For the past few months, I've shown you the first (and hardest) part of PowerShell Active Directory (AD) one-liners: the query. (See "Automating PowerShell Reports, Part 1," and " Automating PowerShell Reports, Part 2.") As I've said before, you can see the real power of PowerShell in AD by combining a cmdlet that collects all the accounts that meet some criterion (e.g., everyone who hasn’t logged on in 120 days, everyone in the Facilities Management OU, everyone whose manager is Sam Jones)—aka the query—with another cmdlet that does something to those accounts (e.g., disables them, forces them to change their password at next logon, changes their manager to Darla Seward). Another way I like to think of these "AD PowerShell duets" is a combination of the filter (find the folks in question) and the hammer (do something with them).

 

To find people who fall into a particular category, we've examined get-aduser (does everything but is complex), search-adaccount (limited to finding just a few things but is well tuned and offers simpler syntax for those needs), and get-adgroupmember (reveals group members). This month, it's time to get some work done—and begin meeting a lot of new cmdlets to get that work done.

To that end, meet our first hammer: disable-adaccount. To use it, you just type the command, followed by a distinguished name, an account GUID or SID, or a samaccountname. To disable an account with a logon name of IvanVasilyevich4, you would type

disable-account -identity IvanVasilyevich4

This looks like the PowerShell cmdlets you’ve met before—same verbish-noun structure. You probably also won't be surprised to learn that disable-account accepts -identity as a positional parameter in the first position, which just means that you can type

disable-account IvanVasilyevich4

and get the same result. But here's the question: Would you ever do that? Disable-account involves a lot of typing, even if you're using PowerShell's tab-completion functionality. (And may the repetitive-stress-injury gods have mercy on your wrists if you try tab completion while in System32, the folder that PowerShell likes to start in if you're running elevated.) You could, of course, give it a shorter name with set-alias, as in

set-alias disable-adaccount dacc

which would let you henceforth just type

dacc IvanVasilyevich4

But you'd have to put that set-alias command in your profile, and you'd be typing commands that no one else understood. Don't get me wrong: There's nothing wrong with performing one-off AD administration with PowerShell, particularly if you're a fast typist, you’re deft with the tab key, and you keep a PowerShell command prompt window open at all times. But the real power is, again, not in PowerShell "solos" but in duets, as in this one:

search-adaccount -usersonly -accountinactive -timespan "120" | disable-adaccount

It looks ugly, but when you break it up, it gets easier. First, there's the piece on the left:

search-adaccount -usersonly -accountinactive -timespan "120"

If you've been reading these columns for the past few months, that should look familiar. It's the command that finds all the users who haven't logged on in 120 days. You've known about these truants for months … you just haven't done anything with that information, short of making note of it.

Second, there's the pipeline character (|). If you've ever messed with DOS batch files or with UNIX command-line administration, you might recognize it. It's how PowerShell takes the output of one command (the list of people who haven't logged on in four months) and feeds it as input to another command—in this case, the command to disable them:

disable-adaccount

Thus, this pair of cmdlets finds those users who haven’t logged on in 120 days and disables their accounts.

This example, I think, finally offers some payoff for all of our PowerShell studies. Could you do this with the GUI? Not easily. You'd have to craft some kind of bizarre LDAP query, run it, hit Ctrl+A to select the results, and—well, you get the idea. Yes, the command is a bit long, but do what I do: Use one of those yellow notes in Outlook to store useful PowerShell one-liners, or as one of the new "snippets" in PowerShell 3.0. (Download Windows Management Framework 3.0—it needs .NET 4.0—and you get PowerShell 3.0. I strongly recommend it.) Or, better yet, take that command, package it up as a .ps1 file as I demonstrated last month, and make a task that runs automatically every week or so.

I’ve just started with one-liners. Join me next month for another hammer and—yes—another one-liner!