A few months back I was involved in a discussion about what the subject name of an OCS Edge Server’s A/V authentication certificate should be. Some folks were saying to use the Edge server’s internal FQDN and others were saying to use the external, public FQDN you define for A/V. I was in the camp using the external name, but the odd thing was both sides said their approach worked. There is definitely some confusion about what name you should use and Microsoft has actually published directly conflicting information which further confuses the issue. Some testing I’ve recently done clears up why so many documents and people contradict each other – the subject name doesn’t matter. Really. You could put whatever you want in that subject name, assign it to A/V authentication and it will work flawlessly. The purpose of this certificate per the Technet documentation:

The private key of the A/V authentication certificate is used to generate authentication credentials.

Specifically, it’s not used for encryption or MTLS even if that’s not made clear anywhere. Let’s take a step back and clarify a few things for some background:

• There are two services that run on the Edge server with "A/V" in the name. If you’re not familiar with the difference, Jeff Schertz’s More on OCS Edge Server Certificates article has a good explanation for some background on what the difference is between the A/V Authentication and A/V Edge services, but basically – the A/V Authentication service is internal facing and A/V Edge Service is external facing.
• There is no certificate assigned to the A/V Edge service because encryption for external A/V traffic is provided by SRTP.
• The certificate for A/V Authentication is only used by internal clients when trying to communicate with an external or federated client. This means you can (and should) use an internal certificate authority to issue this certificate. There is no benefit or need to use a public certificate for A/V authentication.

Let’s walk through a little example here as if I was trying to figure out what name to use for my A/V authentication certificate. I have the following environment:

• Public Domain: confusedamused.com
• Internal AD Domain: ptown.local
• SIP Domain: confusedamused.com
• Edge Server Internal FQDN: edge.ptown.local
• A/V Edge Service FQDN: av.confusedamused.com

So with that information what should I use as the certificate name for the A/V authentication certificate? If you consult the Technet documentation topic Set up Certificates for A/V Authentication you’ll find this note (emphasis is mine):

The subject name should match the fully qualified domain name (FQDN) of the A/V Edge Service published by the external firewall, or the FQDN of the VIP used by the A/V Edge Service array on the external load balancer (that is, if the Edge Servers are load balanced).

So based on that blurb, my A/V authentication certificate subject name should be av.confusedamused.com. Fair enough.

I ran through the OCS 2007 R2 Edge Planning Tool for a sanity check. You can see the result below, but the tool follows the Technet documentation and uses the external FQDN I defined for the A/V Edge Service when it asked.

A group of MVPs and Microsoft employees published a document called Deploying Certificates in Office Communications Server 2007 which says the following about the A/V authentication certificate (emphasis is mine again):

Must be the FQDN of Audio/Video authentication server in DNS.

Well that calls out the name of the authentication server, not the A/V Edge Service. I think this comes down to really just poor wording in the document which contributes to confusion, but what is the name of our A/V Authentication server? It would be the same name as the internal Edge interface, right? The A/V Authentication server is the Edge server, not the external FQDN. So now we’re being told to use the internal FQDN, edge.ptown.local as the subject name.

Also released by Microsoft was a document called OCS 2007 R2 Walkthrough – Scale to Load Balanced Edge Server which completely contradicts Technet and the Edge Planning Tool (emphasis mine):

• Access Edge Internal (Corporate Certificate). In our sample topology, the subject name would be set to ocsedge.contoso.com, the FQDN of the Edge Server internal interface.
• A/V Authentication Internal (Corporate Certificate). In our sample topology, the subject name would be set to ocsedge.contoso.com, the FQDN of the Edge Server internal interface.

This seems to match up with the certificates document and is somewhat backed by the exact same Technet article I referenced earlier which says:

As a security precaution, you should not use the same certificate for A/V authentication that you use for the internal interface of the Edge Server.

This begs the question "Why would I ever even try to use the same certificate?" The only logical reason would be perhaps because they use the same subject name. That jives with the Scale to a Load Balanced Edge Server documentation. If we’re thinking about this in terms of MTLS connections, you would have to think that this makes the most sense. In your OCS Forest properties if you added an A/V Edge server with the name edge.ptown.local for port 5062, it’s reasonable that you’d expect the A/V Authentication service operating on port 5062 of the internal interface to offer a certificate matching this name. If it presented something wrong, say maybe the external FQDN of the A/V Edge service it should fail, right?

Well, the truth is the name doesn’t matter. There isn’t MTLS validation happening on port 5062 the same way you’d expect MTLS between servers on 5061. I think the reason the certificate requirement issue hasn’t been pointed out yet is because it’s never caused a problem – it works either way. I can use a certificate with a subject name gobblygook.confusedamused.com and media relay authentication through the Edge server works just fine. It just needs a certificate to generate authentication credentials for the media relay process. Go ahead and try it out – put whatever name you want on the certificate and it will still work.

So while the subject name doesn’t really matter, if you’re still interested in adhering to best practices I would recommend using the external facing, public A/V Edge name. In the example earlier this would be av.confusedamused.com. Hopefully Microsoft will update the certificate and scaling documents with a clarification and make them more consistent with the rest of Technet.

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.

Unboxing photos:

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.

Microsoft has been nice enough to provide a handy tool within the OCS 2007 R2 Management Console that checks what kind of endpoints are connected to your Front-End server. If you open the OCS MMC, click the pool object and then click the database tab you’ll see a number of reports you can run. One of the more useful ones is the client version summary. Just press Go next to it and you’ll see it return a list of endpoints.

You can see from the results we still have quite a mix, and even someone still using a Communicator 2005 client! This is useful in providing an overall picture of what’s been used, but the question I immediately hear next is “Who’s using that version?” Unfortunately, there’s no easy way to tell in the console. You can run a per-user-report which will tell you the endpoints a particular user is signed in with, but that’s going to be a tedious effort to chug through a long list of names trying to find the offenders who haven’t updated their clients. You can see below what searching for a single user returns.

In order to answer the question of who’s using what we need to run a SQL query against the RTCDyn database. I’ll say this is definitely not a recommended/supported task, so be sure you know what you’re doing here before you start messing around in SQL Management studio. You have the potential to really hose your OCS installation if you start changing database content. The query we’ll run is just a SELECT statement so we shouldn’t cause any problems. Still, you’ve been warned.

Open SQL Management Studio. If you have a standard edition pool you can download and install SQL Management Studio Express for free. Press the New Query button and paste in the following query. Then just press the Execute button. You’ll get a list back of SIP URIs along with the endpoint they are currently using.

SELECT CAST([SipHeaderFrom] as varchar) as "SIP URI"
      ,CAST([ClientApp] AS varchar) as "Endpoint"
FROM [rtcdyn].[dbo].[Endpoint]

That will give us a nice long of everything in use and what SIP URI is signed in with that client.

Say we want to filter because we’re looking for people with a specific version. In this case, we want to find everyone still using the R1 MOC client so we can add a WHERE clause that searches for strings that match the agent header.

SELECT CAST([SipHeaderFrom] as varchar) as "SIP URI"
      ,CAST([ClientApp] AS varchar) as "Endpoint"
FROM [rtcdyn].[dbo].[Endpoint]
WHERE CAST([ClientApp] as varchar) like '%2.0%'

You could replace that 2.0 with anything else returned in the agent headers such as 3.5, OC, LCC, etc. This only queries the clients that are connected at a specific point in time so you may want to run this from time to time to catch clients that may not have been connected the first time you Hope this helps you identify your clients.

HKLM\Software\WoW6432Node\Microsoft\RTC\Transport\QoSEnabled=1

Thanks to Matt McGillen for posting this originally.

Luke Kannel already tossed up some screenshots of the interface and what’s disappointing is that that it doesn’t look like it’s changed much since R1 of OCS 2007. It’s not nearly as polished as CWA or any other Microsoft web application, but I suppose it gets the job done.

Now that’s a wordy title. I’ve been meaning to write this up since about March in more detail with some fancy diagrams, but I’ve finally given in and decided to just get the information published and update it later. One of the nicest features of ISA 2006 is the ability to use Kerberos Constrained Delegation (KCD) in reverse proxy scenarios. This can used to publish applications like Exchange or SharePoint externally and allows passing NTLM credentials over an SSL channel to ISA which authenticates to Exchange or SharePoint via Kerberos on behalf of the user, making for a seamless experience regardless of location. Read: No freaking login prompts outside the firewall, even in Outlook Anywhere with ISA performing pre-authentication of users. Jason Jones has an outstanding article already written outlining how to set up KCD with Exchange 2007 and ISA 2006 that I recommend following if you’re interested. The point of this article is not to explain how to configure KCD, but to highlight two issues you’ll find when deploying this with Microsoft Office Communicator. If you’ve deployed KCD for Outlook Anywhere and have users with Communicator outside the firewall they’ll probably see the dreaded “Outlook Integration Error” or “Communicator could not retrieve calendar or Out of Office information from Exchange Web services” warnings.

There are actually two issues here that we need to resolve. The first is that Communicator itself actually uses some slightly different RPC over HTTPs logic than Outlook which causes the KCD authentication through MOC to flat out fail. In R1 of OCS 2007 I found the clients were prompted for credentials 3 times for the Outlook integration and then the integration would fail even with correct credentials. With the R2 client you’ll no longer see the authentication prompts, but the Outlook Integration error would eventually show up. The problem is in how ISA 2006 handles POST requests than do not have a POST body, which is apparently the difference between Outlook and MOC’s logic. There is a hotfix available for this which requires running a .vbs script to make the change to ISA. You can find that hotfix and script here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;942638. You actually need to apply the ISA 2006 Supportability Update package before you can install this hotfix and that package is here: http://support.microsoft.com/kb/939455/.

The second issue you’ll find is that when ISA offers Communicator the Negotiate and NTLM authenticate headers Communicator actually tries to negotiate and fails. This can be remediated by changing ISA to offer only NTLM headers to clients. There is another hotfix and .vbs script to fix this issue which you can find here: http://support.microsoft.com/kb/927265/en-us. One warning I should point out is this is a system-wide setting and will disable Kerberos for outbound-proxy scenarios. I’m not a big fan of ISA for anything other than a reverse proxy so this had no issues on my environment, but be careful to evaluate your existing rules if you use ISA for anything else.

You can test out the second hotfix without making any changes to the ISA server by going in to IE’s advanced settings on a client and unchecking the box “Enable Integrated Windows Authentication.” (Thanks to Scott Oseychik for this tip). Contrary to the outstanding verbiage, this only disables Kerberos authentication in IE and will force IE to only try to authenticate via NTLM.

Once you have all of your hotfixes installed you should be able to login to MOC only and receive no more Outlook integration errors. Perfectly seamless authentication anywhere you are. Jason Jones pointed out the two hotfixes for me originally, so a huge thanks is in order to him.

UC Planet Lookout 1.0 is the industry’s first dynamic WAN Bandwidth Management (WBM) software for Microsoft OCS 2007 and OCS 2007 R2. Lookout 1.0 enables the OCS administrators and network administrators to:

Group the Microsoft Office Communicator (MOC) users into logical “sites” or “locations”

Limit calls from/to certain locations (such as remote or overseas offices)

Assess the usage for capacity planning and for managing available bandwidth as new users, sites and communications modes are provisioned

Sounds great for those times when you actually need to put a hard limit on simulatenous calls. I’m curious to try it out.

Product Page:Lookout 1.0

Via Joachim Farla.

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