Outlook Integration Error in Communicator 2007 R2 when Exchange System Manager is installed

Working on an OCS migration project a few weeks ago I ran into everyone’s favorite error:

There was a problem connecting to Microsoft Office Outlook. Your Outlook profile is not configured correctly. Contact your system administrator with the information.

After double checking the lengthy KB 2373585 article discussing Outlook/Communicator errors and ruling out the usual suspects I was stumped. After some digging around on the workstation I found the user had the Exchange 2003 System Manager and tools installed on the machine. Since the System Manager uses a slightly different version of MAPI components Communicator would generate this error immediately upon signing in.

The solution is to open a command prompt and just run the command: fixmapi.

The C Stands for Compact

I believe in my last post about damaged Communicator address book files I pointed out that it was a good idea to keep your OCS clients and servers on the same hotfix levels. I would still argue that’s a good thing to do in general, but in my case this wasn’t the actual resolution. While it worked for awhile after a few weeks the damaged address book files error popped up again:

Communicator cannot synchronize with the corporate address book because the corporate address book file appears to be damaged. Contact your system administrator with this information.

All the MOC clients and OCS servers were at the same revision level this time so that wasn’t the problem. Deleting the GalContacts.db and forcing a full download would succeed and the client goes along perfectly happy. Interestingly enough, deleting the GalContacts.db.idx file on a problematic machine would allow the delta file to download successfully so it appears the issue may be with the index file. Anti-virus logs also showed they weren’t trying to clean or repair the file in any way.

I couldn’t find any errors server-side and everything seemed to be functioning properly so I looked at the IIS logs on the Front-End again. Low and behold – the log was huge compared to previous days – about 10x as big. It was filled with many, many requests for downloads of files in the C-xxxx-xxxx.lsabs format which threw me off because the ABS documentation points out that F-xxxx files are fulls, and D-xxxx-xxxx files are delta changes, but has zero mention of the C-xxxx-xxxx files. These IIS requests were also successful downloads, not failures so I wouldn’t have expected clients to have an error, but every user was also repeatedly downloading the same sets of files and then trying to download previous C-xxxx-xxxx files as well.

I took one of the matching C-xxxx-xxxx and D-xxxx-xxxx files (they’ll have the same hex names) and dumped both to text files using abserver.exe –dumpfile to try and compare. Viewing them side-by-side they seemed to have the same content, but in a slightly different order. So it appears they were both delta files, but the C file was about 50% of the D’s size. Odd, but I still had no clue when they would be used over a D because there was zero documentation about the change.

Thanks to a few kind folks on Twitter (@aumblumberg and @MacRS4 ) who went down this same road with Microsoft via a support case previously, I found out the new C files stand for “Compact” and the change was implemented in the July server-side hotfixes. These are also delta files, but compressed in a way supposedly to make them more efficient. In our case (and theirs), it broke the address book downloads completely.

Fortunately, there is a registry key available to prevent clients from trying to use these compact files. This key only applies if you’re using the October Communicator client-side hotfix:

Key name: GalUseCompactDeltaFile

Possible Values:

  • 0: Do not use compact delta file
  • 1: Use compact delta file (default)
  • 2: Use compact delta file, but do not issue an LDAP query to retrieve the “Title” and “Office” attribute values from Active Directory

You can read more about this registry setting from KB 976985 even though the actual KB is aimed at a different issue with LDAP queries and account lockouts.

I’ll find out today whether this actually fixes the downloads without having to clear out the GalContacts.db file on each client.

It looks like these constant address book changes like this and adding the 0-60 minute download delay are aimed at the larger organizations with a significant address book size, but. I almost feel like these updates are on par with the Resource Kit book providing examples for companies with 100,000+ users in various locations. Great info, but what about the real world? Not everyone using OCS is that big and it would be swell to have guidance around small and medium-sized deployments instead of trying to take those numbers and make them fit. I’d be happy to just let the ABS download the way it used to and leave it alone.

The most frustrating part here has been that this service has been something that traditionally just worked without intervention and instead I’ve been spending hours and hours troubleshooting to figure out what happened because there was nothing mentioned about the change in behavior server or client-side. Maybe there should be some threshold for these ABS disasters optimization changes where they only occur if the full address books are over some value like 10, 20, 50 or 100 MB? Until that happens I’ll be disabling the compact delta files at future OCS deployments to make sure we avoid this problem.

Communicator and Damaged Address Book Files

The past few days I spent wrestling an address book server issue in OCS and I wanted to share the solution. The quick version: make sure you have your server side and client side hotfix revisions match up.

If you want the whole story…the specific details of this case involved a Front-End server which had the OCS 2007 R2 April hotfixes, but the MOC clients had the July hotfixes applied. The issue first manifested itself with clients reporting ABS damaged:

Communicator cannot synchronize with the corporate address book because the corporate address book file appears to be damaged. Contact your system administrator with this information.

We resolved this by deleting the entire contents of the address book file share and forcing a resync of the address book. We also deleted GalContacts.db from a few user workstations, but later found the client error actually disappeared on its own without removing the file.

Things hummed along nicely for a week or so until a large amount of users (600+) were enabled for OCS one Friday evening. The following Monday previously enabled pilot users were reporting they still didn’t have a SIP URI in their address books for the mass-enabled users. The GalContacts.db file was also still showing a timestamp from the day the mass change occurred, indicating they had not downloaded an update yet.

We took a peek at the Front-End logs and it appeared to be generating address book files correctly. The odd thing was in looking at the IIS logs we actually saw quite a few 404 errors of MOC clients trying to request delta files that did not exist. Other users showed successful downloads of the latest delta files which should have included the changes, but they weren’t being applied to their local GalContacts.db for some reason. I also saw those same clients registering a success end up using the fallback logic and downloading older address book files even though they had the newer versions. Very, very strange. Any client we deleted GalContacts.db on would pull down the latest full address book with no issues. The clients looking for deltas that didn’t exist we probably caused by deleting the address book files previously.

Side tip when looking at the IIS logs: Full files start with F-xxxx and delta files follow a D-xxxx-xxxx naming convention. Also, .lsabs files are used by MOC while .dabs files are used by Tanjay devices.

At that point I noticed the mismatch in server (April hotfixes) vs. client (July hotfixes) versions and suggested we get the latest fixes installed on all sides. While that suggestion made its way through change control procedures we opened a PSS case with Microsoft to hit the problem from another angle. The engineer we spoke with immediately blurted out that we needed to match the hotfix versions as soon as we described the behavior. It sounded to me like this was one he had heard before or was familiar with so while we didn’t have a second approach this definitely helped accelerate the change control ticket to an authorized state. After we fully patched the Front-End using the new ServerUpdateInstaller (a lifesaver), applied the back-end database hotfix, and installed the client October hotfix the address book went back to functioning properly. There were a couple of users that needed to delete the GalContacts.db before everything went back to normal, but most of them picked it up without intervention.

As for root cause, the KB 972403 article actually does reference applying both the MOC and server fix together, but the July server hotfix document doesn’t describe this behavior or even mention it. Personally, I think the underlying issue was having the 3.5.6907.37 hotfix on clients while the abserver.exe file was still at 3.5.6907.0. In any case, I learned a lot more about the ABS than I ever cared to, but it was great information that will surely help in the future.

Communicator QoS DSCP Marking on x64 Operating Systems

I never did manage to figure this one out. The registry key HKLM\Software\Microsoft\RTC\Transport\QoSEnabled=1 never seemed to take effect on x64 versions of Vista or Windows 7. Wireshark packet traces would show no tags, but x86 clients worked just fine. Turns out the registry key you need to set for this to work is under the WoW6432Node which makes a ton of sense after seeing it. The DWORD you need to set is this one:


Thanks to Matt McGillen for posting this originally.

Communicator Phone Edition Update to 3.5.6907.9

I think this went largely unnoticed in many of the blogs I follow in the wake of the Exchange 2010 newsapolooza last week, but there was an update released for Communicator Phone Edition bringing the device version to 3.5.6907.9.  The first thing I noticed was the fact that my phone number is now displayed at the top of the screen which is a nice touch.  There is also a high-contrast option for those who have trouble seeing the screen.

Phone number display:

High-contrast enabled:

Issues and Fixes:

  • This change is applicable if there is a call log entry created for a call from someone who is a contact in the signed-in user’s Outlook contact list, the GAL, or the OCS contact list. For that call log entry, an icon indicates which device (work, home, mobile, or Communicator call) was used to make the call. This enables the user to call the remote party back directly by using the call log entry "Call" function. The call log now stores the actual number that was used to make the call.
  • Issue: This package enables accessibility support for vision impaired users. High Contrast color schemes can increase readability by using higher contrast color combinations on the screen. With this change, user can operate the telephone in high-contrast mode. We have now included the High Contrast setting. You can enable this setting from the Settings menu.
  • This package enables accessibility support for hearing or speech impaired users. Before this release, the user could not connect a telephone typewriter device into the headset port on the back of the telephone and enable the setting so that they can communicate with a remote party that supports text telephony.  A TTY setting on the Settings menu has been added to let the user connect a TTY device to the telephone.
  • This package enables the display of the user’s own telephone number on the main screen. With this change, the work number for the user, as entered in the corporate directory, will always be displayed at the top of the display.

    The official document and download can be found here: http://support.microsoft.com/?kbid=967820

    Communicator multilingual user interface

    Recently I did a global deployment of OCS which required Communicator to be used in a few different languages. A great start for information on languages and localization for OCS components can found at the Modality Systems blog, but one piece of information I had a hell of time finding was deploying the multilingual user interface (MUI) pack for Communicator. Plenty of “go here to download” information available, but nothing on mass deployment.

    The end goal was to deploy a single package to client machines consisting of Microsoft Office Communicator, the Microsoft Office Communicator MUI, Microsoft Office Live Meeting and the Conferencing Add-In for Microsoft Outlook. So we needed a silent installer for the MUI, but the.exe download would not respond to any kind of switches I used, no matter what.

    Turns out I was just over-thinking the installer. It behaves the same way as the Live Meeting or Conferencing Add-In executables you download so you can extract the .MSI by using the –out:[File path] parameter. So, to snag the MSI which will work with any of the regular MSI switches such as /qb or /qn do the following:

    CommunicatorMUI.exe –out:C:\CommunicatorMUI

    Inside of the folder you specify you’ll find CommunicatorMUI.msi, which you can use as you need.

    In the end, having Communicator install in the same language as Office wasn’t a strict requirement, but if you do need that done Steven Westwell has a great post on automating the registry key for language settings. He keys off a custom task sequence variable for their builds, but I’m sure you could modify that script to read the Office installation language ID.

    Communicator Updates Coming in WSUS Soon

    Aaron Tiensivu pointed out that the OCS Update group has been renamed in WSUS in anticipation of R2. The nice thing this time around is that Communicator client updates are going to finally be included. The current update approach is brutal: applying .msp patches which are only available as hotfixes. It made tracking and finding updates for Communicator much more difficult than it should have ever been, but this change should hopefully make that process a bit easier.

    Office Communicator and Published Phone Numbers

    One of the trickiest parts of configuring OCS voice is getting all your address book normalization rules functioning properly and I noticed something recently that really threw me off so I set off on a little investigation. To set the stage, I removed all normalization rules from my Mediation Server and deleted the Company_Phone_Number_Normalization_Rules.txt file. Theoretically that leaves me with just the built in rule processing.

    I have 2 users, Jim Morrison and Roger Daltrey, both enabled for Enterprise Voice capabilities. Jim’s Line URI is tel:+15035461201 and Roger’s is tel:+15035461101. In Active Directory I filled in the telephone numbers for Jim and Roger as the same values, sans the tel: prefix. Just so we’re clear, Jim’s number was +15035461201.

    I fired up 2 Communicator clients, one signed in as Jim and the other as Roger. From Roger’s point of view I saw this:



    Not very nicely formatted, right? Jim sees the same thing for Roger’s number. The key point here is the number is displayed exactly as it is formatted in AD. The thing that threw me off was that I knew I had seen Communicator format those numbers in a much nicer way. Something more like +1 (503) 546-1201, which is much easier to read. So I started fiddling and went into Jim’s phone options within Communicator and added a mobile number. I used the same format I did in AD, +12345678900. I added Roger to my Team Access Level so he could see the mobile number and took another look:


    Interesting. That mobile number sure looks better than the work one, right? Why didn’t Communicator display that number the same way for both numbers? I opened up Jim’s phone options again and took a closer look. Jeff Schertz has a nice post mentioning how access levels (don’t) get applied when you enter a number in AD, but the key point applicable here is that a number entered in AD is automatically visible to anyone within the organization. So Jim’s number was entered in that box and I was unable to edit it as a user, but what I noticed was the work number was unpublished.


    So I checked that box and then flipped over to Roger’s Communicator. Well, well, well. All the numbers look right and are nicely formatted now.



    So what I discovered is that the a visible and published number are treated differently. OCS will format a published number, but not a number that is simply visible because of AD. Strange, but good to know. I think this is due to where Communicator is pulling the information from. If a number is coming from AD and is unpublished, the number is being read by MOC from the GalContacts.db file. If a number is published to OCS, MOC is reading the number from the server and OCS database. So priority-wise MOC prefers a published number over one read from the address book.

    Communicator Custom Presence Tool 1.1

    My little Communicator application for publishing custom presence has been non-functional for some folks. I spent some time trying to fix it and think I figured out most of the problem – it works just fine for users who have made the required registry edit manually or previous to running the application. If the user never has created the necessary registry key for enabling custom presence, the application never worked. I’ve been completely unsuccessful in creating a legitimate fix so I’ve resorted to a cheapskate approach and made the application now require UAC privileges. If you were having problems I would try this updated version, but if the old version worked for you and you are not an Administrator on your box, I’d recommend sticking with the old version for now. Another solution would be to simply run the original version in an Administrator context by right-clicking on the application and choose “Run as Administrator.”

    I’m hoping to get a better solution up soon, but this works as a stop-gap.

    Download: Communicator Custom Presence Tool 1.1

    On the note of a better solution – I’m not much of a programmer so maybe someone has an idea for me.

    My problem is a normal user in Vista does not have write privileges to the HKEY_CURRENT_USER\Software\Policies\Microsoft key. It seems odd, especially considering that’s within the HKCU hive. So the application fails when it tries to create the HKCU\Software\Policies\Communicator key. The .XML file gets created just fine, but Communicator will never look for it because the registry key to tell it so never got set. So how the heck can I use VB to say “Open this registry key, add the permission to create a subkey?” Is it even possible without the user having write access on that key? Every time I try programmatically I get denied access, even if I open the parent key for editing. It’d be swell to be able to do this without requiring a UAC prompt.

    If I ever figure that one out I have some cool ideas for a nicer GUI and 2.0 release.

    Injecting Contacts to the OCS Address Book

    I had a client ask recently if there was a way to insert federated contacts into their own internal address book. This would work out well for organizations where there would maybe be a few high-profile users who are frequently added between different companies. I went about trying this today and the answer is that it kind of works.

    For sake of this example let’s say I’m user A in Company A with an OCS SIP domain of domainA.com and a partner I’m federated with is User B in Company B with an OCS SIP domain of domainB.com. Since the OCS Address Book Service will pick up any user or contact in Active Directory that has the msRTCSIP-PrimaryUserAddress attribute set I went about the following:

    1. Created a contact object for a User B in Company B as you would normally have for a user outside your organization.
    2. Used ADSIEdit and manually populated the attribute with the user@domainB.com value that I knew was reachable and federated through OCS already.
    3. Forced an Address Book Sync.
    4. Removed User B from my Outlook contacts so Communicator wouldn’t pick it up.
    5. Deleted the GALContacts.db file.
    6. Restarted Communicator.

    I can search the Search field in Communicator and I get the by-letter matching for User B as I would expect for anyone else in my organization. The only downside is I don’t receive any presence or information for the user until I actually add them to my contact list. On the other hand, this is the exact same behavior seen when typing any federated contact’s name into the Search field. Mission sort of accomplished?