In this article, I’ll discuss my experience with upgrading from DirSync to Azure Active Directory Connect and how I ran into some issues after the installation was complete.

DirSync and the Azure AD Connect are data syncing mechanisms that sync on-premises objects with the cloud. Microsoft is ending its support for DirSync in April 2017, so if you haven’t upgraded already, the time has come to migrate to its successor, the Azure AD Connect. The upgrade itself can be performed in two ways: in place or in parallel. “In-place” migration is used in a domain where you have fewer than 50,000 objects. I have used in-place migration.

Before proceeding with any major interventions, I wanted to test the migration in a test domain. Unfortunately, I couldn’t connect to the Active Directory with my Office 365 because I had trial tenant, and migration is only possible with the public domain. So every time I tried to connect, I was getting error code 15, as seen in the screenshot below.

The only solution to this problem was to have a registered domain and to try to pull off the migration directly in the production domain. Needless to say, this isn’t the wisest thing to do and is certainly not a best practice.

While doing the upgrade in the production domain, I came across a few problems. The installation itself went rather smoothly, however, after the upgrade the sync service didn’t start and sync the data. When the Azure AD Connect installation was finally over, it created a local service account in the domain. I went to check the Event Log and this is what I found out:

To tackle this problem, I had to remove the existing encryption keys and generate new ones. I ran the misskmu.exe in the C:\Program Files\Microsoft Azure AD Sync\Bin. I was prompted to enter the username, password, and the domain – then an error popped up, logon failure. I found out that the problem had been in the local security policy: Local Security Policy > Local Policies > User Rights Assignment > Log on as a service.

The thing was, among the security settings, I had to include the service account with which I tried to remove the encryption codes. Once I did that and finished removing the keys, I could start the sync service without any trouble. The only problem was that the synchronization mechanism refused to work. Make sure you start this exe as an administrator! Othwerwise it won’t work.

I went back to check the event viewer and found this log:

• Error while retrieving password policy sync configuration. Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException: AADSTS90014: The request body must contain the following parameter: ‘password’

I assumed that the problem had something to do with the service accounts, and I was right.

The issue was hiding in the synchronization managing console and the settings for the Windows Azure Active Directory and the Active Directory Domain Services connectors: C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe.

In the properties I noticed that the account set for the synchronization had been missing a password. I switched the service account to the one I knew the password for. I did the exact same thing for the connector. After that, the synchronization finally started working properly.

In the end, everything seems to be working just fine and to be honest, I wasn’t expecting any inconveniences that happened along the way. The important thing is that there is always a solution, but sometimes you need to turn every stone to find it. Our upgrade from DirSync to Azure Active Directory Connect went smoothly, as for as the installation goes, however I find it important to point out the fact that I had a hard time grasping the fact that my settings weren’t automatically applied causing the server to suspend active synchronization. Luckily, I was able to find the root cause – in the services accounts. And yet it seems that the simplest things can sometimes turn into complicated matters.