Use Exchange Online Management to Update Active Directory Recipient Objects

Updating On-Premises Recipient Objects After Removing the Last Exchange Server

In the Exchange Server 2019 H1 update, Microsoft finally introduced a supported capability to remove your last Exchange Server along with a cut-down set of PowerShell cmdlets to manage Exchange Online-related attributes in Active Directory.

If you missed it, check out my article for more detail. In short, Microsoft has stated for many years that after you migrate your last mailbox to the cloud, you had to keep at least one Exchange Server for recipient management if you synchronize Active Directory to Azure AD. The Exchange 2019 H1 updates deliver a set of standalone management tools for ongoing recipient management, along with guidance on how to remove the last Exchange Server.

But what if you didn’t follow Microsoft’s advice and chose to remove the last Exchange Server before it was supported? At Practical 365 we’ve had a lot of questions from folks asking what to do in this scenario.

The problem that you might need to solve

Prior to having a supported way to remove the last Exchange Server, every time I’ve discussed this with folks in person, at conferences, and online – someone will come out and say that they’ve done this and had no problems at all.

In general, people who went ahead and removed the last Exchange Server early fit into three categories:

• Bought a third-party tool, supported by an ISV, that manages the attributes in Active Directory that relate to Exchange Online, that comes with a support contract for when things go wrong.
• Managed Exchange for many years and know it intimately – and carefully create, test, and maintain PowerShell scripts (or an in-house provisioning system) that will manipulate exactly the same attributes as the management tools would.
• And folks who noticed by trial and error that they could add email address attributes to an Active Directory object, sync and license it online, and a mailbox would be created.

If you fit into the first two categories, then you most likely are not worried about the management tools; if you use a vendor’s provisioning system then you can ask when they’ll use the supported Microsoft approach. If you carefully maintained scripts that create and update objects that are identical attribute-to-attribute to the Exchange Management Tools, then you’ll know you are fine.

Folks in the last category – do have a problem. Often it isn’t of your making. Perhaps the consultant who did this wasn’t aware of the ramifications of doing this, and now they are long gone, or it was a long-departed member of the team. If you did it yourself then at least you know who to blame and if you’re reading this, you probably learned that it was a bad idea.

What happens if you install the Exchange 2019 H1+ management tools?

The first part of getting to a remediated state where you can use officially-supported management tools without an Exchange Server is installing the tools themselves.

If you stripped out the last Exchange Server prior to installing Exchange 2019, then you’ll need to follow Microsoft’s steps that include (as part of running setup) performing Active Directory and Schema preparation for an Exchange 2019 installation.

Exactly how you removed that last Exchange Server will be important here, because in most cases, you will not have uninstalled it – and instead switched it off and eventually deleted the machine.

If this was an Exchange 2013 or 2016 server, then you are in relative luck, but if you were running Exchange 2010 or earlier when you switched it off, then you will need to consider what to do next. You will most likely need to re-install a server running the Exchange version that you were on, then re-attach or manually remove any orphaned objects (like Public Folder database references) before implementing the latest supported version of Exchange that you can move to.

For example: If you were running Exchange 2007, migrated to Exchange Online, then switched off the server & wiped it, then you’ll most likely need to:

• Implement/recover an Exchange 2007 server
• Implement an Exchange 2013 server, upgrading the organization in the process
• Then decommission Exchange 2007, so that you can install the Exchange 2019 schema
• Install the Exchange 2019 H1 management-only tools, then follow Microsoft’s guidance on removing the last Exchange Server (the Exchange 2013 server at this point).

After installation of the tools, you then need to tread extremely carefully.

The installation of the tools shouldn’t cause any issues. The installation of the tools does not perform actions such as email address policy updates, or changes to recipients.

Once you do have the tools installed, you should avoid making any changes with the tools until you have checked that your recipient objects are either in a well-supported state or have made plans for how to remediate the recipient objects using the management tools.

Recipients will have the most problems

OK – so implementing two Exchange Servers so you can use some PowerShell cmdlets wasn’t the sweetest pill to swallow. Honestly though – it’s firstly not that hard and secondly not anything unexpected.

What is unexpected – by the management tools – is potentially the state of the recipient objects, like Remote Mailboxes, Mail Users, Distribution Groups, Email Address Policies, and Contacts.

The management tools work on the assumption that you followed Microsoft’s guidance and used the supported tools, or that your vendor/PowerShell scripting genius did everything by-the-book.

You’ll know that you have work to do if running a cmdlet such as Get-RemoteMailbox does not provide the same list of mailboxes that exist as Active Directory users and Exchange Online mailboxes in the cloud.

The most common scenario described I meet is that people see output from the cmdlet for mailboxes that were moved from on-premises Exchange, but not for folks who joined the business afterward and have only ever been in Exchange Online.

This isn’t an expected result, as all Active Directory users who have mailboxes in Exchange Online should be shown.

The same may be true for Contacts, Mail Users, and other recipients – the problems often begin when someone decided to throw caution to the wind and do it their own way because it seemed to work.

Solving Issues

To understand what you need to remediate, you will first need to see how many Active Directory objects (such as users) are affected, then check these objects to see if the same approach was used, or if it varied. If it is the same – for example, the proxyAddresses and mail attributes are all completed, but other attributes are missing – that is good news. If it is inconsistent, then you have more work on your hands to bring things to a consistent state before attempting to finally solve the issue.

If we go with the example of an object that has the correct mail and proxyAddress attributes, then the core remediation steps should be as follows:

• Use the Enable-RemoteMailbox cmdlet, with the existing -PrimarySMTPAddress value and -RemoteRoutingAddress parameter to update the user so that they have the Exchange attributes required stamped onto them.
• Then immediately update the Remote Mailbox using Set-RemoteMailbox with the -EmailAddresses parameter (and potentially – EmailAddressPolicyEnabled set to false) so that the existing email addresses are re-stamped onto the object.

Of course, this could be the tip of the iceberg – users converted to Shared Mailboxes in Exchange Online (and as such, don’t appear any different when examining your local Active Directory) are a particular point of note. Purely because managing recipient attributes without Exchange is unsupported, there isn’t a consistent way that people have done this.

Therefore, it is crucially important to ensure that you back up Active Directory attributes before making changes; and to export the equivalent Exchange Online attributes for mailboxes. Use a test environment where possible, and absolutely use test users and mailboxes that match each different type of recipient configuration you encounter.

When you do make changes, consider moving Azure AD Connect into staging mode so that you can examine the changes that it will push to Azure AD (and Exchange Online) from your local Active Directory.

And finally – feel free to ask questions as comments below and we’ll do our best to answer & help. But – be forewarned there may be costly Microsoft or competent partner assistance that you’ll need to fix things; sometimes the comments section on a website won’t be enough to cover your back if things go wrong…