If you would like to read the other parts of this article series please go to
- The Offline Address Book (Part 1)
- The Offline Address Book (Part 2)
- The Offline Address Book (Part 3)
Introduction
This is the fourth and final article in a multi-part series that has been taking a look at the web-based distribution method for the Offline Address Book in Exchange 2010. We left part three having started our look at enabling diagnostics logging for the File Distribution Service using the Exchange Management Console. Let’s continue our look at this topic area but this time start with the Exchange Management Shell.
File Distribution Service Diagnostics Logging
It is also possible to use the Exchange Management Shell to examine and set the diagnostics logging level for the Microsoft Exchange File Distribution Service, or MSExchangeFDS. To examine the current diagnostics logging level for the MSExchangeFDS service on the server LABCAHT, use the following cmdlet:
Get-EventLogLevel –Identity LABCAHT\MSExchangeFDS\*
To set the diagnostics logging level to High using the Exchange Management Shell, the following two cmdlets are run one after another:
Set-EventLogLevel –Identity LABCAHT\MSExchangeFDS\FileReplication –Level High
Set-EventLogLevel –Identity LABCAHT\MSExchangeFDS\General –Level High
I was not able to use the wildcard character with the Set-EventLogLevel cmdlet, hence the need to run each cmdlet separately. The results of running these cmdlets can be seen in Figure 16.
Figure 16: Setting Diagnostics Logging Levels Using Exchange Management Shell
With the diagnostics logging levels set, a series of three event logs will be recorded in the application event log when the Update-FileDistributionService cmdlet is next run. These three event logs will have a source of MSExchangeFDS and a category of either FileReplication or General. The first event, which has an event ID of 1025, will inform you that the service update has been triggered. Next, event 1024 informs you that synchronization has started and, perhaps more importantly, gives both the object and GUID names of the OAB that is being updated. You can see an example of this event in Figure 17. Notice how the GUID name in the event description matches the folder names that you saw in Figures 6 and 12, thereby confirming which OAB is being updated. Finally, event ID 1008 is logged indicating a successful synchronization, as shown in Figure 18.
Figure 17: Event 1024
Figure 18: Event 1008
Outlook Client Downloads
Now that the OAB files have been generated on the mailbox server and copied to the Client Access Server such that they are available within the OAB virtual directory, they can now be accessed by Outlook clients. In this article we are concentrating on the web-based distribution method of distributing the OAB files to Outlook clients. The ability to access the OAB files in this way was first made available in Outlook 2007, so only Outlook 2007 and Outlook 2010 have the ability to support web-based distribution.
To locate the actual OAB distribution point on the Client Access Server, the Outlook client will use the autodiscover service. I’m sure that those of you reading this article are reasonably familiar with the autodiscover service so I will not spend any time detailing the overall concepts behind the autodiscover service here. However, if you do require additional information on the autodiscover service, then read Jaap Wesselius’ article here on msexchange.org. For this article though, let’s look at the way the Outlook client will download the OAB assuming that the Outlook client is located on the internal network in the case of a typical office-based cached mode Outlook client user.
If you have read up on the autodiscover service, you will know that one of the URLs returned by the autodiscover service is for the OAB. To see what this URL is for an internally connected Outlook client, Outlook’s Test E-mail AutoConfiguration option can be used. By holding down the CTRL key whilst right-clicking the Outlook icon in the system tray, the Test E-mail AutoConfiguration option can be selected as you can see from Figure 19.
Figure 19: Test E-mail AutoConfiguration Option
Selecting this feature presents the screen shown in Figure 20. Here, the email address and password of a mailbox-enabled user can be entered into the fields. Leave the Legacy DN, Use Guessmart and Secure Guessmart Authentication check boxes clear and then click the Test button. The results will be presented in the Results tab and in Figure 20 you can see that the OAB URL has been highlighted. This URL is returned by the autodiscover service and in the example below points to the CAS server’s OAB virtual directory, including the GUID of the OAB as we’ve seen throughout this article. Therefore, the Outlook client knows that it can locate the OAB at this particular URL.
Figure 20: OAB URL Within The E-mail AutoConfiguration Test
The URL presented in Figure 20 can be set within the Exchange Management Console or the Exchange Management Shell. In the Exchange Management Console, navigate to Server Configuration and then Client Access. In the work pane, ensure that the relevant Client Access Server is selected and then in the result pane at the bottom, click the Offline Address Book Distribution tab as you can see in Figure 21.
Figure 21: The OAB Virtual Directory in Exchange Management Console
At this point you can see the OAB virtual directory object for this particular Client Access Server. By bringing up the properties of this object and clicking the URLs tab, you will be presented with the screen shown in Figure 22 where you can see both the Internal URL and External URL configuration elements. These are the URLs that the autodiscover service will provide to the Outlook client for accessing the OAB when connecting both internally and externally.
Figure 22: OAB Virtual Directory Properties
If you look back at Figure 13 in part three of this article series you can see the results of the Get-OabVirtualDirectory cmdlet. You may also notice the InternalUrl and ExternalUrl parameters and how they are the same as those that you have just seen in Figure 22. Therefore, using the Exchange Management Shell, it is possible to alter these parameters using the Set-OabVirtualDirectory cmdlet with the –InternalUrl and –ExternalUrl parameters. So it can be seen that the Outlook client will connect to the URL http://labcaht.neilhobson.com/OAB when accessing the OAB when on an internal network; this is obviously the OAB virtual directory running on the Client Access Server role.
Outlook Client OAB Files
The Outlook client actually makes use of the Background Intelligent Transfer Service (BITS) to download the OAB files from the Client Access Server. For Outlook 2010, the actual OAB files are downloaded and stored into the following location:
C:\Users\{username}\AppData\Local\Microsft\Outlook\Offline Address Books\{GUID}
Inside this folder you will see several *.OAB files as you can see from Figure 23.
Figure 23: Outlook OAB Files
What you will notice from Figure 23 is that the GUID folder name matches the OAB .LZX file names that you saw in Figure 12 in part three of this article series, which is useful when tracking issues during the OAB generation and download process. If you ever have reason to believe that the OAB files stored on the local Outlook client are not being updated, it is acceptable to delete the OAB files that you can see in Figure 23 as they will be re-created when you next download the OAB from within the Outlook client.
Summary
That completes all four parts of this multi-part article that has taken a look at the web-based distribution method for the Offline Address Book in Exchange 2010. I hope that you have found this article series useful.
If you would like to read the other parts of this article series please go to
