Group Policy configuration may break Presence for non contacts

***Update – Microsoft has released a KB detailing this information and 2 options for fixing it.  You can find the official KB here:

http://support.microsoft.com/kb/2428179 – Thanks for getting the KB pushed through Raaj***

Recently a client contacted me a  after an OCS Enterprise implementation.  The client noticed during their user training sessions that users could not see the presence of other users when searching in communicator.  The issue would resolve itself once the contact they were searching for added them to their contact list.

First, lets look at exactly what the users were seeing.  When you open Communicator and type a name into the search box, you should see results in the results pane.  These results should include Presence information if the contact is from your company.  This is what we were seeing:

Next we tried opening an IM to see if the Presence updated once a conversation window was opened:

I checked the forest level properties under the user tab but “Enable users to view Presence information for non contacts” was already checked.

At this point we enabled file level tracing on the client side.   To do this you need to create a new DWORD named “EnableFileTracing”  under HKCU\Software\Microsoft\Tracing\uccp\Communicator and set the value to 1.

We restarted Communicator, did a quick search for a contact that isn’t on our contact list (and we aren’t on theirs) and exited out of communicator.  The quicker you can do this test the better. It gives you less information to read.  The tracing file is in %userprofile%\tracing and is named “Communicator-uccapi-0.uccapilog” and can be opened with snooper.  A quick search for the contacts name brings us to the Benotify line in snooper, inside of the results section on the right hand side we actually see the availability information being sent back to the client:

OK, so we now know we’re getting the Presence information from the server, but for some reason the client isn’t showing it.  We do the typical stuff next, turn off third-party apps and antivirus, but we still have the issue.  Next we take a non-domain machine and test and we immediately see Presence.  Now we know the issue has something to do with the domain.

Our next step is to check Group Policy.  The client had added a few OCS settings in their policies, so I wanted to bypass these.  We moved the user out of the OU with the policy applied and the issue went away.  So now we just need to figure out which setting in the group policy was actually causing the issue.  Here’s a look at the policy:

Luckily there weren’t too many.  On a hunch I turned of SIP Compression first ( it was at the top of the list anyway).  We moved the test user back to the OU they were originally in with the modified policy applied and no issues.  Could it really be that? Nah, it can’t be.  Let’s turn it on and see if it breaks again:

When we turned the policy back on, Presence broke again.  Now I’m a little bit surprised, it must be something environmental.  The customer does have 2008 R2 running on a number of their domain controllers.  That could be it, right?  Nope!  I replicated the issue in my lab running 2008 domain controllers and just for fun, tested on my company’s’ domain (still 2003 DCs) with a test OU and the issue persisted.

I’ve contacted Microsoft and am working with them to verify the issue.  If there is a patch released or a KB I will certainly update the post, but for now it looks like you just need to disable SIP compression (at least when it is based on ping response time).

Advertisements

About Kevin Peters

My name is Kevin Peters.
This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink.

5 Responses to Group Policy configuration may break Presence for non contacts

  1. Good find, will keep it in mind

  2. Pete says:

    Just had a client run into this. However, no SIP compression.

    It looks like it might have something to do with the way the client was deployed: via 3rd party app instead of GPO. The first few clients worked fine, which is what threw me.

  3. Kevin Peters says:

    Hi Pete,

    What third party app were you using to deploy the client? Do you have any idea why it broke this feature?

    Thanks for reading!

    -kp

  4. John Jennings says:

    Hey OCS Guy!

    Is there a group policy or regedit I can perform to force my users to stay logged into OCS?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s