Hello world! I’ve had a rather average run of late with a severe cold. I’ve been out of action of over a week from work and the lovely Sydney weather but more importantly I’ve hardly had the energy or brain power to write any blog posts. I’m not on the mend thanks to antibiotics (which I haven’t had to take for maybe 15-20 years) and I’m back on deck with my head in the clouds- pun intended. The following post I began writing several weeks ago in August 2015 but now in mid September I can put it out. Enjoy!
Today is back to AAD Connect. I want to talk about Office 365 migrations and how they can be tricky with various options and scenarios around hybrid or non hybrid. On a recent project we were migrating a client from IBM Lotus Notes to Exchange Online in Office 365. The plan and proposed solution was designed to not use Exchange Server Hybrid on-premises and use Dell Software Migrator for a direct migration from on-premises to the cloud.
The client has never had Exchange Server on-premises before and was running a well-managed ADDS deployment spanning three sites across three continents. To allow for the schema requirements for Exchange Online, Exchange Server 2013 was downloaded and the ADDS schema was extended with that from Exchange Server 2013. All simple, standard stuff right?..
Dell Software Migrator required several ADDS attributes to be sync’ed with Azure AD and Office 365 services like Exchange Online. I had deployed AADConnect after the Exchange 2013 schema update had occurred. However, It seems that the Exchange 2013 schema update to ADDS had not finalised completely or replicated to all domain controllers when AADConnect was deployed. AADConnect did not have the “targetAddress” attribute available. A bit of a rookie mistake as they had ADDS replication scheduled for every 15min. Although in my defence, AADConnect was in the same site as the PDC and core DC’s that had the schema extensions applied. Regardless, lets move onto how I found the issue and fixed it.
This is a little technical and requires a few steps to check, so I’ll get straight into it. On the Active Directory Domain Services connector and the Windows Azure Active Directory (Microsoft) connector, I ran a Refresh Schema commend via the right hand menu. The targetAddress was now visible to both connectors.
A schema update and manual Full Import and Full Synchronisation process and still no targetAddress syncing to Exchange Online. This required further investigation. While I thought the problem had been resolved, I put on some classical mood on Spotify and enjoyed the fat lady singing. It was a little too soon for a celebration though (when working I do rather like to listen to classical).
Music aside, checking the rules indicated that targetAddress was indeed now available, however, this attribute was not ticked to allow replication to Azure AD. I checked and updated the following attributes in the sync rules:
Active Directory Domain Services connector
Windows Azure Active Directory (Microsoft) connector
After these changes and a manual sync process contacts were still not syncing correctly. However, as has been the case recently, it’s just not that simple. The targetAddress in EXO / AAD was still not being set. I did some relevant investigation into this both online and asking the brains trust at Kloud. From what I’ve found is that the targetAddress field should change to the ExternalEmailAddress field in EXO for contacts, or mirror in this field while the actual targetAddress field remains hidden from Powershell or online console view.
Reading online didn’t prove fruitful at all. I spent a considerable amount of time on that only to find that there’s really a lack of information on in-depth or hardcore sync engine configuration. However, as always when you’re backed into a corner and need figure something out, I had the eureka moment when I carefully looked at AADConnects SyncRuleEditor.exe. Here’s the process I completed to check the rules AADConnect uses to grab the data from ADDS and replicate to AAD:
I checked all the rules that were related to Connector Object Type: Contact. I found that some were indeed missing a key attribute: targetAddress. EUREKA again! I then reviewed everything that made sense logically and came up with the following list of changes I made to add in the targetAddress field:
Thanks to Sean from Ohio who sent through an email sending some thanks back for the blog post. Awesome to hear that it got him on the path to have his co-existence environment up and running. He did mention though that he:
“had to change the ‘User’ object type instead of ‘Contact” in the SyncRulesEditor. One I did this, everything synced properly”
He said it was cool for me to update the post incase anyone else needs to do that same to get their instance of Azure AD Connect up and running. If anyone else has any updates or personal experiences with what you needed to change re targetAddress: it would be great if you shared in the comments below.
Azure AD has only a certain amount of attributes that it will accept. Azure AD is not a direct replica of on-premises or a traditional Windows Active Directory. It’s one of the reasons why you wouldn’t find a group policy feature (yet?) or the ability to edit ADSI attributes (yet?). Simply wanting any piece of software or app to use attributes on Azure AD again isn’t always available. The following list has all the available Azure AD attributes for reference:
I’ve deployed AADConnect a hand-full of times in recent months since it’s become GA. Each time almost there’s been something that’s come up and results in some investigation. Each issue though has been very much independent of one another. That’s both good and bad in that it’s a good from a learning point of view and bad from my greying hair point of view. I definitely feel its becoming time to start dying to maintain these boyish good looks.