Uninstall Exchange Server 2013 Mailbox Role Fails With OAB Generation Server Error

Background

I recently purchased a new hard drive for server at home. It’s faster than old drives, and is perfect for my Exchange server 2013 virtual machines.  My existing environment consists of one Exchange 2013 CAS and two Exchange 2013 Mailbox servers in a DAG.  I plan to built two multirole servers on the new drive and decommission old servers gracefully.

Build/Remove

I successfully installed two multirole servers name MBX3 and MBX4, and added them into existing DAG. I removed database copies off old mailbox servers MBX1 and MBX2, and made sure they are not owning any databases. I then evicted them out of existing DAG, so Exchange 2013 binaries can be uninstalled properly.

Problem

MBX2 had no issue on uninstall process.

MBX1 was throwing a fit during pre-requisite check with following error message.

“Error: This Mailbox server is responsible for generating an Offline Address Book. Removal of Exchange Server isn’t permitted.

For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.CannotUninstallOABServer.aspx  “

The link takes me to a technet page that has yet to complete.

In Exchange 2010, moving OAB generation server was quite easy. All you had to do is run Move-OfflineAddressBook cmdlet, and wait for AD to replicate.  In Exchange 2013, Offline address book is now generated by a system mailbox. See blog post from Exchange Team here.

First, i need to identify OAB generation server in a DAG environment.

Step 1: Identify the mailbox database hosting organization mailbox with OAB Gen capability.

Use the following command to list the arbitration mailboxes with persisted capability of OABGen and database on which this mailbox is hosted:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “*oab*”} | ft name,database

Step2: Identify the mailbox server where the database hosting organization mailbox is mounted

Use following command to identify active copy of mailbox database:

Get-MailboxDatabaseCopyStatus DatabaseName

The server that where the database is MOUNTED, is the OAB generation server. In my case, it shows the correct server MBX3.

For kicks, I created a new standalone database on one of new server, and moved OAB system mailbox over with New-Moverequest cmdlet. Move was successful, however, the uninstall failed again with same exact error.

Solution

While I can always remove MBX1 manually by deleting it from ADSIEDIT, to take the easy way out, but I decide to check one more place in AD, the properties of each Office Address Book object.  For properties of ” \Default Offline Address Book (Ex2012)”, I see this entry at bottom of the attribute list,

OffLineABServer is still pointing to MBX1. After i manually changed it to MBX3, issue was resolved.

Conclusion

Though this setting was there in Exchange 2010, but move-OfflineAddressBook cmdlet changes it to new server. This is not possible in Exchange server 2013. You can still run the command, but it returns following error,

Hopefully this will be fixed in the feature CU, that Exchange server setup ignores this setting,, and allows un-installation to succeed!

Beware Full OAB Downloads After Installing 1st Exchange 2013 Server in Existing 07/10 Environment

Members of the Exchange 2013 Technology Adoption Program (TAP) have known about this issue for a while & the general public had the potential to figure it out once Exchange 2010 SP3 came out last month which allowed co-existence with 2013 in a lab environment; now the Exchange Team has been very clear about it with this recent blog post today. Actually, a Microsoft Support-led session at MEC was when I first heard about it in detail. So what’s the issue? Basically, you have the potential to experience an organization-wide full Offline Address Book download just as a result of installing the first Exchange 2013 server into your existing Exchange environment.

Background:

The Offline Address Book is used by Outlook Cached mode clients to be able to have offline access to Address Lists as well as some Group Metric data when they aren’t connected to the Exchange Server. For a very detailed explanation from Neil Hobson see the following article from him.

Issues can occur when the OAB for an organization grows to a large size, sometimes in the hundreds of MB. Things that contribute to this size are things like number of recipients in AD, number of distribution groups, populated user attributes, & certificate usage (reference ). It’s important to note that GAL Photos are NOT stored in the OAB. The OAB just includes a pointer to AD where the photo is actually stored (reference ). Fortunately, Exchange/Outlook is smart enough to only download the changes to the OAB instead of the entire thing every day. There are still some circumstances where the entire OAB will be downloaded again, which makes it very important to understand the size of your OAB so you know just how much of your networks bandwidth will be used when all Outlook Cached Mode clients perform a full download (reference ).

So as you might imagine, whether or not clients will perform a full OAB download becomes a topic of concern during an Exchange migration.

Offline Address Books in Exchange 2003/2007/2010 are associated with Mailbox Databases, specifically on the Properties>Client Settings Tab of the Mailbox Database in the associated Management Console:

However, in the screenshot above you’ll notice that the “Offline Address Book” field is blank on this Mailbox Database. This is the case by default with all Mailbox Databases. This is not an issue because any Mailbox Database that has its “OfflineAddressBook” attribute set to $Null by default will use the Default Offline Address Book in the Exchange Organization. This OAB can be seen below:

This means if you have configured multiple Offline Address Books in your environment then you would need to manually specify the additional OAB’s on the Databases you would want to use them; otherwise the default OAB would be used. Simply put, if the value for OAB is blank on a Mailbox Database then it will use the Default OAB. If it is hard-set then it will use whichever OAB you hard set it to. Some customers will hard set this value if they want Mailboxes on specific Mailbox Databases to use a specific OAB. Maybe an OAB that only contains a specific Address List instead of the entire GAL like the example below:

Many organizations just have 1 OAB & as a result have never populated the Properties>Client Settings>Offline Address Book value of their Mailbox Databases. This is where a big issue can come into play during an Exchange 2013 migration, or even if you just want a single Exchange 2013 server in your environment for a test group of users.

Issue:

As the recent Exchange Team Blog post announcing 2013 CU1 states, you need to make sure all of your Exchange 2007/2010 Mailbox Databases have an actual value populated for their Offline Address Book. If they are currently blank, then populate them with your current Default OAB. Nothing will change in the environment as a result of this because they will continue to use their current OAB & continue to only download the OAB changes.

Failure to do this will result in each of these Mailbox Databases switching to use the Exchange 2013 Offline Address Book that gets created during installation of your first Exchange 2013 Mailbox Server. This will result in a Full OAB Download for all of your Outlook Cached Mode clients on these Mailbox Databases; a potentially nasty situation which could bring your network to its knees.

You can see the Exchange Team Blog post in question for steps on how to repoint these databases or just use the following commands which I have taken from the post:

“Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} | FT Name,OfflineAddressBook –AutoSize”

This lists all Mailbox Databases in your environment with their OfflineAddressBook attribute set to $null.

Then run:

“Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $Null} | Set-MailboxDatabase -OfflineAddressBook (Get-OfflineAddressBook | Where {$_.IsDefault -eq $True})”

This command will grab each of these Mailbox Databases & populate the OfflineAddressBook attribute with the value of your Organizations current Default OAB. Effectively changing nothing in terms of client behavior but ensuring that when you install Exchange 2013, each of these Mailbox Databases do not switch over to using the 2013 OAB; at least not until you are ready & can stage this process, maybe one MDB at a time.

Summary:

These steps should be mandatory for any organization considering implementing an Exchange 2013 Server into their existing Exchange 2007/2010 environment.