Summary: Honorary Scripting Guy, Sean Kearney, shares his early use of PowerShell as a network administrator.
I have a simple but irritating task each day around lunch time. A handful of people usually lock themselves out of Active Directory. Can you help me find an easy way to deal with this?
Honorary Scripting Guy, Sean Kearney, is here to help you share the pain. I, too, once felt that prickly feeling on the back of my neck near the end of lunch hour. “Lock out Hell”, I called it.
I know that everyone has experienced that, especially on Friday. A handful of people come in and for whatever reason have locked themselves out.
We’re not even going to get in to the root cause of this: the Shift key was stuck, there was a soft lock in the software, or their brains were sucked away by Martians.
Perhaps they were showing off their ‘R@s K001 P@$$w0rd skillz’ to a co-worker and incorrectly typed the last three punctuation marks in the password they invented.
But, you would almost always get an onslaught of “I locked myself out and NEED (not want … capital N*E*E*D) to get back in now.”
In the old world, I would have had to go to Active Directory Users and Computers, find the user, unlock the user, call the use, and then proceed to the next person.
But, it never works like that, does it? Invariably, some of those users (or maybe all on a bad day) will lock themselves out again in that same 10-minute period. Thus the phrase, “Lock out Hell”, as you waste half an hour going through the GUI to unlock users.
People make mistakes, and there’s no use getting angry with them. The process itself was just, well, lacking finesse.
I had been using PowerShell earlier that month to migrate users to a new Active Directory and had been playing with the Quest cmdlets at the time. One lunch hour, I played with PowerShell and found the Unlock-QADUser cmdlet.
After I found this cmdlet, the process was simply a matter of running something like the following for the five or six people:
Unlock-QADUser jsmith
Then I pressed an up arrow, entered the next name, and repeated the process for the next four or five. It was far less stressful. In the modern Windows Server 2008 R2 and higher environment, I would have used the following cmdlet:
Unlock-ADAccount
It accomplished the same result and, again, was far less aggravation for everyone…including me. 
Later on, I would have to start disabling users, often quietly and discreetly. Very much like “Shh…when you see your phone ring from the VP Disable Mr. X.” (Professor Xavier’s evil cousin, you see.)
For that, it was a matter of queuing up a cmdlet like Disable-QADUser. I would also correspondingly have an Enable-QADUser ready because sometimes it was actually Mrs. Y and not Mr. X so “Could you please quickly flip that around?”
As result, it was very easy to deal with those situations by using PowerShell just as a management console.
Later on in my IT life, we had to start producing some basic audits about who had Domain Admin and Enterprise Admin access. I already knew that I could use PowerShell to ask Active Directory questions, such as, “Show me all the members of this group.”
Auditors who saw the code that did the audit were very happy to see that it was PowerShell. The following cmdlet pulled up a list of Domain Admins and dumped it untouched to a CSV file.
Get-ADGroupMember -Identity 'Domain Admins' | Export-CSV DomainAdmins.csv
My environment actually had quite a few domains. Some were for the Development division, Vendor applications for a customer. Because of PowerShell, it was easy to pull the same data for any environment from the console.
As my work progressed into other environments, including managing my remote workstations, PowerShell was my view into systems. Using Windows Management Instrumentation (WMI), I would easily query a remote system for its serial number by using Get-Wmiobject:
(Get-WmiObject win32_bios –computername PC123).serialnumber
At the time, I didn’t have tools like System Center Configuration Manager. Our Division was pretty small. I still needed to manage systems and ask questions.
Those questions were readily answered by using PowerShell, even without scripts.
It’s just some food for thought if you’re convincing yourself that PowerShell is only for scripters.
Pop on in tomorrow. If you’re curious, I’ll show you some neat tricks that Microsoft offers to use PowerShell without actually have to learn it.
Strange concept, eh?
I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to them at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow.
Until then, always remember that with Great PowerShell comes Great Responsibility.
Sean Kearney
Honorary Scripting Guy
Cloud and Datacenter Management MVP