Address Book Service – Use and Troubleshooting (part 1)
I’ve seen a huge number of issues in the Microsoft public newsgroups related to the Address Book (AB Server). The queries arise from a combination of things: lack of clarity on how the AB Server actually works, bad configuration, permission problems, bad/missing certs, etc. I find we spend a lot of time answering the same questions over and over.
To try to help OCS admins grappling with the AB Server, I’m creating a couple of blog posts on the AB Server. This one, the first, will concentrate on how the ABServer Works. Then in a subsequent post, I’ll look at how to troubleshoot your issues.
Note: What I’m publishing is my understanding thus far. To some degree I regard this blog post as a work in progress – so please comment where I’m wrong, or missing a point. There are some gaps in my knowledge and I’ve indicated where those are. More comments PLEASE! Some of the information comes from the [MS-ABS] information you can find at the Microsoft Office Protocol Documents at: http://msdn.microsoft.com/en-us/library/cc307432.aspx. The rest of it via hard work, and loads of troubleshooting!
What does the AB Service actually do?
The AB Server (and some other components)are a part of Office Communications Server that provides users with a local address book that can be searched by the client (e.g Microsoft Office Communicator, or MOC, and Microsoft Communicator Phone Edition, aka Tanjay). Clients then get information about OCS related users and groups (distribution lists) stored in AD, but without having to hit AD each time they search.
When it works (which is most of the time), the AB is pretty cool. You can search for users (and DLs) in MOC by just typing letters/numbers. If, for example, you hit “TH”, MOC would show all the entries that begin with “TH” – this would include all the users whose names start with Thomas, Thanthony, ThePowerShellUGDL,etc. The AB also allows clients to do reverse number look-up of incoming VOIP calls. {this is per MS-ABS – need to check of MOC actually does this]
The AB Server system enables searching of the address book using only local resources. But by decoupling the local store from the AD, there is inevitably a degree of imperfectly fast convergence. If I add a new user, Billy Bob Joe Bob for example, it’s not going to be instantly in your local AB even if he can log on pretty quickly. To understand this, let’s look at how the whole AB server process work works.
How Does The AB Process Work?
The AB Process consists of several pieces that extract information on SIP enabled users and contacts and use this to create a set of files that the MOC client downloads and uses as noted above. At a very high level, this process involves several steps:
The User Replicator Service has a couple of functions. First,propagates necessary OCS information from AD to OCS relatively quickly. UR can ask AD (technically it asks a GC) for all changes since a certain time. It then writes those changes to OCS’s SQL database. The UR process runs on the Front End Server. [need to add details of process name, and clarify what happens in expanded enterprise deployment]]
The information downloaded enables the OCS (SQL) database to contain all the information about OCS users up to ‘relatively soon ago’. This means you can add a user and they can logon pretty soon. [need to quantify ‘soon’].
Since OCS has all the information about all the SIP enabled users/contacts, the DB also serves as the basis for generating downloadable address books. This is done by the AB Server that runs on the web components server and the client then downloads these as described below.
AB Server Process
Once a day the AB Server parses the OCS SQL database and creates a set of files that the client can download to construct a local address book database. By default, the AB Server performs this at 01:30 local time. You can use WMI to change this time. [should add WMI class/property to change]
The AB creates several files each night:
The delta files contain the difference between two full files including new and changed user objects as well as deleted user and contact objects. The AB Server files are named as follows:
The files with the .LSABS extension contain full information about each contact or user. Files with the .DABS extension contain a minimal subset of information useful to a SIP Phone Client. [need to check that MOC downloads the .lsabs and that the tanjay downloads the DABS]
What does the client do?
When the client logs into OCS, the client subscribes to provisioning information. The FE/registrar server responds by sending this information which includes a b base URL details of where to find the AB files. The client then uses the URL to request the appropriate files. It does this by concatenating the base URL received via in band provision with a detailed name based on the current date (using the date format noted above).
If this is the first time the client has ever logged on, or if the client hasn’t logged in for 31 days or more, MOC downloads the latest full file. If the user has logged in between 1 and 30 days ago, MOC downloads the appropriate .LSABS file. If the file is a delta, it’s merged wiuth the current address book. If it’s a full file downloaded, the new file overwrites the older one.
In some cases, the size of the delta can be larger than the size of the full file. This could happen if you do some major re-organisation of the AD (deleting users, adding users, etc). In such cases, no delta is created, and a full file is used instead.
The MOC client gets two separate base URLs – an internal one and an external one. MOC will first try to access the AB Server files using the internal base URL. If that fails (i.e because the client is external), MOC tries again using the external address. [need to confirm this using WS]
So What can go Wrong
In an nutshell – lots. although in most cases it all just works. There are some simple problems to resolve, as well as some more complex ones. But I’m leaving those details for a second blog article that looks into the primary issues you may face. I’ll publish this later this week.
To try to help OCS admins grappling with the AB Server, I’m creating a couple of blog posts on the AB Server. This one, the first, will concentrate on how the ABServer Works. Then in a subsequent post, I’ll look at how to troubleshoot your issues.
Note: What I’m publishing is my understanding thus far. To some degree I regard this blog post as a work in progress – so please comment where I’m wrong, or missing a point. There are some gaps in my knowledge and I’ve indicated where those are. More comments PLEASE! Some of the information comes from the [MS-ABS] information you can find at the Microsoft Office Protocol Documents at: http://msdn.microsoft.com/en-us/library/cc307432.aspx. The rest of it via hard work, and loads of troubleshooting!
What does the AB Service actually do?
The AB Server (and some other components)are a part of Office Communications Server that provides users with a local address book that can be searched by the client (e.g Microsoft Office Communicator, or MOC, and Microsoft Communicator Phone Edition, aka Tanjay). Clients then get information about OCS related users and groups (distribution lists) stored in AD, but without having to hit AD each time they search.
When it works (which is most of the time), the AB is pretty cool. You can search for users (and DLs) in MOC by just typing letters/numbers. If, for example, you hit “TH”, MOC would show all the entries that begin with “TH” – this would include all the users whose names start with Thomas, Thanthony, ThePowerShellUGDL,etc. The AB also allows clients to do reverse number look-up of incoming VOIP calls. {this is per MS-ABS – need to check of MOC actually does this]
The AB Server system enables searching of the address book using only local resources. But by decoupling the local store from the AD, there is inevitably a degree of imperfectly fast convergence. If I add a new user, Billy Bob Joe Bob for example, it’s not going to be instantly in your local AB even if he can log on pretty quickly. To understand this, let’s look at how the whole AB server process work works.
How Does The AB Process Work?
The AB Process consists of several pieces that extract information on SIP enabled users and contacts and use this to create a set of files that the MOC client downloads and uses as noted above. At a very high level, this process involves several steps:
- OCS’s User Replicator service registers for changes in the AD. The UR service then looks at all the new/changed/deleted user or contact objects. The details of these objects are then written to the OCS database. [need to add details around just what the replicator looks for, and where in the DB these records live]
- The Address Book Server parses the DB contents and produces a set of files that the client can download to generate the local store. The ABServer runs, by default at 01:30 local time, but this can be changed using WMI. The AB Server creates both a new file representing ALL the contact data, plus a set of delta files showing ONLY the changes since a certain number of days ago. These AB files are placed on a local share, which are exposed as an IIS virtual root off the web components server. The ABServer runs on the web components server (and for an expanded Enterprise deployment, on all web components servers.
- When the MOC client logs on, it obtains the URL to these files via in-band provisioniong. It then loads the appropriate files and creates a local database. This database is stored in [need to add this location]
The User Replicator Service has a couple of functions. First,propagates necessary OCS information from AD to OCS relatively quickly. UR can ask AD (technically it asks a GC) for all changes since a certain time. It then writes those changes to OCS’s SQL database. The UR process runs on the Front End Server. [need to add details of process name, and clarify what happens in expanded enterprise deployment]]
The information downloaded enables the OCS (SQL) database to contain all the information about OCS users up to ‘relatively soon ago’. This means you can add a user and they can logon pretty soon. [need to quantify ‘soon’].
Since OCS has all the information about all the SIP enabled users/contacts, the DB also serves as the basis for generating downloadable address books. This is done by the AB Server that runs on the web components server and the client then downloads these as described below.
AB Server Process
Once a day the AB Server parses the OCS SQL database and creates a set of files that the client can download to construct a local address book database. By default, the AB Server performs this at 01:30 local time. You can use WMI to change this time. [should add WMI class/property to change]
The AB creates several files each night:
- A full file holding all AB entries (at the time of the AB Server run)
- Up to 30 delta files, representing the change between “now” and up to 30 days ago.
The delta files contain the difference between two full files including new and changed user objects as well as deleted user and contact objects. The AB Server files are named as follows:
- F-XXXX.lsabs - a complete full file from date XXXX
- D-XXXX-YYYY.lsabs – a complete delta file representing changes between XXXX and YYYY.
- F-XXXX.dabs - a minimal full file from date XXXX
- D-XXXX-YYYY.dabs – a minimal delta file representing changes between XXXX and YYYY.
The files with the .LSABS extension contain full information about each contact or user. Files with the .DABS extension contain a minimal subset of information useful to a SIP Phone Client. [need to check that MOC downloads the .lsabs and that the tanjay downloads the DABS]
What does the client do?
When the client logs into OCS, the client subscribes to provisioning information. The FE/registrar server responds by sending this information which includes a b base URL details of where to find the AB files. The client then uses the URL to request the appropriate files. It does this by concatenating the base URL received via in band provision with a detailed name based on the current date (using the date format noted above).
If this is the first time the client has ever logged on, or if the client hasn’t logged in for 31 days or more, MOC downloads the latest full file. If the user has logged in between 1 and 30 days ago, MOC downloads the appropriate .LSABS file. If the file is a delta, it’s merged wiuth the current address book. If it’s a full file downloaded, the new file overwrites the older one.
In some cases, the size of the delta can be larger than the size of the full file. This could happen if you do some major re-organisation of the AD (deleting users, adding users, etc). In such cases, no delta is created, and a full file is used instead.
The MOC client gets two separate base URLs – an internal one and an external one. MOC will first try to access the AB Server files using the internal base URL. If that fails (i.e because the client is external), MOC tries again using the external address. [need to confirm this using WS]
So What can go Wrong
In an nutshell – lots. although in most cases it all just works. There are some simple problems to resolve, as well as some more complex ones. But I’m leaving those details for a second blog article that looks into the primary issues you may face. I’ll publish this later this week.
