Working with Users in Active Directory

Summary: Ed Wilson, Microsoft Scripting Guy, talks about using Windows PowerShell to work with users in Active Directory Domain Services.

Hey, Scripting Guy! Question Hey, Scripting Guy!

We are a rather diversified IT shop, but we have a heavy investment in Microsoft, and particularly in Active Directory. We use it for everything. I need to be able to update user information, but I cannot install anything on my computer. I need something that is basically in the box. How can I do this?


Hey, Scripting Guy! Answer Microsoft Scripting Guy, Ed Wilson, is here. It is becoming rather warm here in central Florida. The other day, the Scripting Wife and I were in Tampa working with Microsoft evangelist, Blaine Barton. We met up with Blaine in Jacksonville at the IT Pro Camp, and he persuaded us to come to Tampa and hang out for a while.

We have decided to start doing the monthly POD casts again, so we were creating our plan for that. It is really exciting stuff, and it will be absolutely awesome. We took his boat out, so we would have some awesome acoustics. Nothing says GEEK quite like Windows PowerShell, boats, and a Surface Pro 3. The only bummer was that I could not get a New-Boat cmdlet to work properly.

Anyway, OF, it is still possible to use ADSI to create and work with users in Active Directory. Yesterday in Create Users in Active Directory Without Using Module, I talked about creating user objects, so today I will talk a little bit about modifying a user.

You will use ADSI to modify user properties that are 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 data that used to be contained in separate disparate places. For instance, you might have an internal website that contains a telephone directory, and you can put phone numbers into Active Directory as attributes of the User object. You might have a website that contains a social roster that includes employees and their hobbies, so you could put hobby information in Active Directory as a custom attribute.

You can also add to Active Directory information, such as an organizational chart. The issue, 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. However, 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 users.

This is where ADSI and Windows PowerShell really begin to shine. You can update hundreds or even thousands of records easily and efficiently by using scripting. Such a task would be unthinkable using conventional point-and-click methods.

To modify user properties in Active Directory, do the following:

  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 the following image is used in this script.

Image of menu

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 field in the previous image. Use the values to see which display name maps to which LDAP attribute name.

Two of the attributes accept an array: OtherTelephone and url. The url attribute is particularly misleading—first because it is singular, and second because the OtherTelephone value uses the style OtherTelephone.

In addition, the primary webpage uses the name wwwHomePage. When supplying values for the OtherTelephone and url attributes, ensure that the input value is accepted as an array by using the @() characters to cast the string into an array. The use of all these values is illustrated in ModifyUserProperties.ps1, shown here:

# ModifyUserProperties.ps1

$objUser = [ADSI]"LDAP://cn=MyNewUser,ou=myTestOU,dc=iammred,dc=net"
$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", "")
$objUser.Put("wwwHomePage", "")

OF, that is all there is to using ADSI to modify user attributes. Active Directory Week will continue tomorrow when I will talk about using the Active Directory cmdlets.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (1)

  1. Rocky19xx says:

    Great article!!! _BK

Skip to main content