Upgrading to AADConnect…Without the Pain

If you’re one of those people still running the default original version of DirSync or it’s successor Azure AD Sync, it’s time to upgrade to Azure AD Connect!

The latest version (1.1.105.0) was released on 16th February 2016 and can be downloaded here.  It is a major upgrade with a bunch of cool new stuff:

  • 30 minute sync scheduling 
  • Automatic updates 
  • Domain and OU filtering built into wizard (yay!)
  • etc.

AADConnect is the tool which integrates your on-premises identity system such as Windows Server Active Directory with Azure Active Directory and connects your users to Office 365, Azure and 1000’s of SaaS applications e.g. Exchange Online.  In case you are not aware, integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Users can use a single identity to access on-premises applications and cloud services such as Office 365.
  • Single tool to provide an easy deployment experience for synchronization and sign-in.
  • Provides the newest capabilities for your scenarios. Azure AD Connect replaces older versions of identity integration tools such as DirSync and Azure AD Sync.

aadconnectstack2

Doing the Upgrade

On three separate occasions recently I’ve followed the “best practice” upgrade guidance which is to perform an “in-place” upgrade.  Each time it got to the end of the install and died with various errors.

Imagine:  it’s 8pm, you’ve arranged a Production Change with your customer to upgrade their legacy version of ADSync or DirSync to AADConnect.  You hit the download center, grab the MSI and diligently read the prescribed article here. Before you hit install, you will of course have asked the customer to provide you with their documentation on any customization made to the original configurations, the most obvious and widely used being OU Filtering as discussed here. Of course, noone ever documents anything so you’ll have logged in to the MIISClient and checked the Containers configuration and taken screenshots for yourself. Make sure you do not skip this step.  Let me illustrate why.

The in-place upgrade copies the current configuration and leads you through what should be a painless procedure without the need for manual intervention or porting of configuration files etc.  That’s assuming it works. As I stated above, in my last three attempts – upgrading from both DirSync and ADSync various version numbers – the upgrade has failed.  The wizard gets to the end of the road and has provided various flavors of error message.  Last night at 2am, a reading of the error logfile  stated the following:

Exception Data (Raw): System.Exception: Unable to install the Synchronization Service.  Please see the event log for additional details. —> System.InvalidOperationException: Cannot start service ADSync on computer ‘.’. —> System.ComponentModel.Win32Exception: An instance of the service is already running

The annoying part is that the legacy program directories and even desktop icons are re-branded as “Azure AD Connect”, so first impression is confusion – did it complete or not?  Further reading of the install logfile showed Azure AD Sync to have been completely removed.  A quick check of the connectors showed all configurations disappeared.  Now you have nothing…

Time for a new VM…

Unfortunately, there is nothing that can be done with the legacy installation.  You need to provision a new server (preferably), or uninstall the old version and cleanup.  In all three earlier cases, I had to open a Microsoft support call to find this out.  Forewarned is Forearmed, so last night at 2am I was lucky when the upgrade failed as I had smartly pre-prepared a new VM in advance just in case 🙂

Now follow the process of a net new installation of AADConnect on this new server.  

The sync engine server does not store any state about the objects so the database can be rebuilt from the data in Active Directory and Azure AD. The sourceAnchor attribute is used to join the objects from on-premises and the cloud. If you rebuild the server with existing objects on-premises and the cloud, the sync engine will on reinstallation match those together again. The things you need to document and save are the configuration changes made to the server, such as filtering and synchronization rules. These must be re-applied before you start synchronizing.

The key point here is to ensure that you are able to reflect the original environment in the new environment – aka OU Filtering – as discussed above. Failure to do so will have a potentially disastrous effect on the existing tenant.  (If you don’t understand the implications of this statement then you shouldn’t be near that server in the first place).  So make sure you examine the original configuration and customization before trying to upgrade.

That being said you should save yourself the headache to begin with: provision a new target VM and disregard the in-place upgrade.  That’s the feedback i got from the  Office 365 Support Managers.  All will be well in the world once more…you can go ahead and implement Password Writeback which was the original intention last night at 8pm!

 

Advertisements
This entry was posted in Microsoft and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s