{"id":5897,"date":"2015-08-27T12:00:58","date_gmt":"2015-08-27T11:00:58","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/?p=5897"},"modified":"2015-08-23T23:43:39","modified_gmt":"2015-08-23T22:43:39","slug":"reconfiguring-azure-ad-sync","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2015\/08\/reconfiguring-azure-ad-sync.htm","title":{"rendered":"Reconfiguring Azure AD Sync – rip and replace!"},"content":{"rendered":"

I had an interesting learning experience recently, whilst working with a customer to implement some Microsoft Online services.<\/p>\n

They have an existing AAD Sync installation, although from time to time that stops working when Microsoft changes the IP addresses of the servers that are needed for synchronisation. This is not a recommended configuration – but the reasons why are well-described in David Ross’ post on using a proxy with Azure AD Sync Services<\/a>. To limit the number of IP addresses in their firewall and router configurations, this customer places hosts file entries on the Azure AD Sync server, meaning that Azure AD Sync only uses two IP addresses to find the hosts:<\/p>\n

134.170.172.140 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0adminwebservice.microsoftonline.com<\/code>
\n191.235.135.139 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0login.microsoftonline.com<\/code><\/p>\n

Microsoft publishes a full list of Office 365 URLs and IP addresses<\/a>, together with an RSS feed for changes<\/a>.<\/p>\n

Anyway, to cut a long story short, my customer created a test environment by cloning existing servers into Azure IaaS. I ran IdFix against test directory objects,\u00a0changed the UPN on the user accounts to match the domain we had associated with Office 365 (test.companyname<\/em>.com) and ran the Microsoft Azure Active Directory Sync Services tool (directorysynctool.exe<\/code>) to set Azure AD Sync up with\u00a0the new, test Office 365 tenant. Then I sat back and waited for the changes to sync.<\/p>\n

To my horror, I found that the changes didn’t sync to the test Office 365 tenant, but to production! Running miisclient.exe<\/code>\u00a0confirmed that the original connectors were in place and had had not been changed by re-running the Directory Sync Services tool.<\/p>\n

Unfortunately, because the production AAD Sync server was unable to connect to Azure (due to IP address changes…), we couldn’t force a sync from that server to overwrite the stale directory information, which meant\u00a0late night working was needed to get emergency changes in place and restore service.<\/p>\n

Once the production AAD Sync was up and running again, the live directory data was re-synced to Azure AD and services that relied on this (Intune-managed mobile devices were the obvious ones) started working again.<\/p>\n

As expected, the sync with the correct directory over-wrote the changes from the stale directory and the login names for those users that had changed to @tenantname<\/em>.onmicrosoft.com (because their UPN from the test domain was not valid in the production tenant) reverted to the correct UPNs (which have verified domains in the tenant).<\/p>\n

In the cold light of day, I realised that the issue was not caused by me – the only reason synchronisation from the\u00a0test environment hadn’t over-written the live directory sooner was that the test AAD sync server didn’t have Internet access and then I’d disabled the scheduled task whilst running the Directory Sync Services tool. Once it was enabled it simply did its job – but the key learning point for me is that reconfiguring Azure AD Sync is not as simple as re-running the Directory Sync Services tool and supplying the necessary details – it really needs to be ripped out and run from scratch because directly editing the connectors is unsupported<\/a>:<\/p>\n

Microsoft does not support modification or operation of the Directory Sync tool outside of those actions formally documented.\u00a0\u00a0[…]\u00a0 Unsupported actions include:<\/p>\n