Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to update address information in Active Directory Domain Services (AD DS).
Microsoft Scripting Guy, Ed Wilson, is here. Yesterday, at the Charlotte Windows PowerShell user group meeting, one of the members was talking about adding mailing information to all of the users in a particular organizational unit. There are many reasons that this information may change: Street names are renamed all the time in the United States; cities incorporate other cities; postal codes change due to shifting populations. These are all reasons outside of one’s control. And there are other reasons as well, for example, companies may consolidate offices, close offices, or move offices. Everyone who used to work in the Charlotte, North Carolina, office may suddenly find themselves commuting to Jacksonville, Florida.
Whatever the reason is for updating address information, Windows PowerShell and the Active Directory module make this task fairly simple. It involves a number of attributes, however, and because all of the values for the attributes are static, this is a great time to use splatting.
Note I have several really good articles that talk about splatting. I have written some of them, and others have been written by various guests. Splatting is a technique introduced with Windows PowerShell 2.0, and, if you have not been using it, today is a great time to learn.
Populating address information in Active Directory
There are a couple of approaches to populating address information in Active Directory Domain Services (AD DS). The first approach is to search for particular values and modify the offending values. A second approach is to search for empty or null values for specific attributes, and then populate only the missing data. A third approach is to simply blast new values for a select group of users that meet a specific search criteria. This is the approach I take today.
Note This is the fourth in a series of articles about creating a test Active Directory environment. On Tuesday, I began the series with the Create Test Users in a Test Active Directory Environment by Using PowerShell Blog post, where I wrote a script to create a test organizational unit with 100 test user accounts. On Wednesday, I wrote Use PowerShell to Modify Existing User Accounts in Active Directory, where I talked about using existing user information to create new information such as email addresses and personal web page URLs. On Thursday, I wrote Use PowerShell to Standardize Titles in Active Directory. You should refer to those articles prior to reading today’s article.
The first thing I need to do is to add City attribute values to the user accounts in the TestOU organizational unit (OU). This is a simple matter, and I use the script shown here.
SetADUserCityProperty.ps1
Import-Module ActiveDirectory
$city = "charlotte", "atlanta","jacksonville"
Get-ADUser -SearchBase 'ou=testou,dc=iammred,dc=net' -Filter * |
Foreach-Object {
$i= Get-Random -min 0 -Maximum 3
Set-ADUser -identity $_ -City $city[$i] }
To ensure that I obtained a nice random mixture of cities in the OU, I use the following command.
PS C:\> Get-ADUser -SearchBase 'ou=testou,dc=iammred,dc=net' -Properties city -Filter * | group city -NoElement
Count Name
----- ----
25 jacksonville
40 atlanta
35 charlotte
Create three hash tables for splatting
I want to populate the city, state, streetaddress, postalcode, and the country of each user in the TestOU. Because I know that the city properties are already populated, I know that I will be searching for the City property. However, it may be that the city will need to change once the new properties apply to the user (depends on the exact scenario). Therefore, I decide to create three hash tables. Each hash table resides in a variable with the name of the city. Each hash table is used to apply the appropriate attribute values when calling the Set-ADUser cmdlet from the Active Directory module.
Note Keep in mind, the key properties of the hash table (city, state, streetaddress, postalcode) must match exactly with the Set-ADUser cmdlet parameter names. This is important because ADSI stores the city information in an attribute named l (a lowercase letter L), but the Set-ADUser cmdlet uses the parameter name of City to provide the same information. There are similar attribute name changes to be aware of when migrating old ADSI scripts to use the Active Directory cmdlets.
The three hash tables are shown here.
$charlotte = @{
"City" = "Charlotte"
"State" = "NC"
"StreetAddress" = "One Microsoft Way"
"PostalCode" = "12345" }
$atlanta = @{
"City" = "Atlanta"
"State" = "GA"
"StreetAddress" = "Two Microsoft Way"
"PostalCode" = "23456" }
$jacksonville = @{
"City" = "Jacksonville"
"State" = "FL"
"StreetAddress" = "Three Microsoft Way"
"PostalCode" = "34567" }
The code to make the change is simple. I use the Get-ADUser cmdlet to search the organizational unit, and I add a filter to look for the city equal to Charlotte. I then pipe the results to the Set-ADUser cmdlet and splat the Charlotte values. Because all three cities reside in the United States, I use a static Country value of US. Here is the code to assign the Charlotte values to users with a city value of Charlotte.
Get-ADUser -SearchBase 'ou=testou,dc=iammred,dc=net' -Filter `
{city -eq 'charlotte'} |
Set-ADUser @Charlotte -Country US
Now, I do a cut-and-paste job to create two more searches to find Atlanta and to find Jacksonville. I also splat their values as well. Only the search filter and the splatted values change.
Get-ADUser -SearchBase 'ou=testou,dc=iammred,dc=net' -Filter `
{city -eq 'atlanta'} |
Set-ADUser @atlanta -Country US
Get-ADUser -SearchBase 'ou=testou,dc=iammred,dc=net' -Filter `
{city -eq 'jacksonville'} |
Set-ADUser @jacksonville -Country US
Join me tomorrow for a guest blog post by the Scripting Wife as she talks about our upcoming European Scripting Tour.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy