I had a situation recently where I wanted to shuffle my labs around as I’ve changed jobs and also got access to a new Azure subscription as part of my MVP award. I decided to bite the bullet and just start again as it had been a while since I changed my lab around and in the words or Satya Nadella it was time to Hit Refresh.

The only thing I wanted to take over was my domain name in Azure AD. But in this case as it’s a lab I seem to have mislaid the server I was using for Azure AD synchronisation during one of my many ‘playing around’ sessions. That, it seems, is a bit of a problem. In order to delete the domain name from my Azure AD I need to make sure there’s nothing reliant on it. I’d already switched my primary domain around so it was no longer my ‘vanity’ domain. But, in my case the users were synchronised from an AD using Azure AD Connect and I didn’t have any access to that AD Connect to ‘un-synchronise’ them.

You can see here that if I select the domain and try and delete it…

I actually get thrown a warning as described and the Delete button is greyed out

You can click on each warning and it will highlight the user accounts and groups that you have using that domain.

Now, as is often the case with Microsoft, all is not what it seems and you can do more in PowerShell than you can in the console. We have the capability to force a disable on directory synchronisation through the MSOnline PowerShell module. So here goes…

First you need to import the PowerShell module for MSOnline.

Import-Module MSOnline

Now you need to connect to the Microsoft Online service.

Connect-MsolService

Now complete the authentication challenge. You will need to use an account with global admin in the directory.

Now you’re connected in through PowerShell you can make a check on the current directory synchronisation status.

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Now you can change the directory synchronisation to false.

Set-MsolDirSyncEnabled –EnableDirSync $false

As this is a change, you will be prompted to confirm.

You should now see an emphatic lack of errors whilst the command succeeds.

If you like, you can now re-run the check and prove that the change was made.

NOW HERE IS THE CATCH

Yes, of course there’s always a catch. This change may take UPTO 72 HOURS to take effect depending on the number of objects you have in your subscription. Keep checking back. In my lab I only have a handful of user accounts so it was actually done in minutes as opposed to hours.

That’s me done. If you want to see how to reclaim the custom domain as I did then check out this follow up post.

/Peter