How Exchange 2013 generates the Offline Address Book
Following
the redefinition of the Mailbox server role, Exchange 2013 changes the
approach to how the Offline Address Book (OAB) is generated. EAC does
not include any options to manage the process of OAB generation or
distribution, so these tasks are handled through EMS.
In previous
versions of Exchange, a specific Mailbox server is assigned the task of
generating the OAB. The first Mailbox server installed in an
organization automatically takes on the generation of the default OAB
and retains it until an administrator reassigns the task to another
Mailbox server. For example, in an Exchange 2010 organization, you can
find the name of the server that currently generates the default OAB
with the following command:
Get-OfflineAddressBook –Identity 'Default Offline Address Book' | Format-List Name, Server
This
mechanism worked very well for small organizations. However, as
organizations expanded to tens or hundreds of servers, perhaps
distributed across multiple geographic regions, it became obvious that
having a single potential point of failure for a critical component
wasn’t a good idea, especially when other parts of Exchange had been
upgraded to become highly resilient to problems. If the OAB generation
server was offline for a period, update files for OAB would not be
generated, and clients would start to operate with outdated
information. This might not be a problem if the OAB was out of date by
a week or so, but after that, users would start to notice that new
mailboxes or other mail-enabled recipients were not present in the OAB
and that deleted recipients were still present.
Exchange 2013
updates the OAB generation process so that multiple Mailbox servers can
generate the necessary files required to keep clients up to date. The
default configuration is that a single Mailbox server hosts a special
type of arbitration mailbox called the organization mailbox, which
stores the OAB update files during the generation process. When
generated, the OAB update files are copied to the server directory
previously described. Other mailboxes can be created to handle OAB
generation if you need to spread the load across the organization. You
can identify the current set of organization mailboxes that are used
for OAB generation as follows:
Get-Mailbox –Arbitration | Where-Object {$_.PersistedCapabilities –like "*OAB*"} | Format-Table Name, Database, ServerNameOutputting
the server name is accurate only if the mailbox is located in a
database that is not hosted within a DAG. When databases are part of a
DAG, the active copy of the database that holds the OAB generation
mailbox can move within DAG members. To know the server on which the
active database copy is currently located, you have to run the
Get-MailboxDatabaseCopyStatus command.
Like
any location, the database in which the OAB generation mailbox is held
might need to change over time. For instance, you might want to delete
the database. Exchange won’t allow you to delete a database while it
holds any mailboxes, so you must move the OAB generation mailbox first
to allow the database deletion to proceed. Assume that the database
you’re dealing with is DB1. The following command searches for OAB
generation mailboxes in the database and moves them to database DB2.
Get-Mailbox –Arbitration –Database DB1 | Where-Object {$_.PersistedCapabilities –like "*OAB*"} |
New-MoveRequest –TargetDatabase DB2This
command works for both single-copy databases and those protected by a
DAG. It also does the job when you want to move the OAB generation
mailbox because you think the OAB load should be handled by another
server, when all you need to change in the command is to specify a
database on the target server.
The default organization mailbox used for OAB generation is called SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c},
a name that is probably unique in any organization. This mailbox is
created when the first Exchange 2013 server is installed in an
organization.
After the OAB update files have been generated, the assistant copies them from the organization mailbox to a folder under Program Files\Exchange\V15\ClientAccess\OAB\.
Each set of files for an OAB is held in a separate folder identified by
the internal globally unique identifier (GUID) Exchange uses to
identify the OAB.
Another change is that the role of the old
System Attendant process (which doesn’t exist in Exchange 2013) in OAB
generation is replaced by a dedicated mailbox assistant called
OABGeneratorAssistant (a process within the Microsoft Exchange Mailbox
Assistants service). Like the other mailbox assistants,
OABGeneratorAssistant runs according to a throttled workload policy
that enables it to take advantage of resources whenever the Mailbox
server is under low demand. Unlike the previous situation, which aimed
to generate OAB updates at a specific time every day, the
OABGeneratorAssistant runs on a work cycle basis, so OAB generation
proceeds as system resources allow. The work cycle is defined as
properties of the Mailbox server that hosts the OAB mailbox. The
OABGeneratorWorkCycle property determines the length of the work cycle,
and its default value is one day. The OABGeneratorWorkCycleCheckPoint
property determines the interval between OAB generation runs and,
again, the default is one day. Combined, the two properties instruct
Exchange to generate OAB updates for clients on a daily basis.
If
necessary, you can change the work cycle to have OAB updates generated
more or less frequently. A settled organization that does not add new
mailboxes or other mail-enabled objects very often might find it
reasonable to have OAB updates generated weekly. To do this, you’d
update the Mailbox server properties as follows:
Set-MailboxServer –Identity ExServer2 –OABGeneratorWorkCycle 07.00:00:00
–OABGeneratorWorkCycleCheckPoint 07.00:00:00
However,
if your organization is in a state of constant flux with new
mail-enabled objects being created on a very frequent basis, and you
wanted to have OAB updates generated twice daily, you’d run a command
like this:
Set-MailboxServer –Identity ExServer2 –OABGeneratorWorkCycle 01.00:00:00
–OABGeneratorWorkCycleCheckPoint 12:00:00
You can tell when the assistant has last processed an OAB by examining the LastTouchedTime property. For example:
Get-OfflineAddressBook –Identity 'Default Offline Address Book' | Select Name, LastTouchedTime
Name : Default Offline Address Book
LastTouchedTime : 01/11/2013 13:53:04
In
this case, you know that the default OAB was last updated by
OABGeneratorAssistant on 11 January 2013 at 13:53. Although the
OABGeneratorAssistant is designed to get new or updated objects into
the OAB reasonably soon after changes occur, you can generate the OAB
files manually at any time by using the Update-OfflineAddressBook
cmdlet. For example:
Update-OfflineAddressBook –Identity 'Default Offline Address Book'
Exchange logs event 17002 in the Application Event Log when the new OAB files are available.
As
with previous versions, the OABGeneratorAssistant reads information
from Active Directory by using the Name Service Provider interface
(NSPI) when it creates its updates. Although the address lists as
displayed in EAC might indicate that they are up to date, this only
means that the task of defining the correct set of objects to appear in
an address list is complete. It does not imply that the
OABGeneratorAssistant has finished creating new OAB files for clients
to download, so it’s always best to run the Update-OfflineAddressBook
cmdlet when the need exists to be sure that an OAB is updated and ready
for download.
You can manage the OAB generation parameters with EMS. To
begin, you can examine the many interesting details of the OAB by
running the Get-OfflineAddressBook cmdlet:
Get-OfflineAddressBook –Identity 'Default Offline Address Book' | Format-List
When you examine the output from Get-OfflineAddressBook, you can see the following:
The name of the Mailbox server that generates the OAB, blank because this is an Exchange 2013 server.
The address lists included in the OAB. In this case, just the set of objects specified in the default GAL is included.
The
versions of the OAB that are generated. Because it does not support
clients like Outlook 2003 that depend on older format OABs, Exchange
2013 only generates version 4 type OAB files.
The date and time of the last OAB update (LastTouchedTime).
The
number of records in the OAB (LastNumberOfRecords). This should
approximate the number of mailboxes, groups, contacts, and mail-enabled
public folders in the organization that are not hidden from address
lists.
The attributes included
for each OAB record (configured attributes). Some of these support
ambiguous name resolution (ANR), meaning that you can search the OAB
based on partial matches of attributes such as Surname and Office. For
example, you can find all the users in the London office by typing Lond
in the OAB search dialog box. (Click the More Columns button to force
the OAB to perform more than the default name search.) Because it’s an
ANR search, the OAB also returns users whose surname begins with Lond.
Other attributes contain simple values, such as the MailTips attributes.
How long (30 days) different files are kept on the server.
The virtual directories on the server that support web-based distribution of the OAB files.
To see a complete list of OAB attributes, you can do this:
$LA = Get-OfflineAddressBook –Identity '\Default Offline Address Book'
$L2 =$LA.ConfiguredAttributes
$L2 | Format-Table –AutoSize
You
can customize attributes that are included in an OAB by specifying the
desired set with the Set-OfflineAddressBook cmdlet. For example, a
simple OAB that contains just three attributes could be generated as
follows:
Set-OfflineAddressBook –Identity 'Default Offline Address Book'
–ConfiguredAttributes 'Surname, ANR','GivenName, ANR', 'Account, ANR'
Each
attribute is defined with its Messaging Application Programming
Interface (MAPI) property name and its type, which must be one of ANR,
Value, or Indicator. The correct type for each attribute is listed in
the preceding output. If you need to revert to the default situation,
you can do this with:
Set-OfflineAddressBook –Identity 'Default Offline Address Book' –UseDefaultAttributes
Client
access servers maintain an OAB virtual directory to specify the URLs
for internal and external clients to connect to download the OAB. The
internal URLs are created automatically and are of the form https://exserver1.contoso.com/OAB. If external access is required, the ExternalURL property must be configured by running the Set-OABVirtualDirectory cmdlet to point to the correct URL. The Set-OfflineAddressBook cmdlet can be used to set the GlobalWebDistributionEnabled
property to $True, which means that the settings for OAB virtual
directories on all CAS servers in the organization will be set
automatically. If this property is set to $True, you won’t be able to
configure the settings for the OAB virtual directory on an individual
server.
Creating new OAB generation mailboxes
When an Exchange 2013 CAS receives a client request to
download the OAB, it proxies the request to the nearest Mailbox server
that hosts an OAB generation mailbox. By default, all OAB download
requests therefore go to a single Mailbox server because only one OAB
generation mailbox exists in the organization. This is an acceptable
situation when the organization is small or connected with very capable
network links so that client download requests from around the
organization can be handled by the one server.
In larger
organizations or when you have scenarios such as hub-and-spoke
networks, you might want to distribute OAB generation by creating
multiple OAB generation mailboxes. For example, you could have an OAB
generation mailbox in every Active Directory site so that all the OAB
download requests are kept local within each site. A large site might
host more than one OAB generation mailbox; if so, the CAS will
round-robin client requests between the servers that host the mailboxes.
To
create a new OAB generation mailbox, you first run the New-Mailbox
command to create the mailbox in a database within the chosen site and
then run the Set-Mailbox command to mark it as an OAB generation
mailbox. For example:
New-Mailbox –Name 'OAB Generation Mailbox Dublin' –Database DB1-Dublin
–UserPrincipalName [email protected] –DisplayName
'OAB Generation Mailbox Dublin' –Arbitration
Set-Mailbox –Identity 'OAB Generation Mailbox Dublin' –OABGen $True -Arbitration
You’ll
be asked to confirm that you want to set the mailbox to be used for
workflow purposes. When you do, the mailbox is marked as being suitable
for OAB generation, and the OAB Generation Assistant begins to use it.
Marking the mailbox as an arbitration mailbox also hides it from
recipient lists. Now when you run the command to report on OAB
mailboxes, you should find your new mailbox listed:
Get-Mailbox –Arbitration | Where-Object {$_.PersistedCapabilities –like "*OAB*"}To
validate that client requests are being handled correctly after you
have deployed multiple OAB generation mailboxes, you can check the HTTP
proxy logs on the CAS servers to discover which Mailbox servers and
mailboxes are used. The log is found in Exchange Server\V15\Logging\HttpProxy\Oab, and the important fields to look for are the following:
