Exchange 2013 impact on legacy OAB settings


Much has been written about the new and changing ways OAB (Offline Address Book) generation in Exchange 2013 works: RTM process, CU5 process, and now CU7 process. However, I want to remind everyone of what happens when you go to install Exchange 2013 in a legacy (2007 or 2010) Exchange environment. This was also covered in the CU1 information, but many of you are not thinking of those steps from way back then.

If you have any Exchange databases in the organization that do not have an OAB defined, then once the first Exchange 2013 server is up and running, every client that has a mailbox in an undefined OAB DB (Database), will download the OAB. Yep, download the entire OAB. Couple this with most engineers building out a pre-production server during the day, and you can have potentially some big impact to client experiences and network bandwidth.

There is an extremely easy way to prevent this out of control OAB download from happening. Before you go to install your first Exchange 2013 server, just set all DB’s with an OAB value. And of course, our friend PowerShell (PS) can help. While some organizations may need to set OAB’s on DB’s for specific locations or regional areas, most companies just use a single OAB source. So setting all DB’s to the same default OAB value is usually an option.

To see which, if any databases don’t have an OAB set, run this PS within the Exchange Management Shell (EMS):

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

This command says to get all mailbox databases, filter that result down to where just the OAB attribute value is null (empty), then format a table view with the name of the DB and the OAB value (which would be null). To set all null valued DB’s to the default value, our friend PS is leveraged again:

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

This next command then takes all of the DB’s with null OAB values, sets those specific DB’s OAB attribute to use the current default OAB and write that default value to the DB’s filtered out in the get portion of the one-liner.

To confirm this second cmdlet has run and set the values for the OAB attribute, just re-run the first one-liner. (Hint: in the PS shell window, just up arrow on the keyboard to scroll through previous cmdlets that you’ve run.)

To see the current values for OAB settings on all of the DB’s:

Get-MailboxDatabase | FT Name,Of* –AutoSize


Conclusion

There you have it. One more step to ensure you have setup a controlled migration process as you install your new Exchange 2013 environment. We do flag you in the EXRAP toolset, if you have the ability to purchase one of these engagements from Microsoft. No need to have users impacted when you do have the ability to control the environment. For additional steps on how to migrate, don’t forget to visit the ExDeploy2013 website.

Comments (2)

  1. If I set all DB’s parameter OfflineAddressBook to $Null – will Outlook clients use online GAL instead of OAB?

    (Pls, correct typo in "… the ExDeloy2013 website …")

  2. Mike_O'Neill says:

    No. A $Null value will have all clients re-download the OAB files, in cached mode. The Exchange value does not update the clients on which version of the AB to use.

    However, you bring up an interesting point, if all clients are in online mode, or if you regedit your client machines to only use online AB info (http://support.microsoft.com/kb/841273), then a $Null value
    should not have any impact on the clients, and therefore, no impact to re-download the OAB since the OAB is not being used.

Skip to main content