Adaxes blog

146 attributes. On a Server 2012R2 domain with Exchange, a new user has 146 attributes ready to be populated. The more data put into Active Directory, the more useful it becomes. Consider an employee trying to find a colleague in the Global Address Book. If your user accounts contain job titles, locations, and account pictures, finding someone becomes a snap.

Over the years, your domain probably received many manual entries. If your user accounts were (or are still) created manually, you will probably find that attributes are not standardized. Some may be filled and others left empty. Job titles may not have been updated and old locations haven’t been removed. By using PowerShell and the built in Active Directory Administrative Center (ADAC), we can get these attributes back in order. 

A High Level Attribute View with PowerShell

The first step is to make sense of the existing madness. What optional attributes are most important to you? What can be set in your environment to make life easier for end users or the IT department? If you are unsure, start by looking at available attributes with PowerShell.

Launch PowerShell ISE on a machine with Remote Server Administration Tools (RSAT) installed on it. If this is your first time using the Get-ADUser cmdlet, you may want to use Get-Help –name Get-ADUser –full to view syntax and examples.

Run the command below to view all of the properties for a single user. Be sure to replace the value after –Identity to reflect a user in your domain.

Get-ADUser -Identity Joseph -Properties *

When thinking about your list, consider applications that your users may have. For example, staff using Outlook would benefit with the standardization of the Company and Title attributes as these are shown in the recipient preview window.

Configuring Active Directory Attributes with ADAC through PowerShell

The Active Directory Administrative Center (ADAC) is the replacement for the antiquated Active Directory Users and Computers MMC. Though ADAC still has several shortcomings, it makes an excellent PowerShell instructor. Like many of Microsoft’s newer administrative GUIs, it essentially rests on a PowerShell module.

To demonstrate this, launch ADAC and find a user. Open the properties of this user and edit the “Job Title” field. Alternatively, you can scroll to the bottom of the properties windows – select Attribute Editor and edit the Title attribute. After applying your change, look at the bottom of your ADAC window and expand the Windows PowerShell History pane.

You will see a history of every change you’ve made as if you made those changes in PowerShell! This history shows you the correct syntax and required parameters for each cmdlet. You can even copy the PowerShell command to save or use in a script.

Get and Set Active Directory Attributes by OU

As you expand your view from single objects, discrepancies will begin to appear. In ADAC, navigate to an OU containing user accounts. Left click on in the breadcrumb section to change the path to a PowerShell friendly path. The breadcrumb section is outlined in the red box below.

Copy this path and jump back to PowerShell ISE. Paste in the following command (but do not execute it):

Get-ADUser -Filter * -SearchBase OU=Domain Users,DC=Domain,DC=local -Properties Company,Title | Out-GridView

Instead of looking at a single identity, we’ve changed Get-AdUser to filter off of a single wildcard. Essentially, we are saying find any user. The –SearchBaseparameter controls where those users are found. Paste in your OU path that you copied from ADAC. If your OU has any spaces in it, be sure to put the whole path in quotes. Next, we retrieve a view optional properties (Company and Title). To pull every property, we could have added another asterisk at this location. To make this data a bit easier to analyze, we send our information to the Out-GridView parameter.

Execute your command now. Your output should look similar to the screenshot below:

Out-Gridview allows you to filter by columns. With it, you can also remove any extra column that isn’t needed (ex: SID or ObjectGUID). Another very useful addition to the Get-ADUser cmdlet is Select-Object with the –unique parameter and a filter on a single object. 

Get-ADUser -Filter * -SearchBase "OU=Test,OU=Domain Users,DC=Domain,DC=local" –Properties Title | Select-Object -Property Title -Unique

The example above grabs a single additional property (Title), selects only that value in and narrows our output to unique values. The –Unique parameter provides a very quick way for you to find differing values. This output can be piped to Out-GridView or the Sort-Object cmdlet for further data manipulation.

Let’s take a look at a practical example. Assume that in your Get-ADUser output, you could see that some users have a Title of “Administrative Assistant” and others have a Title of “Secretary”. In your organization, these might be the same job position. You could then run the following command to gather more information about this differing attribute:

Get-ADUser -Filter * -SearchBase "OU=Test,OU=Domain Users,DC=Domain,DC=local" -Properties Created,Title | Where-Object {$_.Title -like "Secretary" -or $_.Title -like "Administrative Assistant"} | Select-Object -Property SamAccountName,Title,Created

The output for this command would show you all users that have a title that is like “Secretary” or “Administrative Assistant”. It would show you only the properties specified after Select-Object. In our example, you could see that users with the title “Secretary” where created before users with the title “Administrative Assistant”. From this, you could surmise that this job position changed in the past but no one went back to update older user accounts. As always, be sure that any large organizational changes are tested and properly approved. Be sure to include your HR department (or similar) as they are frequently the originator of user accounts.

Putting it All Together and Preventing a Reoccurrence

The title attribute problem that we examined could be repeated many times across your entire environment. After analyzing your attributes, make use of the Set-ADUser (or the equivalent Set- cmdlet for other object types). The sample script below solves our secretary/administrative assistant issue that we explored earlier:

$UserTitles = Get-ADUser -Filter * -SearchBase "OU=Test,OU=Domain Users,DC=Domain,DC=local" -Properties Created,Title | Where-Object {$_.Title -like "Secretary"}

foreach ($User in $UserTitles){
    Set-ADUser $User.Samaccountname -Title "Administrative Assistant" -Verbose -WhatIf
}

This script uses the –WhatIf parameter for safety. Once comfortable with the users pulled into the $UserTitles variable, it can be removed. To use this script on a single user at a time, add a pause command on the line below Set-ADUser. After you are confident in your changes, this simple script will let you update thousands of attribute values in seconds!

As you can see, sorting out the incorrect data is much harder than actually fixing it! The next step, which is unique to every organization, is to modify any object creation processes. After all, it would be silly to see that some new users are still getting obsolete attribute values.

Finally, you have to account for one off creations (ex: a new computer account) and attributes that may not get set correctly. Consider using any (or all of the following solutions) to overcome this problem:

•          Centralized creation: less cooks in the kitchen leads to less mess.
•          Alternative solutions such as Adaxes Property Patterns
•          Configuration Scripts: regular tasks that check each value against a known list

If you have any success stories (or tips) on standardizing AD attributes, let us know in the comments below!

Joseph Moody

Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.