Is PowerShell Flawed?

Following my previous post about automating user licensing in Office 365, I came across a funny issue with Windows PowerShell for Active Directory. The project was to help the client connect to Office 365, they had multiple Active Directory forests in multiple international locations. For those that have worked with Office 365 you will know that before a license is allocated a “Usage Location” has to be set. So the plan was to use the “Country/Region” data from Active Directory. However some of the forests had not set this for their users. As this had not been set for a large number of accounts I thought the easiest solution would be to set this via PowerShell. I always say that if you’re using the GUI to do something twice, you’re doing it wrong… ;-) I ran the following cmdlet:

Set-ADUser [User] –Country:”GB”

Which in principal worked:  But after a Directory Synchronisation to Office 365 I noticed the change had not been applied to the Azure AD user?!? After some troubleshooting and digging around, I found the issue was that the PowerShell cmdlet run only sets the “c” attribute in Active Directory, whereas if you update the Country via the GUI it updates the “c”, “co”, and “countryCode” attributes. The Directory Sync server uses the “co” field to populate the “County/Region” field in Azure AD. So this got me thinking why the PowerShell cmdlet did not set these values? The sometimes much forgotten Active Directory Administration Centre or ADAC makes changes via PowerShell and gives you the history of the run cmdlets, so I made the change in ADAC, which updated all the attributes as expected, the in the PowerShell history it had run the following cmdlet:

 

I copy and pasted the cmdlet from ADAC straight into Windows PowerShell, but it only set the “c” attribute again… So after a bit of digging around, I came up with the following:

$c ="US"
$co ="United States"
$countryCode = "840"
Set-ADUser <USER> -replace @{c=$c; co=$co; countryCode=$countryCode}

Which had the desired result on the Active Directory attributes and once synchronised to Office 365 the data in Azure AD was correct. I don’t fully understand why setting in ADUC and ADAC updates all the attributes, and if ADAC is making additional changes why it’s not being report in the PowerShell history.

So getting back to the title of the Blog “Is PowerShell Flawed?”… No of course not, PowerShell is a very powerful tool to aid any configuration or administration of infrastructure and systems, but you need to make sure you know what the PowerShell cmdlet are setting, you ask it to set something, it will set it!, it maybe not the desired setting you think it’s going to set, just make sure you check what you’re trying to set and what you’re running is applying the correct setting.

Disclaimer: All scripts and other PowerShell references on this blog are offered "as is" with no warranty.  While these scripts are tested and working in my test environment, it is recommended that you test these scripts in your own test environment before using in any production environment.