When helping our clients with Office 365 deployments, we sometimes find that DirSync has been associated with a trial tenant that is about to expire and/or was originally created with a provisional name, or similar. In any case, a public DNS name can only be verified once in Office 365, which associates that namespace with the Office 365 and Azure AD tenancies. So if we want to move DirSync (which is also a prerequisite for ADFS) to a new tenancy, then we need to back it out from the first tenant and re-associate it with the second. Unfortunately, that process isn’t exceptionally quick, but there are some manual steps that you can carry out in order to accelerate the change. As we do this more often, our list of things to check is growing, so this list may change, but this is where we’re at today. Please feel free to comment if you feel we’re overlooking anything.
To get started, I chatted with my Office 365 guru colleague Liam about the specific steps and sequence. I found a few interesting twists with my client, so I’ve put a high level set of steps together here in the interest of saving some time next time we come across this. I hope it’s helpful.
- Export your Management Agent configuration from the FIM Synchronisation Manager if any filtration or Container selection has been carried out. It may also be wise to screenshot Container selection.
- Open PowerShell from wherever you normally administer your Office 365 tenant and Connect-MSOLService.
- Run Set-MSOLADFSContext -Computer <Primary ADFS Server> to establish a connection with ADFS (if applicable).
-
Run Convert-MsolDomainToStandard -DomainName <PublicDNSName> -PasswordFile <UNCPathWherePwdFileShouldBeCreated> -SkipUserConversion:$false.
- Note: in my most recent work, this step failed part-way through the password creation step, but since I was about to delete the accounts I proceeded and didn’t have any issues. You may opt to use different -PasswordFile and -SkipUserConversion settings accordingly.
- Confirm that the Microsoft Office 365 Identity Platform Relying Party Trust has been deleted in ADFS.
- In the Office 365 Administration Portal, navigate to User and Groups and Deactivate Active Directory synchronization (towards the top of the page, beneath the Single sign-on status).
-
Delete the DirSync’d user accounts either from the Office 365 Portal Users and Groups page or use Remove-MSOLUser –userprincipalname <UPNOfDirSyncUser>
- This bit can no doubt be enhanced with a manifest or some other intelligence, but when we’ve been carrying this out so far the first tenant doesn’t normally have a load of accounts, even if the new one will.
-
Delete the just-deleted accounts with Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force
- DirSync should now appear to be inactive in the Office 365 Administration Portal.
- At this point, the DirSync and user account-specific work is complete, but other remnants of these identities may persist. They will need to be cleaned up.
- This article from Microsoft provides some good tips on other areas to check and syntax for clean-up.
- In my most recent work I had to delete Groups and Contacts. I manually deleted them in the Exchange Admin Centre.
- I also needed to wait a few minutes for the effect of these changes to allow removal of the domain.
- Remove the domain from the tenant in the Office 365 Administration Portal or with Remove-MsolDomain -DomainName <PublicDNSName>.
- Close and re-open PowerShell.
- Get credentials for new tenant.
- Run Connect-MSOLService with the new tenant administration credentials.
- Run Get-MsolUser (or anything else) to confirm connectivity and confirm you’re connected to the right one.
- Run Set-MSOLADFSContext -Computer <Primary ADFS Server> to establish a connection with ADFS (if applicable).
-
Run New-MsolFederationDomain -DomainName <PublicDNSName> if you will be using ADFS. Otherwise use New-MsolDomain.
- Copy the TXT or MX record value from the Warning message and make the change in public DNS. This will be a different value than the old record.
- Wait for DNS verification.
-
Run New-MsolFederationDomain -DomainName <PublicDNSName> or New-MsolDomain again.
- Confirm that the Microsoft Office 365 Identity Platform Relying Party Trust has been re-created in ADFS.
-
Run Set-MsolDirSyncEnabled -EnableDirSync $true.
- Activate Active Directory Synchronisation in the Office 365 Administration portal (I’m not sure why this step is necessary after running the PowerShell above, but it appears to be.
-
Re-connecting DirSync can take “up to 24 hours” to complete, but in my most recent experience it took about an hour. I’m impatient, so I ran this PowerShell to notify me when it completes:
- For ($i=0; $i -lt 60; $i++) { (Get-MSOLCompanyInformation).DirectorySynchronizationEnabled; sleep 30; }
- This could definitely be made even more clever with e-mail notifications etc., but this is a start for me. It checks the configuration every 30 seconds.
- Find your Enterprise Admin and new tenant administrator so they can enter their credentials during DirSync re-configuration.
- Run the DirSync Configuration Wizard. Don’t run synchronisation immediately if you’ll be filtering accounts.
- The original filters should still be in place, but in case they aren’t you have the backup information we gathered in step 1.
- Run Start-OnlineCoexistenceSync once filtration is configured.
No doubt this will grow and improve over time, but it can hopefully help get started. Big ups to Liam for his help.
A great article; I reviewed it the last time I had to move SSO services between Tenants, and found it spot on for my needs.
For reasons that I cannot explain, I’ve found that I have to uninstall and reinstall the DirSync service entirely; otherwise after re-running the DirSync configuration, I get various Windows Internal Database errors. I haven’t found a cogent explanation, and I’ve had only two opportunities to do this, but something to bear in mind. I also found that I had to restart my ADFS / ADFS Proxy servers (again, this makes no sense to my mind, but whatever, if that’s what it’s going to take… I’ll do it!)
Some of the errors I was getting before reinstalling DirSync, just to help anyone with the same issue who may be Googling…:
Directory Synchronization: Event ID 109 (error code 78, “cause not clear”)
FIMSynchronizationService: Event ID 6803 (“server encountered errors”)
MSSQL#MICROSOFT##SSEE: Event ID 17137 (“AdfsArtifactStore” The specified resource type cannot be found in the image file)