One of the critical tasks ahead for on boarding your organization to Microsoft’s Office 365 (O365) will be to determine your identity strategy. In fact, whether your on boarding to O365 or not, having a strategy in place will help determine the path to take when and if you decide to take advantage of Microsoft’s Software As A Service (SaaS) model encompassed by the capabilities in O365.
Early on, either during a Fast Track Pilot (Pilot –> Deploy –> Enhance) or a pilot you may run yourself, you will want to get up and running as quickly as possible to experience all that O365 has to offer. Often that means creating separate ‘Cloud Accounts’ (In Cloud) that have no coorelation to the Active Directory accounts used within your organization.
Later, as you move through to Step 2 Deploy of Fast Track or the next step in your own project plan, you will want to enable the use of your own organizational identity. This isn’t Single-Sign-On (SSO), but a simple way to duplicate/replicate your organizational identity to O365/Windows Azure Active Directory enabling things like account and password synchronization. It is also a prequiste for true SSO with Active Directory Federation Services (AD FS). To do this you will employ the use of Windows Azure Active Directory Sync (WAADS) affectionally known as DirSync from its downloadable executable name – dirsync.exe.
Often customer take a shortcut in implementing WAADS by installing the components (Forefront Identity Manager 2010 R2 or FIM) onto a Domain Controller (DC) which became a supported scenario last year by Microsoft. For smaller organizations this might be the only option when server resources are in short supply. Later as they grow or are able to invest in an additional resources the desire to create a dedicated WAADS machine (physical or virtual) becomes desirable. However, moving and removing WAADS from the DC can be a little tricky and is not documented on TechNet by Microsoft at this time.
What follows is a set of steps that can be followed to accomplish this task – keeping your current FIM Filtering in place and reusing you’re existing WAADS service accounts that get created during installation.
You have a single ADDS forest tied to a public domain and two domain controllers DomainDC1 and DomainDC2. Originally WAADS was installed on DomainDC1 and now you want to create a new member server DomainDirSync and move the existing implementation of WAADS to this machine from DomainDC1. Keep in mind that WAADS/DirSync is also filtering by OU.
- Create the new DomianDirSync machine/VM w/Windows Server 2012 R2.
- Join DomainDirSync to Forest.
- Stop or disable WAADS/DirSync on the existing DomainDC1.
- Install WAADS and import the exported settings from the DomianDC1 to DomainDirSync machine/VM
- Uninstall WAADS/DirSync from the DomainDC1.
- Clean up domain service account(s) created by the installation of WAADS/DirSync on DomainDC1.
- Clean up the uninstall process of WAADS/DirSync on DomainDC1.
Backup your existing FIM (formerly MIIS) settings:
On DomainDC1 start the MIISClient “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe”
Select File –> Export Server Configuration… and create a folder to save off the FIM settings. You will import these settings to the newly created DomainDirSync machine once dirsync.exe has been installed and configured there. NOTE: Be prepared to keep track of where you saved this exported configuration and copy it to the DomainDirSync machine later.
In Active Directory Users and Computers, on DomainDC1 or any other DC look for an make note of the names of two accounts:
Why? One of these accounts will get disabled and later deleted (AAD_) as they are the service accounts being used by WAADS/DirSync instance running on DomainDC1 which we are going to replace. MSOL_ will get reused if we import our prior settings. Note that two new accounts will be created when building DomainDirSync. The MSOL_ and AAD_ accounts. The AAD_ account will no longer be a domain account, but a local machine account on DomainDirSync. The MSOL_ account that gets created in domain will ONLY be used if we don’t import our prior settings and reconfigure our AD Filters in FIM manually. If we import our FIM Filters, then we will get prompted for our original MSOL_ accounts password. If you don’t know the MSOL_ account password, and most likely you don’t, you can set it in Active Directory Users and Computers now.
Next, build DomainDirSync using Windows Server 2012 or Windows Server 2012 R2 (See References section below for details.) NOTE: You will need to enable the .NET 3.5 Framework feature and run Windows Update to get .NET 3.5 SP1 installed prior to attempting to install dirsync.exe.
Install dirsync.exe, but DO NOT launch it. It’s OK to Configure it, but we don’t want to execute a Sync until we’re done importing the exported configuration (above). We will need to import the exported server configuration (above) and disable the Windows Service on DomainDC1 that is used by the FIM 2010 R2 (Windows Azure Active Directory Sync Service) so that DomainDC1 is temporarily disabled from synchronizing with O365.
When the install is finished you can start the Configuration.
Not being a tutorial on how to install DirSync you’ll follow the steps you did before including entering your O365 Global Administrator account credentials, your Active Director Domain Account credentials, most likely enabling Password Sync (checkbox).
WARNING: Uncheck the Synchronize your directories now checkbox!
Now, before executing a sync we need to stop the WAADS/DirSync Windows Service on DomainDC1. To do this use Administrative Tools –> Services, look for and stop the Windows Azure Active Directory Sync Service.
While in Services you’ll notice that this service runs under a domain account that begins with ADD_. We won’t need this account any longer once we uninstall WAADS/DirSync from DomainDC1. Also note that there is another account in the domain that begins with MSOL_ and again you NEED to know this account and it’s password. If you don’t know the password (as already mentioned), then just use Active Directory Users and Computers on DomainDC1 to set it to something you know.
Now that the new machine or VM, DomainDirSync is ready to go, let’s import our exported settings from DomainDC1 (at the very beginning of this post). Copy the folder over to DomainDirSync and as before start the MIISClient “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe” on DomainDirSync.
To import, Select File –> Import Server Configuration… and when prompted put in your OLD MSOL_ accounts password (the one you set earlier, you did set it right?) to finish the import process.
Finally we can execute a manual WAADS/DirSync with O365 by executing manually a Start-OnlineCoexistenceSync from the FIM PowerShell “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1”.
We should see a full sync occur and everything should be working normally again. Last, but not least you need to disable / delete the newly created domain MSOL_ account and the old ADD_ domain accounts leaving the original MSOL_ account in the domain.
Then, finally, we can uninstall Windows Azure Active Directory Sync from DomainDC1. When you do, you’ll have to manually delete the C:\Program Files\Windows Azure Active Directory Sync\ folder and its contents, since the uninstall fails to do so.