Mailbox Migration to Exchange Online, Strange error…

Recently I tried to do some mailbox migration tests between my on-premises Exchange infrastructure and Exchange Online in Office 365. The mailbox move/migration should be the simple part on any migration project as you spend all the time ensuring the other parts of the solution are correct. However I queued a new move request recently as I needed a new mailbox in Exchange Online to test some settings in SharePoint Online… The move started, but it failed with the following:

After a number of checks and trying the migrations again still with no joy, I thought I’d remove the user/object from Office 365. Prior to removing the object I connected to Exchange Online via PowerShell and ran:

Get-MailUser –Identity “Affected user email” | FL *GUID*, Ident*

I then moved the users AD Object in my local Active Directory to an OU that was not being synchronised to Azure AD, and performed a full sync. Once the sync had completed I confirmed the user object was no longer in Azure AD, then moved the AD Object back to synchronised OU and perform another sync. After the sync had completed I re-ran the previous PowerShell cmdlet:

So by performing these actions I can see that I managed to get a new object GUID for the this mail user. I then performed a new mailbox migration to Exchange Online which completed successfully.

I will add that my home lab does get a load of abuse, where I test different exchange scenarios, but I do this so I know how to fix issues etc. its very possible I caused this error within my lab when I was doing previous disaster recovery tests. So there is a very good chance that you may never see this error.

I know that this process can be very long especially if your Directory Synchronisation has a lot of objects, so I’ll continue to look if there is another way to resolve this.

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.

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.

Azure Active Directory Sync Issue…

Working on an Azure Active Directory Sync for a client with multiple forests I came across a strange issue. The first forest was setup with password synchronization for the On-Premises AD accounts, stepped through the wizard and did the initial sync to Azure AD. Once the sync was complete tested login to Office 365 using one of the synced accounts and all worked as expected.

The issue came when adding the second AD connection. Disabled the scheduled task, then open the Microsoft Azure AD Connection Tool to use the wizard to add the second AD forest. Once the new forest was added and synchronization was complete I tested the new logins with Office 365, however this time I was not able to use the accounts that had been synched.

After double checking all settings and making sure I’d not missed anything, I checked the connector using PowerShell:

Get-ADSyncAADPasswordSyncConfiguration –SourceConnector ForestB.Domain.com

This reported back that:

Password hash synchronization isn’t configured for this connector

I checked the original connector

Get-ADSyncAADPasswordSyncConfiguration –SourceConnector ForestA.Domain.com

This reported back:

SourceConnector: ForestA.Domain.com
TargetConnector: Tenant.Onmicrosoft.com
Enabled: True

I ran the PowerShell to add password synchronization to the new connector:

Set-ADSyncAADPasswordSyncConfiguration –SourceConnector ForestB.Domain.com –TargetConnector “tenant.onmicrosoft.com – AAD” –Enable $True

Re-checked the AD Connector, which reported back:

SourceConnector: ForestB.Domain.com
TargetConnector: Tenant.Onmicrosoft.com
Enabled: True

Re-ran the synchronization to Azure AD, once completed tested the same login and all worked.

Note: We plan to add another AD forest to this Azure Active Directory Sync installation, so will update if the issue was with this AD connector or all connectors…