More Control of Active Directory Groups through PowerShell

How to scour PowerShell's Help to discover time-saving tips

In “Searching and Managing Active Directory Groups with PowerShell,” I showed you a bunch of AD-related PowerShell commands related to AD groups: new-adgroup creates groups, add-adgroupmember adds accounts to a group, and get-adgroupmember retrieves user accounts that are members of a given group. This month, I want to extend your ability to use get-adgroupmember and I want to finish the column by showing you how I used PowerShell's Help to come up with a time-saving tip.

First, to round out your ability to manage groups, let's apply what you've learned in the past PowerShell articles. Once you know that you can create a new group with new-adgroup, you probably won't be surprised to learn that you can delete a group with remove-adgroup, like so:

remove-adgroup folks

(Remember that, in general, you don't see PowerShell commands like create-something or delete-something; rather, it's new-something or remove-something.) After you enter that command, PowerShell will ask you if you're sure you want to zap that group, and that's a good thing: Undeleting stuff in AD is a pain if you don't yet have the AD Recycle Bin enabled. If, however, you're very sure of yourself, you can always suppress the PowerShell confirmation question by adding -confirm:$false, as in

remove-adgroup folks -confirm:$false

That same "remove equals delete" factoid also takes the guessing game out of removing a user from an AD group, because you can assume that there's probably a remove-adgroupmember command, given that you've already met add-adgroupmember. That's a reason why you should stick with learning PowerShell: The first few commands are a bit complex and even initially non-intuitive, but once you grasp the PowerShell way of thinking, it gets a lot easier to use it—and quickly.

Second, remember when I showed you that add-adgroupmember acts a bit unusually for PowerShell? As an example, I offered

add-adgroupmember folks user2,user3

which looks odd because PowerShell normally needs parameters with names, as in this perfectly correct alternative way to type that command:

add-adgroupmember -identity folks -members user2,user3

How did I know that I could skip -identity and -members? I took a close look at PowerShell's Help! By running get-help add-adgroupmember -full, you’ll find a huge pile of information. Yes, it's tempting to just skip down to the examples, but take a moment to look at the text about the parameters. You'll quickly deduce that you're pretty much always going to need the -identity and -members parameters, so those are the ones to examine. The description for -identity partly looks like this:

Required? true
Position? 1
Default value

Those three items tell you a lot: You can't call add-adgroupmember without -identity (Required? true), it doesn't have a default value (no value after Default value), and then there’s the most interesting of the three items, Position? 1.

In the case of 99 percent of the PowerShell parameters, that line says Position? named, meaning that you must use the parameter's name, such as -identity folks. The rare case wherein there's a number means that you can certainly use a number as a named parameter, but alternatively if you just type the number as the first word after the command, PowerShell will treat it as if you'd typed -identity before it. Continue along and look at the Help text for -members and you'll see Position 2, which is how I knew that I could skip the named parameter on that one, also. Positional parameters don't appear often in the AD tools, but they're welcome gems when you do find them, so a minute's work in Help is often repaid.

Finally, there's some bad news about get-adgroupmember: Once it retrieves a user object, get-adgroupmember contains only about a dozen of that user's attributes. Furthermore, get-adgroupmember lacks a -searchbase option that would let us tell it to return only users from some subset of the domain's containers. By expanding on techniques I’ve shown you before, though, you can restore these functionalities to the cmdlet.

First problem: How do you retrieve the members of the group folks and their lastlogondate? Well, get-adgroupmember folks gets the members, but not their lastlogondate. Recall that we solved this problem for search-adaccount, and it'll work just as well for adgroupmember:

get-adgroupmember -r folks | get-aduser -properties lastlogondate

In this case, I grabbed the (incomplete) user accounts, then used the pipeline to retrieve those accounts again with get-aduser. Once get-aduser was in play, I could employ -properties—very nice, and not too inefficient, because dumping get-adgroupmember took only a short time, and (since it probably returns a fairly small number of objects) re-retrieving the accounts with get-aduser will usually be quite quick.

But what about the lack of -searchbase? How can I restrict my search to, say, users in just one OU? I’ll tackle that next month, when I’ll show you once again that in the PowerShell world, there's usually more than one way to skin a cat!

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.