I realized this morning I broke the comment feature sometime awhile back. Oops. I think I’ve fixed the error so if you’ve been dying to post something you actually can do so now.
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.
I wanted to point out a quick note about KB 969834 aka the OCS2009-DBUpgrade.msi file – The KB article suggests running the package from your Back-End database server, but if you’re running SQL 2005 x86 you’ll be greeted with the following error:
This installation package is not supported by this processor type.
Basically, the MSI needs to be run from an x64 machine so your only option now is to run the update directly from your Front-End server. If you try to launch from there you might receive this error:
You must install Microsoft SQL Server 2005 Client Tools before you install Microsoft Office Communications Server 2007 R2 (KB969834).
You could try install the SQL Tools and Service Pack updates from installation, but OCS is looking for very specific versions of the SQL tools. The quickest and easiest way is to just use a couple of downloads from the Feature Pack for Microsoft SQL Server 2005 – February 2007.
You’ll want to download and install the following on your R2 Front-End before running the update:
- Microsoft SQL Server 2005 Backward Compatibility Components (x64 package)
- Microsoft SQL Server 2005 Management Objects Collection (x64 package)
After running those installers you should be able to run the DB upgrade successfully. Don’t forget – you need to run that MSI from a command line with the poolname (Non-FQDN version) parameter. And if you’re using Server 2008 be sure open the command prompt as Administrator so it runs with elevated rights. Example:
Disclaimer: Plantronics did me a sample device to test out, but this post is not a paid review in any way.
Prior to my poor experience with the Jabra GO 6430 and Communicator I had picked up a Plantronics Voyager PRO for use with my iPhone in the car because of California’s hands-free driving laws. I had been extremely happy with the quality of that device and was surprised to see Plantronics had also released a UC certified version for Communicator. My favorite headset up until then had been the Plantronics Savi Go, but I needed something a lot more portable on a day-to-day basis and the Savi Go charging stand was a bit bulky. I definitely needed to replace that Jabra so I picked up a PRO UC to try with Communicator with high hopes based on my experience with the Savi Go.
I was very happy to see that the Voyager PRO UC worked well with MOC right out of the box – no installation or drivers needed, just the way it should be. The multi-function button worked great and the headset was extremely comfortable to wear for long periods of time with the felt ear bud cover. The sound quality is definitely on par with the Savi Go which was already the best device out there so you can’t go wrong with this headset. As an added bonus it also pairs with a mobile phone so I can get by with a single headset now for my work calls when I have Communicator open and when I’m on the road driving with my mobile.
There really isn’t much to say. The device works as advertised, it looks good and the sound quality is outstanding. For someone who is constantly mobile this is the headset I’d recommend using, but if you’re at a desk more often the Savi Go is still a great choice.
A few weeks ago I started a new job and had to turn in all my UC certified devices to the old employer, which left me needing to pick up some sort of headset for use with Communicator on the road. I took a peek at the Phones and Devices Optimized for Microsoft Office Communicator page and noticed Jabra had a few newly certified devices listed. The Jabra GO 6430 caught my eye mostly because of the small form factor and sturdy looking design so I decided to give it a shot and placed an order for one.
You can see from the photos below that the device is actually a really nice size. I’ve had trouble in the past with really small headsets, but I also don’t care for the ones that extend all the way to your mouth. The charging case also doubles nicely as a carrying case, especially for someone who needs to throw a headset in a bag constantly. Unfortunately, the aesthetics are about the only thing Jabra got right. Here are a few photos of the package:
When it arrived I pulled it out, plugged the USB dongle in and tried doing some test calls with Communicator. I placed a call from my mobile to my work number and tried to answer by pressing the multi-function button. It did nothing. Ok, how about outbound? Press the button, and no dial tone. It was as if the button was worthless. Digging a little deeper into the package I found a CD and some documentation (who reads that?) so I popped it in and installed the Jabra Software Suite. After that, I was able to use the multi-function to partially control calls in MOC. For an outbound call I could now get a dial tone by pressing the button, but I still didn’t have much luck with inbound calls. I had some mixed results with the headset either not picking up or it would send the call directly to voicemail, but both were undesirable to say the least.
It only gets worse. Every time I made a settings change within the Jabra suite it seemed take down my entire wireless stack of 802.11 and Bluetooth for a few seconds. At this point I threw in the towel and gave up. Maybe it was my PC, or Windows 7, or some other combination but the bottom line is I shouldn’t have to mess with anything to make these certified devices work flawlessly. I’ve never had issues in the past with any other product, Jabra made or not, but this was unusable. Integrators and especially end-users aren’t going to spend time trying to make these things work – they just expect it to work easily. Giving someone a softphone is already a sensitive subject at times and having a device that flakes out completely ruins any hope of a good user experience. Bottom line: don’t waste your money.