The “getting rid of old crap” way of moving from ADFS 2.0 and dirsync to ADFS 3.0 and AAD Sync.

This gave me a headache so I need to write this down. The project meant moving an existing ADFS 2.0 and dirsync installation without TMG to a new install made up of ADFS 3.0 and AAD Sync on one server and WAP on one. I started of using Windows Internal Database (WID) for ADFS and SQL LocalDB was installed by AADSync, when importing the configuration from the ADFS 2.0 server the ADFS 3.0 service would not start and gave event error 220, looking at the configuration file for ADFS it looked as I had imported way to much configuration information than I wanted to. I then proceeded to an alternate migration path.

 

After resetting the new ADFS server I installed SQL Server Exress 2014 with tools and configured a default instance on the server so that I didn’t have to be concerned about having both Windows Internal Database (for ADFS) and SQL LocalDB (for AAD Sync). I used the latest version of AAD Connect for the installation since it does most of the job for you.

I started of leaving the external mapping of port 443 for the external dns record fs.customerdomain.com pointing to the old ADFS server and logged in on the old ADFS server. In the ADFS 2.0 server I started “Microsoft Online Services Module for Windows Powershell” as an administrator.

I connected to the customer tenant using the following commands.

The next step was to convert the already federated domain customerdomain.com to a standard Managed domain WITHOUT converting the users to standard users. This was achieved by the following command.

The passwordfile is not created when using the -SkipUserConversion parameter but the command didn’t let me skip it so I just added it anyway. This got rid of the federation configuration for the domain in the Office 365 tenant so the AAD Connect wizard can configure the new federation for the domain to the new servers. The next step was exporting the certificate for fs.customerdomain.com with the private key to a PFX file from the old ADFS 2.0 server and importing it in the Local computer perosnal store on the new, soon to be, ADFS 3.0 server. After that I changed the external mapping of port 443 from the internal IP of the old ADFS 2.0 server to point on the internal ip of the soon to be Web Application Proxy Server. Since I use split DNS I also had to change the internal record for fs.customerdomain.com to point to the internal IP of the ADFS 3.0 server since internal authentication request does not need to pass the Web Application Proxy. I also stopped and disabled the services for the old ADFS 2.0 server and the old dirsync services.

 

After this was done I started the AAD Connect wizard and it worked all the way. Since the customer did not syncronize the whole directory to Office 365 it was important to remember to uncheck the box “Start the syncronization process as soon as the configuration completes” at the end of the wizard and then start the AAD Sync UI and configure the correct OU to syncronize., after that is done you enable the task for AAD sync in scheduled tasks.

aadconnect2

You may also like...