Mike Stacy's Blog

Powershell script to populate the thumbnailphoto attribute

In my role I work with a lot of demo environments, and so it’s not uncommon for me to find quick workarounds for tasks that I have to do repeatedly or train others to do.  Recently one of those has been populating the thumbnailphoto attribute for Lync Server.  For a while I was using a modified version of a script written by George Durzi, and the script below still uses most of what he wrote in his blog entry on the topic.  I also borrowed the file dialog function from Hugo Peeters from his PeetersOnline entry and the AD bits from various places.  That’s really how I “code” these days anyway – thank goodness for the internet. 

I wrote this so that it works well in multi-domain environments like the one I work in, so it searches the global catalog to find the user wherever they may be and then does an LDAP bind to write to the domain where they are actually located since thumbnailphoto isn’t a global catalog attribute.

“Release Notes”

- To run, save the attached script and simply run the script from Powershell.  If you are running it from a server you may need to install the Desktop Experience feature (servermanagercmd -i desktop-experience).

- To change it to work in your environment just modify line 2 to match your Active Directory domain.  In case you’re not familiar with the syntax, domain.com would be dc=domain,dc=com and europe.domain.com would be dc=europe,dc=domain,dc=com.

- When you run the script you’ll be prompted for a username.  This should be the logon name (samaccountname) of the user, i.e. mstacy rather than mstacy@domain.com.

- The photos can’t be larger than about 70kb (In my brief testing 67kb worked, 76kb didn’t).  If the photo is too large you’ll receive this:  "Exception calling "CommitChanges" with "0" argument(s): "A constraint violation occurred.

- Like all things on the internet, use at your own risk.

Download photo.ps1 (1.4K)

Other useful links related to photos in Lync and Exchange:

http://blogs.technet.com/b/nexthop/archive/2010/11/22/microsoft-lync-2010-photo-experience.aspx

http://technet.microsoft.com/en-us/library/ee721049.aspx

http://msexchangeteam.com/archive/2010/03/10/454223.aspx

Are you really Away?

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.