Tuesday, March 31, 2009

OCS WMI access denied 0x80041003, Windows 2008

Just a quick post today. Super busy...

If you get this error when modifying the WMI properties on Windows 2008 for something like removing the "+" sign out of the Mediation server, simply run WBEMTEST by doing the following:


1. Either open a command prompt by right-clicking the icon and choosing "run as administrator"

or

2. Disable UAC

Cheers!

Jason

Sunday, March 8, 2009

OCS R2: Conferencing Attendant & E.164

I recently griped about the new feature in OCS 2007 R2 called the Conferencing Attendant to my local Microsoft TSP. The issue I had was that the voice prompts for joining a meeting asked you to type in your phone extension to join as an 'authenticated user'. Since we have a mix of users with DID's and non-DID numbers, how could the user type in their extension (which is actually their TEL URI) if it followed the e.164 format of:

+17805551212;ext=5555

As it turns out the Conferencing Service uses normalization rules as well. So if the user types in "5555" as their extension, it will normalize to the above number and they will pass the TEL URI authentication.

Prior to writing this article I was convinced that using a TEL URI of "+5555" is the best option when using the Conferencing Attendant service. Now, once again I'm a supporter of the ';ext=' format.

There are however two outstanding issues with this idea:

1. The AudioCodes Mediant 2000 voice gateway (version 5.6 firmware) doesn't like the the non-numerical values such as ';ext=' when performing digit manipulation. As you are well aware, if your user doesn't have a DID, they'll require the voice gateway to manipulate the digits to prepend the +17805551212;ext= value before their extension number. When you save this type of manipulation into the AudioCodes gateway it wipes out all, YES ALL of your manipulation rules. I'm waiting for a fix at the moment :(

2. When you type in the e.164 formatted number into the "Telephone" field of a user's account in Active Directory, and try to perform a lookup using an Exchange Auto Attendant, it will fail. Apparently Exchange doesn't know how to handle the ';ext=' value either. Also, when building number masks for these types of numbers, the ';ext=' value is not something Exchange will accept. Seems odd doesn't it? Well give it a try. It doesn't work :(

The so called 'workaround' for issue 1 is that you shouldn't reboot the gateway and a saved config file will have the values stored in it so if you must reboot, reload the config file. To get around issue 2, you need to change the Telephone field to the users extension only and make sure you have a normalization rule in OCS to handle the 4 (or 5) digits Exchange will toss at it.

Now, the question is.....to e.164 or not?