Having been working with presence for some time now it’s hard to remember a time when I didn’t know in advance if a coworker or business partner was available before trying to contact them. Unfortunately there are people out there who are interested in obfuscating their availability, presumably to confuse people into not communicating with them. Most commonly people like this set their status to “Away” when they are really there. In the beginning it causes people not to communicate with them but over time people figure out that they may be there anyway, which eventually causes the more annoying situation of trying to communicate with someone who actually is away. It’s not overly pleasant to always wonder if the person on the other end is available.
I’ll stop the soapbox there. To address this, at least with regards to internal users, you can leverage the DiagShowPublisherPresence stored procedure in SQL. To do so, open SQL Management Studio, expand Databases/rtc/Programmability/Stored Procedures:
You’ll find a lot of stored procedures here (aka stored procs) and if you browse through them you’ll start to see how OCS works under the covers. It’s very important not to modify any of the stored procs - doing so could cause major problems with OCS.
With that aside, scroll down to the dbo.DiagShowPublisherPresence, right click, and select Execute Stored Procedure:
A dialog with options will appear. In the Value field enter the SIP address of the user whose presence you wish to see and click OK:
This will return a fair amount of data, as you can see below. The column we’re interested in is the one titled Data.
In the Data column you’ll see the raw XML of the presence data. You’ll see a lot of data here, especially if the user is logged on to multiple places. The “aggregateState” entries will reference the overall presence state of the user. You’ll also see “userState” and “machineState” entries:
Notice the difference between the availability of the userState and the machineState (15500 and 3500 respectively). 15500 represents an Away state whereas 3500 represents an Available state (see http://msdn.microsoft.com/en-us/library/bb878933.aspx for reference on the presence state integers). I can tell since the machineState is Available but the userState is Away and set to manual=”true” that this user has manually set their presence to Away.
Admittedly it’s not an elegant solution to finding this information. I may write a quick tab extension to show this right in Communicator but in the meantime it highlights the usefulness of the stored procs that you’ll find in SQL. Thanks to Simon Booth, our UC developer extraordinaire for some insight on the presence data.