Troubleshooting HMC OCS’s Address Book Segregation
HMC 4.5 has been out for a while now. We are beginning to see more and more people deploying OCS into the HMC environment as the concept of using IM as one of the corporate communication tools getting better acceptance.
One of the most common issues when setting up the OCS in HMC is configuring the address book segregation. To be honest, that’s really the only major customization you need to do to have OCS in HMC environment. If you want to know more about what are the customizations we have in HMC, you can refer to my previous blog, HMC 4.5 and Office Communications Server 2007.
In my previous blog, I talked about the address book segregation customization introduced by HMC into the OCS 2007 on a very high level. Here, we will take a closer look at the mechanism, how it should work and what are the things to look at if it doesn’t work.
1. Address Book Generation or Synchronization.
So, firstly, in order for you to have address book segregation, obviously you need to have different address book for different organizations, just like Global Address List in Hosted Exchange. Once you have completed the installation of the OCS servers, by default, it generates one address book. Think of it like the Default Global Address Book in Exchange. Now, we really don’t want that. If you have that, you should delete those to avoid confusion.
Go to the server where you have your OCS address book, such as \\OCSPOOLWEB01\ABS
If there are files there, you should remove them all.
Then by following one of the deployment steps in HMC deployment guide, Procedure W08-DWHO.66: To enable Address Book Isolation, to be specific, you will use a tool called ABSConfig.exe from the OCS 2007 ResKit and through WMI to enable the feature called Partition ABS data by Organizational Unit and create individual ABS files per OU.
Essentially, with this option enabled, when the OCS tries to perform the address book synchronization, it will generate address book based on OU instead of everyone in one big address book. So, if you want to find out if the address book generation is working accordingly right now (assuming you currently have sip enabled users in your environment), look at the ABS output location. It should have a structure following your domain OU like the following,
If it does not have any of the OU structure and just have the plain .lsabs and .dabs files in the root of ABS folder, then it probably means the feature has not been activated.
You can force a call to generate or synchronize address book by calling the following,
C:\Program Files\Microsoft Office Communication Server 2007\Server\Core>ABServer.exe -syncNow
Of course, if you have absolutely zero sip enabled users in the environment then nothing will be generated.
2. Address Book Redirection
Once the address book has been generated, of course the next thing is to make sure that it should redirect to the user to the appropriate address book according to the location of the user. This is documented in the following steps, Procedure W08-DWHO.68: To enable redirection on the external Address Book Website.
Now, here I want to highlight a couple of things which I think has kind of being left out in the deployment guide.
a. Configuring Redirection. The deployment guide only request you to configure web.config file in the C:\Program Files\Microsoft Office Communications Server 2007\Web Components\Address Book Files\Ext\Handler
This is the External handler. This handler will be used only if the connection is through external (based on the configuration of the Office Communicator client). This is where sometimes things get slightly confusing because when you are setting up stuff, you tend to try connecting through the internal server name and that will trigger the internal handler instead.
So, if you may actually want to configure the internal handler as well, which is the web.config file in C:\Program Files\Microsoft Office Communications Server 2007\Web Components\Address Book Files\Int\Handler
So, once all these have been setup, when you try to download the address book from Office Communicator, it will send you to the IIS location containing the address book. Authentication will take place and based on the authentication, it will redirect you to the appropriate path containing the address book. If you look at the IIS log, you find something like the following,
2009-06-05 10:14:04 W3SVC1 192.168.45.20 GET /Abs/Int/Handler/D-0c03-0c04.lsabs - 443 - 192.168.45.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+MS-RTC+LM+8) 401 2 2148074254
2009-06-05 10:14:04 W3SVC1 192.168.45.20 GET /Abs/Int/Handler/D-0c03-0c04.lsabs - 443 HMC45\johnc_AlpineSkiHouse 192.168.45.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+MS-RTC+LM+8) 302 0 0
2009-06-05 10:14:04 W3SVC1 192.168.45.20 GET /Abs/Int/Files/hmc45.com/Hosting/ConsolidatedMessenger/AlpineSkiHouse/D-0c03-0c04.lsabs - 443 HMC45\johnc_AlpineSkiHouse 192.168.45.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+MS-RTC+LM+8) 200 0 0
Note: See how Communicator will first request for /Abs/Int/Handler/D-0c03-0c04.lsabs and then authentication happened and when it finally got authenticated, it got redirected (302) and it goes to /Abs/Int/Files/hmc45.com/Hosting/ConsolidatedMessenger/AlpineSkiHouse/D-0c03-0c04.lsabs.
b. Configuring Application Pool account. Now, everything is in IIS and the redirection happens in IIS through an application pool created by OCS installation.
If you note the IIS log above, you will find that the Office Communicator client isn’t the one that will send you to the exact path but it was the application pool that is serving the directory that figures out which path to redirect you to.
If you right click at the application pool (LSGroupExpAppPool) in the IIS, you will find the identity running this pool is RTCComponentService.
This is important, in order for the redirection to work; the RTCComponentService must have the appropriate permissions to know where those accounts are from (when they authenticate). By default, this account has no permission to the Hosting container in HMC because of how we harden the Hosting container. Hence, in order for it to work, RTCComponentService should be part of the Windows-based hosting Service Accounts. If it is not there, you need to add it to the group and then restart the IIS.
c. ABS location and connection.
The last thing to check is how the IIS able to connect to the address book file share. If you look at the Abs\Ext\Files properties in IIS Manager, you will find that it is pointing to a network directory for the ABS. Click on Connect As button to find out what user it is using to connect to the file share. It is important to make sure that the password for that user is correctly set AND also that the account has not been disabled or locked out.
3. Quick Tests using Internet Explorer
To find out if the redirection is working.
a. Find out a .lsabs file in the ABS folder, say in
b. Then go to the web site where your address book is being published, say, https://web.consolidatedmessenger.com/Abs/Ext/Handler/F-0b72.lsabs
c. It should prompt you for user name and password. Enter a sip enabled user in the AlpineSkiHouse.
d. It will then redirect you to https://web.consolidatedmessenger.com/Abs/fabrikam.com/Hosting/ ConsolidatedMessenger/Alpineskihouse/F-0b72.lsabs and allow you to download the file.
e. If it doesn’t work, then check the IIS log to find out why.