Lync 2013 CWEs – Breaking Change to Context Package Registration

Recently I blogged about a breaking change in Lync 2013 regarding authentication of CWEs.

It seems there’s another one.

Lync 2010 – User or Machine

In Lync 2010 you can register CWEs in one of two places in the registry – the LocalMachine hive or the CurrentUser hive.

The current MSDN documentation on registering CWEs has both these locations:

Registration Data Values

Add the context application GUID as a key under either of these two paths:

HKEY_CURRENT_USER\\Software\\Microsoft\\Communicator\\ContextPackages
HKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Communicator\\ContextPackages

This is useful, because it means that large-scale roll-outs don’t have to worry about targeting specific users on machines. It’s also led to a mix of different settings in the wild, with some customers using LocalMachine and some using CurrentUser.

Lync 2013 – All Change

In our Lync 2013 lab we ran into problems with Lync thinking that our context packages weren’t registered, when we knew full well that they were. By trial-and-error we discovered that only packages registered to the User Hive were doing anything.

We reached out to Microsoft for clarification. They have confirmed that this is indeed the case: all CWEs in Lync 2013 must be registered to the User Hive.

To clarify: In Lync 2013 you can only register CWEs using the UserHive path, NOT the LocalMachine one.

New Registry Keys

In addition, in the User Hive – there’s now a NEW LOCATION for registering CWEs:

[HKEY_CURRENT_USER\\Software\\Microsoft\\Office\\15.0\\Lync\\Addins\\ {YOUR_GUID_HERE}]

Luckily the contents of the key don’t seem to have changed.

(it’s worth pointing out that in my testing on the Lync 2013 Preview client, the ‘old style’ of User Hive key still worked fine for me, though I imagine this isn’t supported and might get removed by the time 2013 goes to RTM)

Documentation?

On the face of it, this is a fairly sensible, though annoying change. Sensible because it will be better to have just one location to look in for context packages. Annoying because we will have to update ever client machine when they upgrade to Lync 2013 with new package information. (and really annoying if they keep the old UserHive location active, because we won’t know if there are any clients sitting on a time-bomb)

However, the real issue here is that this information isn’t being widely communicated to Lync Developers. In fact, looking at the preview 2013 MSDN documentation, which you can see here, both methods are still shown as valid. Microsoft kindly pointed me to this page, Migrating Your Application to Lync 2013 Preview. It’s definitely worth a read and worth checking back for updates. I’ll put something on the front page about it as well.