[UPDATED] Azure AD Connect: SyncRuleEditor.exe and why is targetAddress missing

Originally  blogged @ lucian.blog. Follow Lucian on Twitter @LucianFrango. Send Lucian an email.

---

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?..

Wait, its not over yet!

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
  • Right click and select properties.
  • Go to Select Attributes.
  • Tick Show All.
  • Scroll to the “T” section (in alphabetical order)
  • Tick to add the targetAddress field.

• Windows Azure Active Directory (Microsoft) connector
  • Right click and select properties.
  • Go to Select Attributes.
  • Tick Show All.
  • Scroll to the “T” section (in alphabetical order)
  • Tick to add the targetAddress field.

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.

Further investigation

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:

• Went to C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe
• Note: yes, the path is Azure AD Sync, but this is for an install of AADConnect.
• There are two types of rules: Inbound and Outbound.
• Inbound is for data that is being pulled from on-premises ADDS.
• Outbound is for data that is being pushed to Azure AD.

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:

Inbound rules

• In from AD – Contact join
  • Precedence 108
  • Did not change
• In from AD – Contact Common
  • Precedence 109
  • Transformation added:
    • Direct
    • Target attribute: targetAddress
    • Source: targetAddress
• In from AD – Contact Join
  • Precedence 112
  • Did not change

Outbound

• Out to AAD – Contact Join
  • Precedence 123
  • Nothing changed
• Out to AAD – Contact Identity 
  • Precedence 124
  • Transformation added:
    • Direct
    • Target attribute: targetAddress
    • Source: targetAddress
• Out to AAD – Contact ExchangeOnline 
  • Precedence 125
  • targetAddress alright in here, so nothing to change.
  • Protip- just double check anyway
• Out to AAD – Contact DynamicsCRM
  • Precedence 126
  • Transformation added:
    • Direct
    • Target attribute: targetAddress
    • Source: targetAddress
• Out to AAD – Contact Intune
  • Precedence 127
  • Transformation added:
    • Direct
    • Target attribute: targetAddress
    • Source: targetAddress
• Out to AAD – Contact LyncOnline
• Precedence 128
• Transformation added:
  • Direct
  • Target attribute: targetAddress
  • Source: targetAddress
• Out to AAD – Contact SharePointOnline
• Precedence 129
• Transformation added:
  • Direct
  • Target attribute: targetAddress
  • Source: targetAddress
• Out to AAD – Contact AzureRMS
• Precedence 130
• Transformation added:
  • Direct
  • Target attribute: targetAddress
  • Source: targetAddress

UPDATE on 2015-09-23

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.

Further reading

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:

http://social.technet.microsoft.com/wiki/contents/articles/19901.dirsync-list-of-attributes-that-are-synced-by-the-azure-active-directory-sync-tool.aspx

Final words

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.

Thank you, Lucian

---

Originally  blogged @ lucian.blog. Follow Lucian on Twitter @LucianFrango. Send Lucian an email.