Learn about Windows PowerShell
Summary: Learn how to translate between ADSI, Quest, and Windows PowerShell cmdlets for creating users in Active Directory.
Hey, Scripting Guy!
I've got some older scripts that create users by using the [ADSI] accelerator. Can you show me how they might be rewritten to work with the more modern cmdlets in Windows Server 2012 R2?
Honorary Scripting Guy, Sean Kearney, is here, and I'm just "primed" to show you how to "transform" from one style of scripting to another!
Windows PowerShell is truly a technology that is more than meets the eye. It can be a simple management console to a full-fledged automation solution. It is so many things to so many people.
One of the challenges faced by IT professionals is taking an older script and bringing it up-to-date. This is, of course, after contemplating the most critical thought process: What is the business case for bringing it up-to-date? If the old script works fine, why change it?
It could be for a reason such as using the newer technology lends to better security, such as in the case of the Microsoft Active Directory cmdlets, which leverage WinRM instead of using RPC.
It could even be that upgrading some scripts to leverage cmdlets (instead of using an older method like ADODB or ADSI) might mean that it would be less difficult to train newer staff.
For whatever reason, this week we're going to assume that you've crossed past the reasoning and there is a valid reason to rewrite some or all of your older scripts. We're also going to focus strictly on Windows PowerShell as opposed to dabbling in VBScript script.
I'm personally of the opinion that if you can adapt your Windows PowerShell script and your VBScript script to work with each other (which it does out of the box), save yourself some time, go home, watch a little Doctor Who, and enjoy the day.
But for the next five days, we're going to visit adapting and transforming between three of the key versions for interfacing Active Directory and Windows PowerShell: the [ADSI] accelerator, Quest cmdlets, and Windows PowerShell cmdlets.
Each has their strengths and each has their weaknesses. But the goal of the next five days is show you the same task in all three worlds so that you can grasp how to adapt between the syntaxes and walk between the three worlds.
So let's try something that saves every administrator a bit of a headache. That pesky locked-out account. You clean them, you scrub them, and no matter what you do, they keep locking.
In my last job, a new coworker (who was already an excellent scripter), joined me in my challenge of maintaining and upgrading our current environment. His name was Kevin.
Kevin's eyes lit up when he heard about Windows PowerShell. He was already trying to find a quicker way to unlock user accounts, which is normally a real…well, you know what's it like.
Kevin had put together a quick Windows PowerShell script to unlock a typical user account, and he was very pleased by it:
$User.lockouttime = 0
He was about to ask me how to find users in Active Directory rather than typing in the Distinguished Name each time, when I showed him the Quest cmdlets I had been using.
Unlocking the same account with those cmdlets was even easier—a single line. We can pass along the same value to the Quest cmdlet:
Unlock-QADUser –identity 'CN=Valentine-Michael Smith,OU=Grok,DC=Contoso,DC=Local'
But we can even unlock it with only the name from Active Directory:
Unlock-QADUser 'Valentine-Michael Smith'
I think Kevin must have fallen over in his seat when he saw the Quest cmdlet in action. "But wait, there's more!" I popped in.
"More?" he seemed puzzled.
"The Quest cmdlets are a non-Microsoft add-in, and they work great, but your solution is native to the operating system."
There is a new way to work with Windows PowerShell because we have a modern Active Directory domain controller in our environment. Introduced for domain controllers running Windows Server 2008 R2, we can use the Microsoft Active Directory cmdlets, which also happen to be a native solution."
Kevin remembered reading about them, and asked, "So for the same user and the same task, how would this run in the newer cmdlets from Microsoft?"
I looked at Kevin. "They're kinda cooler because you can use them in a manner similar to ADSI, and kinda close to Quest, too. We can unlock an account with only the Distinguished Name like using this method:"
UNLOCK-ADAccount –identity 'CN=Valentine-Michael Smith,OU=Grok,DC=Contoso,DC=Local'
"Or we can let Windows PowerShell find the account and pipe the information to the Unlock cmdlet like this:"
GET-Aduser –filter 'Name –like "Valentine-Michael Smith"' | UNLOCK-ADAccount
Kevin looked over the cmdlets, "So it's not really too tricky to switch between the different methods. Is there an advantage of one over the other?"
I looked at Kevin, "We'll chat about that on Friday, but let's get more stuff that we can convert tomorrow."
Pop in tomorrow when we will learn more about converting between scripting styles!
I invite you to follow The Scripting Guys on Twitter and Facebook. If you have any questions, send an email to The Scripting Guys at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then remember eat your cmdlets each and every day with a dash of creativity.
Sean Kearney, Windows PowerShell MVP and Honorary Scripting Guy
I love the Quest cmdlets. I work in a large environment and piping simple cmdlets such as Get-QADuser -Locked:$true | Unlock-QADuser -verbose ---- is a huge timesaver, especially if they're getting locked out from a scheduled task or invalid attempts on
their phones email app.
Greatly looking forward to the other Parts.
Very good article! I have never used UNLOCK-ADAccount cmdlet.