Creating the Address Page

One of the more useful tasks you can perform with Active Directory is exposing address information. This ability is particularly important when a company has more than one location and more than a few hundred employees. I remember one of my first intranet projects was to host a centralized list of employees. Such a project quickly paid for itself because the customer no longer needed an administrative assistant to modify, copy, collate, and distribute hundreds of copies of the up-to-date employee directory-potentially a full-time job for one person. After the intranet site was in place, personnel at each location were given rights to modify the list. This was the beginning of a company-wide directory. With Active Directory, you avoid this duplication of work by keeping all information in a centralized location. The “second page” in Active Directory Users and Computers is the address page, shown in Figure 7-4 with the appropriate Active Directory attribute names filled in.

Figure 7-4: Every item on the Address tab in Active Directory Users and Computers can be filled in via ADSI and Windows PowerShell

In the  ModifySecondPage.ps1 script, you use ADSI to set the street, post office box, city, state, zip code, c, co, and country values for the User object. Table 7-4 lists the Active Directory attribute names and their mappings to the Active Directory Users and Computers management tool “friendly” display names.

Table 7-4: Address Page Mappings
Open table as spreadsheet

Active Directory Users and Computers Label	Active Directory Attribute Name
Street	streetAddress
P.O. Box	postOfficeBox
City	l (Note that this is lowercase L.)
State/Province	st
Zip/Postal Code	postalCode
Country/Region	c,co,countryCode

When working with address-type information in Windows PowerShell, the hard thing is keeping track of the country codes. These values must be properly supplied. Table 7-5 illustrates some typical country codes. At times, the country codes seem to make sense; at others times, they do not. Rather than guess, you can simply make the change in Active Directory Users and Computers, and use ADSI Edit to examine the modified value, or you can look them up in ISO 3166-1.

 ModifySecondPage.ps1

 $objUser = [ADSI]"LDAP://cn=MyNewUser,ou=myTestOU,dc=nwtraders,dc=msft" $objUser.put("streetAddress", "123 main st") $objUser.put("postOfficeBox", "po box 12") $objUser.put("l", "Bedrock") $objUser.put("st", "Arkansas") $objUser.put("postalCode" , "12345") $objUser.put("c", "US") $objUser.put("co", "United States") $objUser.put("countryCode", "840") $objUser.setInfo()

Table 7-5: ISO 3166-1 Country Codes
Open table as spreadsheet

Country Code	Country Name
AF	AFGHANISTAN
AU	AUSTRALIA
EG	EGYPT
LV	LATVIA
ES	SPAIN
US	UNITED STATES

Caution 

The three country fields are not linked in Active Directory. You could easily have a c code value of US, a co code value of Zimbabwe, and a countryCode value of 470 (Malta). This could occur if someone uses the Active Directory Users and Computers to make a change to the country property. When this occurs, it updates all three fields. If someone later runs a script to only update the country code value, or the co code value, then Active Directory Users and Computers will still reflect the “translated value” of the c code. This could create havoc if your Enterprise Resource Planning (ERP) application uses the co or country code value, and not the c attribute. Best practice is to update all three fields through your script.

Quick Check

Q. To set the country name on the address page for Active Directory Users and Computers, what is required?

A. To update the country name on the address page for Active Directory Users and Computers, you must specify the c field and feed it a two-letter code that is found in ISO publication 3166.

Q. What field name in ADSI is used to specify the city information?

A. You set the city information by assigning a value to the l (lowercase) field after making the appropriate connection to Active Directory.

Q. If you put an inappropriate letter code in the c field, what error message is displayed?

A. None.

Modifying the user profile settings

1. Open the  ModifySecondPage.ps1 script, and save it as yourname ModifyUserProfile.ps1.

2. The user profile page in Active Directory is composed of four attributes. We can therefore delete all but four of the $objUser.put commands. The actual profile attributes are shown in Figure 7-5.

   
   Figure 7-5: ADSI attributes used to fill out the profile page in Active Directory

3. The first attribute we need to supply a value for is the profilePath attribute. This controls where the user’s profile will be stored. On my server, the location is \\London\Profiles in a folder named after the user, which in this case is myNewUser. Edit the first of the $objUser.put commands you left in your script to match your environment. The modified $objUser.put command is shown here:

    $objUser.put("profilePath", "\\London\profiles\myNewUser")

4. The next attribute we need to supply a value for is the scriptpath attribute. This controls which logon script will be run when the user logs on. Even though this attribute is called scriptpath, it does not expect an actual path statement (it assumes the script is in sysvol); rather, it simply needs the name of the logon script. On my server, I use a logon script called logon.vbs. Modify the second $objUser.put statement in your script to point to a logon script. The modified command is shown here:

    $objUser.put("scriptPath", "logon.vbs")

5. The third attribute that needs to be set for the user profile is called homeDirectory, and it is used to control where the user’s home directory will be stored. This attribute needs a Universal Naming Convention (UNC) formatted path to a shared directory. On my server, each user has a home directory named after their logon user name. These folders are stored under a shared directory called Users. Modify the third $objUser.put statement in your script to point to the appropriate home directory location for your environment. The completed command is shown here:

    $objUser.put("homeDirectory", "\\london\users\myNewUser")

6. The last user profile attribute that needs to be modified is the homeDrive attribute. The homeDrive attribute in Active Directory is used to control the mapping of a drive letter to the user’s home directory. On my server, all users’ home drives are mapped to the H: drive (for home). Please note that Active Directory does not expect a trailing backslash for the homeDirectory attribute. Modify the last $objUser.put command to map the user’s home drive to the appropriate drive letter for your environment. The modified command is shown here:

    $objUser.put("homeDrive", "H:")

7. Save and run your script. If it does not modify the user’s profile page as expected, compare your script with the  ModifyUserProfile.ps1 script.

8. This concludes the modifying the user profile settings procedure.

Modifying the user telephone settings

1. Open  ModifySecondPage.ps1 script, and save the file as yournameModifyTelephone Attributes.ps1.

2. The Telephones tab in Active Directory Users and Computers for a user account is composed of six attributes. These attribute names are shown in Figure 7-6, which also illustrates the field names, as shown in Active Directory Users and Computers on the Telephones tab for the User object. Delete all but six of the $objUser.put commands from your script.

3. The first attribute you modify is the homePhone attribute for the MyNewUser user account. To do this, change the value of the first $objUser.put command so that it is now writing to the homePhone attribute in Active Directory. The phone number for the MyNewUser account is [phone]. For this example, we are leaving off the country code, and enclosing the area code in parentheses. This is not required, however, for Active Directory. Our modified line of code is shown here:

    $objUser.Put("homePhone", "[phone]")

4. The next telephone attribute in Active Directory is the pager attribute. Our user account has a pager number that is [phone]. Modify the second $objUser.put line of your script to put this value into the pager attribute. The revised line of code is shown here:

    $objUser.Put("pager", "[phone]")

5. The third telephone attribute we need to modify on our user account is the mobile telephone attribute. The name of this attribute in Active Directory is mobile. The mobile telephone number for our user is [phone]. Edit the third $objUser.put command in your script so that you are writing this value into the mobile attribute. The revised line of code is shown here:

    $objUser.Put("mobile", "[phone]")

6. The fourth telephone attribute that needs to be assigned a value is for the fax machine. The attribute in Active Directory that is used to hold the fax machine telephone number is facsimileTelephoneNumber. Our user has a fax number that is [phone]. Edit the fourth $objUser.put command in your script to write the appropriate fax number into the fax attribute in Active Directory. The revised code is shown here:

    $objUser.Put("facsimileTelephoneNumber", "[phone]")

7. The fifth telephone attribute that needs to be assigned a value for our user is the IP address of the user’s IP telephone. In Active Directory, this attribute is called ipPhone. The myNewUser account has an IP telephone with the IP address of “192.168.6.112”. Modify the fifth $objUser.put command so that it will supply this information to Active Directory when the script is run. The revised command is shown here:

    $objUser.Put("ipPhone", "192.168.6.112")

   
   Figure 7-6: Telephone page attributes found in Active Directory

8. Finally, the last telephone attribute is the notes, or the official disclaimer attribute. In Active Directory, this field is called the info attribute.

    $objUser.Put("info", "All contact information is confidential," `  + "and is for official use only.")

9. Save and run your script. You should see the all the properties on the Telephones tab filled in for the MyNewUser account. If this is not the case, you may want to compare your script with the  ModifyTelephoneAttributes.ps1 script.

10. This concludes the modifying the user telephone settings procedure.

Creating multiple users

1. Open the  CreateUser.ps1 script, and save it as yourname CreateMultipleUsers.ps1.

2. On the second line of your script, change the name of the variable $strName to $aryNames because the variable will be used to hold an array of user names. On the same line, change the CN=MyNewUser username to CN=MyBoss. Leave the quotation marks in place. At the end of the line, place a comma and type in the next user name: CN=MyDIrect1, ensuring you encase the name in quotation marks. The third user name is going to be CN=MyDirect2. The completed line of code is shown here:

    $aryNames = "CN=MyBoss","CN=MyDirect1","CN=MyDirect2"

3. Under the $objADSI line that uses the [ADSI] accelerator to connect into Active Directory, and above the $objUser line that creates the user account, place a foreach statement. Inside the parentheses, use the variable $strName as the single object and $aryNames as the name of the array. This line of code is shown here:

    foreach($StrName in $aryNames)

4. Below the foreach line, place an opening curly bracket to mark the beginning of the code block. On the line after $objUser.setinfo(), close the code block with a closing curly bracket. The entire code block is shown here:

    {   $objUser = $objADSI.create($strCLass, $StrName)   $objUser.setInfo() }

5. Save and run your script. You should see three user accounts-MyBoss, MyDirect1, and MyDirect2-magically appear in the MyTestOU OU. If this does not happen, compare your script with the  CreateMultipleUsers.ps1 script.

6. This concludes the creating multiple users procedure.

Note 

The interesting thing about Windows PowerShell is that it can read inside a string, find a variable, and substitute the value of the variable, instead of just interpreting the variable as a string literal. Example:

 $objUser = [ADSI]"LDAP://$strUser,$strOU,$strDomain"

Modifying the organizational settings

1. Open the  ModifySecondPage.ps1 script, and save it as yourname ModifyOrganizationalPage.ps1.

2. In this script, we are going to modify four attributes in Active Directory, so you can delete all but four of the $objUser.put commands from your script. The Organization tab from Active Directory Users and Computers is shown in Figure 7-7, along with the appropriate attribute names.

   
   Figure 7-7: Organization attributes in Active Directory

3. To make our script more flexible, we are going to abstract much of the connection string information into variables. The first variable we will use is one to hold the domain name. Call this variable $strDomain and assign the value of dc=nwtraders,dc=msft (assuming this is the name of your domain). This code is shown here:

    $strDomain = "dc=nwtraders,dc=msft"

4. The second variable you wish to declare is the one that will hold the name of the OU. In this procedure, our users reside in an OU called ou=myTestOU, so you should assign this value to the variable $strOU. This line of code is shown here:

    $strOU = "ou=myTestOU"

5. The user name we are going to be working with is called MyNewUser. Users are not domain components (dc), nor are they organizational units (ou); rather, they are containers (cn). Assign the string cn=MyNewUser to the variable $strUser. This line of code is shown here:

    $strUser = "cn=MyNewUser"

6. The last variable we need to declare and assign a value to is the one that will hold the MyNewUser’s manager. His name is myBoss. The line of code that holds this information in the $strManager variable is shown here:

    $strManager = "cn=myBoss"

7. So far, we have hardly used even one piece of information from the  ModifySecondPage.ps1 script. Edit the $objUser line that holds the connection into Active Directory by using the [ADSI] accelerator so that it uses the variables we created for the user, OU, and domain. Windows PowerShell will read the value of the variables instead of interpreting them as strings. This makes it really easy to modify the connection string. The revised line of code is shown here:

    $objUser = [ADSI]"LDAP://$strUser,$strOU,$strDomain"

8. Modify the first $objUser.put command so that it assigns the value Mid-Level Manager to the title attribute in Active Directory. This command is shown here:

    $objUser.put("title", "Mid-Level Manager")

9. Modify the second $objUser.put command so that it assigns the value of Sales to the department attribute in Active Directory. This command is shown here:

    $objUser.put("department", "sales")

10. Modify the third $objUser.put command and assign the string North Wind Traders to the company attribute. This revised line of code is shown here:

     $objUser.put("company", "North Wind Traders")

11. The last attribute we need to modify is the manager attribute. To do this, we will use the last $objUser.put command. The manager attribute needs the complete path to the object, so we will use the name stored in $strManager, the OU stored in $strOU, and the domain stored in $strDomain. This revised line of code is illustrated here:

     $objUser.put("manager", "$strManager,$strou,$strDomain")

12. Save and run your script. You should see the Organization tab filled out in Active Directory Users and Computers. The only attribute that has not been filled out is the direct reports attribute on the MyNewUser user. However, if you open the MyBoss user, you will see MyNewUser listed as a direct report for the MyBoss user. If your script does not perform as expected, then compare your script with the  ModifyOrganizationalPage.ps1 script.

13. This concludes the modifying the organizational settings procedure.