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.
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.
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.