Understanding the consequences of improperly decommissioning your on-premises Exchange environment

My setup includes two separate forests, named “demo.loc” and “demo02.loc”. The accounts from both forests are hybrid with the tenant “bennylab.xyz”, and a single ADConnect server is used to synchronize accounts from both forests.

Next, we'll create a new synced user in the target forest. Note that there's no on-premises Exchange server in this forest because it was deprovisioned a few months ago, and the AD schema hasn't been updated since.

To get that account synced with Azure Active Directory as quickly as possible, you'll need to force the synchronization process.

After the synchronization process is successful, make sure to check that everything has been created correctly:

Now, let's assign a valid Microsoft 365 license to that user. This will allow the cloud environment to provision their mailbox.

Note: If I had a valid Exchange hybrid server running in the same environment, I would need to run the “enable-remotemailbox” command before the step of assigning the mailbox. In the process described above, the tenant will immediately provision the mailbox, resulting in a cloud mailbox instead of a remote mailbox.

Once this is done, let's check to make sure the user has the license assigned:

Now, let's check the contents of the user's mailbox. Log in to Exchange Online (mail.office365.com) using the user's credentials and make sure their mailbox is working correctly.

Next, let's connect to the Exchange Online environment:

Now, let's run a “Get-Mailbox” command to get all the details of that user's mailbox. As you can see, the mailbox has been provisioned by the cloud environment, just as we expected:

Here's where the problem arises: let's say you need to change an Exchange attribute of that user account. The primary source environment for this user is on-premises, but the mailbox isn't remote because it was created when the Microsoft 365 license was assigned.

So, to manage Exchange attributes, the only option is to connect to Exchange Online, since the on-premises Active Directory can't manipulate these attributes. Here's where the issue lies:

Exchange Online indicates that the change cannot be made because the source of truth is the on-premises Active Directory (remember, your account is synced). However, the on-premises ADremove attribute isn't available, and there's no on-premises Exchange hybrid available to handle the change.