Hey folks! Pure Awesomeness here!
Hope you’ve all been staying healthy and safe during these uncertain times. I know, I know…It’s been a while since my last blog but I’m back…back once again to deposit as much knowledge and wisdom as one individual with the title of Pure Awesomeness can, whilst maintaining social distancing and carrying on with self-isolation.
So, my last blog was all about the new concept of syncing identities using Azure AD Cloud Provisioning. With this blog, I thought I’d keep it to a similar topic and talk to you about the fun and games Microsofttenant to tenant migrations can bring to the table, especially around the identities and domain removal. OK, not really a similar topic but if you saw the lack of hair on my head, you’d be forgiven for thinking I’d pulled them all out as a result of my latest tenant to tenant adventure.
So, what happened on my latest tenant to tenant adventure which has resulted in writing this blog? Well, before I tell you, I need you to sign up to Insentragram! Oh, come on, this is basically standard practice with all of my blogs 🙂
Now, ensure you’ve checked off all of the requirements below:
- Signed up to Insentragram
- In possession of a cup of liquid gold, aka coffee
- Do the Evan Almighty happy dance because Microsoft is increasing the Teams video tiles to 49!
HERE WE GO!
It all started a few months ago when I was assigned a new project where I had to migrate content out of an Office 365 tenant located in Europe to an Office 365 tenant located here in Australia. Only a handful of Office 365 services were in use in the source tenant so as a whole, the project didn’t look too complex (famous last words!).
What happened I hear you ask?
Well, in any tenant to tenant migration, not only is your identity model key, but you also need to make sure the domain(s) you need to remove aren’t tied to any services in the source tenant. If that domain is tied to even a single object, such as a distribution group, you can forget about removing the domain from the source tenant. The tenant gatekeepers won’t allow it.
In my scenario, even though Exchange Online wasn’t being used in the source tenant (phew!), the domains I needed to remove were tied to the proxy addresses of the synchronised identities. What does the proxy addresses have to do with anything given Exchange Online isn’t in use? Well, here’s where the fun begins!
Outside of a few distribution groups which were removed, the issue I had was with Mail User objects (not Mail Contacts) and proxy addresses. Keep reading to find out how these two staples of the Exchange Online world can impact a simple task such as a domain removal.
msExchMailboxGuid
If you’re running an on-premises Exchange organisation, every account with an on-premises mailbox has a unique attribute called the msExchMailboxGuid. In an Exchange Hybrid world, this attribute tells Exchange Online there is an on-premises mailbox and not to provision a mailbox until cutover is complete. This bad boy is also responsible for creating Mail User objects in Exchange Online (these come in to play in the Exchange Hybrid world).
Another thing to note is that when you install Azure Active Directory Connect (AAD Connect), by default, this attribute syncs to Azure AD, creating the Mail User objects. These objects are stamped with the proxy address attributes of the corresponding on-premises mailbox and these aliases are tied to the domain you need to remove. You can’t delete these objects from Exchange Online as they’re synced from on-premises and for obvious reasons, you can’t delete the mailbox. So how do you get around this?
You’ve come to the right place my loyal apprentice…
There’s two ways you can remove the Mail User object without impacting the synced identity or the on-premises mailbox:
- Attribute filtering from within AAD Connect
- Custom AAD Connect synchronisation rules
The easiest approach is option 1, so within AAD Connect, unselect the check box for msExchMailboxGuid and click OK.
Then you’ll be presented with the below heart stopping warning (it’s not that bad I promise).
Just click OK.
Next, run a server to push the changes up to Azure AD.
Please note that the full sync can take some time to complete, depending on the number of objects and attributes you are syncing and any changes which are made during the sync won’t appear in Azure AD until the next sync cycle.
Once the sync cycle completes, you will notice Mail User objects start to disappear from Exchange Online, but the corresponding Azure AD identities remain untouched. Trial this out in a lab environment. The downside to this approach is that there is no way to stage this – it’s all or nothing.
So, that takes care of the Mail User objects but, yes there’s always a but…you’ve still got proxy addresses to take care of.
Proxy Addresses
Back to my scenario…Even though I tried to remove the domain, it was still tied to the Azure AD proxy addresses, so, by default, the first thing I tried was to filter the proxyAddress attribute from AAD Connect (same approach as the msExchMailboxGuid). I ran a full sync and BINGO (just kidding) … it did not work! All related articles lead me down the path of removing the proxy addresses at the on-premises mailbox level (which I didn’t want to do) so, I decided to log a support ticket with Microsoft to see if there was another way…I mean…there had to be!
Turns out, there isn’t. As it stands now, there is no way to filter the proxy address attribute from an Azure AD synced identity without impacting the on-premises mailbox. So, what do you do? I can almost hear a pin drop as you all wait in anticipation for the answer.
So, What’s the Answer?
The only way forward (and it’s not pretty) is to assign Exchange Online licenses to the identities, let the mailbox be provisioned and then remove the license. This approach strips away the proxy addresses and leaves only the onmicrosoft.com domain as the only remaining proxy address. Remember, this approach is only possible because I’ve removed the Mail User object and I’m not syncing the msExchMailboxGuid anymore.
Depending on the number of identities to apply the license to, it may be best to script this or if licensing allows, use Group Based licensing.
Back to my scenario…once the proxy addresses were removed, I was now able to successfully remove the domain from the source and register it in the target tenant. #winning
As the title of this blog suggests, it was definitely a battle with the proxy addresses and trying to get these removed!
Until next time, Pure Awesomeness signing off.
“The greatest glory in living lies not in never falling, but in rising every time we fall.” – Nelson Mandela
