Summary: Learn how to translate between ADSI, Quest, and Windows PowerShell cmdlets for creating users.
Hey, Scripting Guy!
Today I’m translating a script for modifying user properties and I could really use some help. There are so many parameters to work with. Where do I start?
—LC
Hello LC,
Honorary Scripting Guy, Sean Kearney, here. I’m finishing up this week where I have been discussing switching between the various forms of Active Directory cmdlets.** **
Note This is the final post in a series. For more, see:
- Transforming to Active Directory Cmdlets: Part 1
- Transforming to Active Directory Cmdlets: Part 2
- Transforming to Active Directory Cmdlets: Part 3
- Transforming to Active Directory Cmdlets: Part 4
Funny enough, LC, Kevin had the same issue. He actually had an older ADSI script that he was trying to modify to both Quest and Windows PowerShell versions. The original script looked like this:
$ModifyList=Import-CSV $ModifyList.csv
Foreach {$User in $ModifyList)
{
$Parent=’OU=Grok,DC=Contoso,DC=Local’
$Class=”user”
$Connection=[ADSI]”LDAP://$Parent”
$Name=’CN=’+$User.Name
$Phone=$User.Phone
$Email=$User.Email
$Description=$User.Description
$SetUser=$Connection.($invokeGet(Class, $Name)
$SetUser.put(“description”,$user.Description)
$SetUser.put(“mail”,$user.email)
$Setuser.put(“telephoneNumber”,$user.phone)
}
Kevin was in small quandary, “The cmdlets are easy to use. The issue I am having is trying to sort out the parameters with all the names—there are sooo many.”
By looking at Get-Help for both cmdlets for setting user information, you can see Kevin’s issue. Check out the sheer number of parameters!
First the Quest cmdlet:
Then the Windows PowerShell cmdlet:
“Using them is actually pretty easy to figure out. Pass the name and give the parameter and value. But I have to try to find the one parameter to match the value I’m looking for. If only there was a way to list the parameters so I could find the name with a search.”
Kevin began eyeing the shiny spot when I pointed out, “There is a way…and an easy one at that.”
“We get that information by using Get-Command. IT can tell us information about the cmdlet and its properties.”
GET-Command SET-ADUser | GET-Member
I then showed Kevin how to pull up a list of parameters for the Set-ADUser cmdlet:
(GET-Command SET-ADUser).parameters
“Ooooooo!” His eyes lit up, “So can I pass this information to Where-Object to filter on?”
He immediately sat down to try to find the parameter for “email” with Set-ADUser:
(GET-Command SET-ADUser).parameters | Select-Object -ExpandProperty Keys | where { $_ -like ‘*mail*’ }
He found that the parameter name is EmailAddress, and he began putting together the rest of the command for the Set-ADUser Windows PowerShell cmdlet:
(GET-Command SET-ADUser).parameters | Select-Object -ExpandProperty Keys | where { $_ -like ‘*description*’ }
(GET-Command SET-ADUser).parameters | Select-Object -ExpandProperty Keys | where { $_ -like ‘*phone*’ }
And then he wrote the following for the Quest version:
(GET-Command SET-QADUser).parameters | Select-Object -ExpandProperty Keys | where { $_ -like ‘*mail*’ }
(GET-Command SET-QADUser).parameters | Select-Object -ExpandProperty Keys | where { $_ -like ‘*description*’ }
(GET-Command SET-QADUser).parameters | Select-Object -ExpandProperty Keys | where { $_ -like ‘*phone*’ }
In most cases, Kevin found a one-to-one match, for example, Description. In some cases, he got a few extras, for example, HomePhone, MobilePhone, and PhoneNumber.
“But this is way easier. Now that I can see the most likely parameters to use, I can easily convert this script. First, a version for our modern environment with Windows Server 2012 R2:”
$ModifyList=Import-CSV $ModifyList.csv
Foreach {$User in $ModifyList)
{
$Parent=’OU=Grok,DC=Contoso,DC=Local’
$Name=$User.Name
$Phone=$User.Phone
$Email=$User.Email
$Description=$User.Description
SET-ADUser $Name –emailaddress $email –OfficePhone $phone –description $Description
}
“And now the exact script for the Quest Set-QADUser cmdlet:”
$ModifyList=Import-CSV $ModifyList.csv
Foreach {$User in $ModifyList)
{
$Parent=’OU=Grok,DC=Contoso,DC=Local’
$Name=$User.Name
$Phone=$User.Phone
$Email=$User.Email
$Description=$User.Description
SET-QADUser $Name –email $email –Phonenumber $phone –description $Description
}
Kevin noted that all three commands (ADSI, Quest, and Windows PowerShell) seemed to have their place, “I found that the Quest cmdlets were easiest to use, but they have a .NET Framework requirement that I can’t use sometimes—depending on restrictions in the environment. The older [ADSI] accelerator is more involved, but it works all the time.”
“True,” I nodded, “But the coolest thing you may not have realized about the Microsoft Active Directory cmdlets is that they do not require firewall ports to be open for WMI and RPC. They leverage a web service.”
Jaw drop time. “Do you mean the network guys won’t freak on me as much when I spin up a domain controller? WooHooo!”
And after this day, a small paper lay on the desk:
“Here lay the ‘Shiny Spot’—a place of frustration, venting, and head butting—until Kevin learned Windows PowerShell. The ‘Shiny Spot’ is no more.”
LC, that is all there is to converting the basic Active Directory user cmdlets. You know? I think tomorrow is Saturday! That means time for the Weekend Scripter! WooHoooo!
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 scripter@microsoft.com, 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
0 comments