Working with Users

In this section, you will use ADSI to modify User properties stored in Active Directory. The following list summarizes a few of the items you can change or configure:

• Office and telephone contact information

• Mailing address information

• Department, title, manager, and direct reports (people who report to the user inside the “chain of command”)

User information that is stored in Active Directory can easily replace several pieces of disparate information in a single swoop. For instance, you might have an internal Web site that contains a telephone directory; you can put the phone number into Active Directory as an attribute of the User object. You might also have a Web site containing a social roster that includes employees and their hobbies; you can put hobby information in Active Directory as a custom attribute. You can also add to Active Directory information such as an organizational chart. The problem, of course, is that during a migration, information such as a user’s title is the last thing the harried mind of the network administrator thinks about. To leverage the investment in Active Directory, you need to enter this type of information because it quickly becomes instrumental in the daily lives of demure users. This is where ADSI and Windows PowerShell really begin to shine. We can update hundreds or even thousands of records easily and efficiently using scripting. Such a task would be unthinkable using conventional point-and-click methods.

Just the Steps 

To modify user properties in Active Directory

1. Implement the appropriate protocol provider.

2. Perform binding to Active Directory.

3. Specify the appropriate ADsPath.

4. Use the Put method to write selected properties to users.

5. Use the SetInfo() method to commit changes to Active Directory.

General User Information

One of the more confusing issues when you use Windows PowerShell to modify information in Active Directory is that the names displayed on the property page do not correspond with the ADSI nomenclature. This was not done to make your life difficult; rather, the names you see in ADSI are derived from LDAP standard naming convention. Although this naming convention makes traditional LDAP programmers happy, it does nothing for the network administrator who is a casual scripter. This is where the following script,  ModifyUserProperties.ps1, comes in handy. The LDAP properties corresponding to each field in Figure 7-3 are used in this script.

Figure 7-3: ADSI attribute names of the General tab of Active Directory Users and Computers

Some of the names make sense, but others appear to be rather obscure. Notice the series of objUser.Put statements. Each lines up with the corresponding fields in Figure 7-3. Use the values to see which display name maps to which LDAP attribute name. The use of all these values is illustrated in  ModifyUserProperties.ps1, shown here:

 ModifyUserProperties.ps1

 $objUser = [ADSI]"LDAP://cn=MyNewUser,ou=myTestOU,dc=nwtraders,dc=msft" $objUser.put("SamaccountName", "myNewUser") $objUser.put("givenName", "My") $objUser.Put("initials", "N.") $objUser.Put("sn", "User") $objUser.Put("DisplayName", "My New User") $objUser.Put("description" , "simple new user") $objUser.Put("physicalDeliveryOfficeName", "RQ2") $objUser.Put("telephoneNumber", "999-222-1111") $objUser.Put("mail", "[e-mail]") $objUser.Put("wwwHomePage", "http://www.mnu.msn.com") $objUser.setInfo()

Quick Check 

Q. What is the field name for the user’s first name?

A. The field for the user’s first name is called "GivenName". You can find field mapping information in the Platform SDK.

Q. Why do you need to do a SetInfo() command?

A. Without a SetInfo() command, all changes introduced during the script are lost because the changes are made to a cached set of attribute values for the object being modified. Nothing is committed to Active Directory until you call SetInfo().