Lync CWEs – a Technical Introduction
Microsoft Lync CWEs – Conversation Window Extensions – are one of the key tools in the Lync developer’s toolkit, but when and how you can use them takes a little bit of understanding.
make sure you check out my latest CWE project: a free Information Dashboard!
What are they?
At its simplest, a CWE is just a webpage browser, part of the Lync client and displayed to the user as a extension of their chat window. There’s no chrome (no windows, buttons, menus etc.) but content is rendered the same as in Internet Explorer, and some shortcut keys, such as Alt+arrow continue to work.
You can load whatever you want in a CWE, as long as you think it will render. For instance, I could choose to show this site as a CWE:
As a user, I can open this anytime I want to using the More Options ellipses in the bottom-right corner of the chat window.
Integration
There’s two advantages CWEs have over regular webpages though, which really open up possibilities for developers:
- CWEs can be invoked from code to open on a client’s machine automatically
- CWEs can communicate with the Lync system, to read information about the Lync session, or to send information to other applications
Let’s take each of these and break them down.
CWEs can be invoked from code to open on a client’s machine automatically
As an application developer, creating applications using either the Lync Client SDK or UCMA, when your application is in conversation with a user, you can “invoke” a CWE to appear on their client. You do this by sending a special code through to the client (which the user doesn’t see), which pops open the window. This is useful if, for instance, your application is telling the user about a recent sales order – it would be useful to open a webpage showing the order and related information.
As you might imagine, there are some security prerequisites to this (wecan’t have people opening windows everywhere on other people’s machines – this isn’t the 90’s!), but if you’ve prepared the way you can create some really nice experiences for your user this way, by giving them rich additional content to support whatever other information you were providing them.
CWEs can communicate with the Lync system, to read information about the Lync session, or to send information to other applications
As well as just opening the CWEs, there’s a clever way your application can communicate with Lync, which opens up a number of exciting possibilities.
The CWE window supports the use of Silverlight. As part of the Lync Client SDK, Microsoft provide Silverlight DLLs for Lync development. This means that you can write a Silverlight application which uses the Lync DLLs and which therefore can talk to Lync.
Why would you want to do this? Well, to take the sales example from earlier, rather than just showing a webpage with sales data, you might want to write a Silverlight application which showed the data, but targeted for the user that was looking at it. You might also want to show the Lync presence of other key people involved in the sale, making it easy for the user to contact them. You can also integrate the process of contacting people deep within your application, making it more intuitive – the user doesn’t feel like they are switching over to Lync to call someone, they’re doing it from within your application.
Microsoft have released a load of Silverlight controls which you can embed into your CWE applications. There’s an example on MSDN of adding a ContactCard into a Silverlight application to display contact information. Or, if you want to write your own, just grab a reference to the Lync client in code and have a play – the Intellisense is a good way of discovering what you can do. Start with:
Other applications can also talk to your CWE, via the Context Channel. This is a like a hidden pipe through which applications can trade data. If you’ve written an application in UCMA which contacts a user and opens a CWE, then the UCMA application and the CWE application talk to each other, without the client being aware. This unlocks some pretty powerful abilities, as it makes your CWE webpage or Silverlight application “come alive” by being able to react to events. An example would be a chess game, where you play against the computer (a UCMA application). The application would open a CWE window with a Silverlight application containing a chess board. When you make a move, this is sent over the context channel to the UCMA application. When the UCMA application has worked out its next move, it sends that back over the context channel, and the CWE application updates. of course, this communication could also be between two CWE clients, or between multiple CWE clients and a UCMA application etc. There’s a really nice code sample on MSDN showing how to send and receive context. It’s written for Lync 2010, but it should work fine in 2013: Using Lync Controls to Send Contextual Data.
Security
CWEs can perform powerful functions, such as opening on remote command, and sending data silently, so there are some tight rules about how they operate. I think this is why people find them confusing – it’s often not clear why they don’t work – but it’s usually security related! 
First, in order for any CWE to be opened, either by the user locally, or by an application remotely, it must be registered. This is done via a registry entry. The registry entry contains the name of the application, its URL and a unique GUID to identify it. This must be in place before you attempt to open a CWE on a user’s machine via code. The command to open a CWE doesn’t take the name, or the URL of the CWE – it takes the unique GUID. This is then sent to the client. If the client recognises it in the registry, then it opens the stored value of the URL. If it doesn’t recognise it, you see the “Context is not support” error in the Lync client. This means that the client doesn’t have a match for the GUID you’ve just sent it. The registry settings are keyed by the GUID of your application, and contain a friendly name, a size, and two URLs – for internal and external access. This allows you to specify an intranet URL if you want to serve a different version of the application to internal users (versus those that arrive via your Edge Server):
If opening a URL is all you want to do, then you don’t need to do any more work. However, if your application needs to establish communication with the Lync client (using the Silverlight DLLs) then the application also needs to be trusted. In Lync 2013, this means adding the domain the site is running at into a special registry key, the Lync Trusted Sites key. (in Lync 2010, this key didn’t exist – sites had to be trusted in Internet Explorer by placing them into the Trusted Zone). If you fail to do this, when your application first tries to use the Lync DLL, you’ll receive a Client Not Trusted Exception:
(for more on trusted sites, see blog post here.)
Conclusion
CWEs are a great way for developers to extend the functionality of Lync to their users. Microsoft have done a good job of providing controls and tools to allow applications to communicate with the Lync client and react to events. They can also send data to other CWEs or to applications running UCMA, which allows for a powerfully integrated solution. Because of their power, there are some fidlly security rules to work with, but once you understand these, and what you need to do to satisfy them, you can be up and running creating CWEs to extend Lync in no time!
Written by Tom Morgan
Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.
Related posts:
Problem loading Conversation Window Extensions in Lync 2013
Lync 2013 CWEs – Breaking Change to Context Package Registration
What is Microsoft Lync & Why Should I Care? A Non-Technical Introduction to Microsoft Lync
Migrating Lync CWE Registry Settings from 2010 to 2013 the Easy Way
Lync Conversation Window Extension (CWE) Sizes
Sorry, I’m two years late to the party!
I’m struggling to understand why MS didn’t build this type of functionality centrally (and might not be doing this in Skype for Business).
That is.. a central repository of CWE apps that are available (based on role based access groups) to specific users, and a section of the Lync client (a bit like managing add-ons in a browser) which allows you to enable/disable particular apps. This way you can’t get anyone with local admin rights knocking out their own apps too.
Users could then have chosen what they want to be able to use (and start apps from within Lync), you wouldn’t end up in a situation where registries are being modified, apps/shortcuts etc. are being installed on every desktop (potentially). Just feels a bit like it’s the wrong way around, only my two cents though.
I might be misunderstanding all this, but the official docs online have some barmy stuff in, like IIS must be installed on all clients who want to use the app. It doesn’t sound like something that’s easy to swallow for the enterprise type customer.
Yep – I agree it could have been architectured better. As it stands today you write the CWE then publish it on your network / internet. It doesn’t have to be IIS, but it normally is. Essentially, it’s just a webpage. That can either be a plain-old webpage, or contain the Silverlight object that enables more functionality. The way it then gets exposed to users as a CWE is (as you say) by adding a registry key to the user’s machine. Yes, this bit feels hackey. One of the reasons for this (I think) is that as well as user’s choosing to open specific CWEs, a use case is UCMA applications automatically opening the CWEs for users. The way it works today, the UCMA sends the client a GUID, the client looks in the registry, matches the GUID to the URL, and displays the webpage. I guess one advantage of this is that you could have different pages for different users, by installing different reg keys. You don’t need IIS on all clients though, or anything like that. Having to roll out the reg keys to anyone who may potentially want to open the CWE, or have an application try and open it, is certainly a pain though. Having it done as a central store would be nice – though you would remove the ability to have different URLs for different users. I’m not sure how well used that feature is though to be honest. -tom
Hey Tom, thanks for coming back on this stale topic.
In the enterprise, as I’m sure you’re aware; rolling out registry changes is not small feat! I still find it a little strange, but good news if you don’t all need IIS etc. Apart from a reg change on a client, what do they need to actually kick off/open the CWE?
The documentation from MS is plentiful, but so far I’ve found it rather messy/confusing/incorrect in many areas. 🙁
I started watching your Skype for Business videos (thanks for those by the way) but sadly they don’t cover CWE – as you say perhaps the CWE feature isn’t really well used at all.
Thanks again.
Peter
Hi Tom!
First of all thank you so much for your help with this Technical Introduction.
I have created a Silverlight App. in order to use it as CWE in my Skype4B Chat Window.
But my problem is, that I get an Error when I try to call a Javascript function from my Silverlight App.
I call the javascript function from my MainPage.xaml.cs like:
1) _message = (string)HtmlPage.Window.Invoke(“CallSilverlight”, new object[] { “test” });
Error: “Failed to Invoke: CallSilverlight”
When I run the Silverlight App. from VisualStudio I have not Errors in the call but when I run it from my CWE in S4B, the Error occurs.
I have a Button and a TextBox in my Silverlight App.
[MainPage.xaml]
[MainPage.xaml.cs]
public void CallingButton_Click(object sender, RoutedEventArgs e)
{
try
{
if (string.IsNullOrEmpty(txtTest.Text))
{
_message = (string)HtmlPage.Window.Invoke(“CallSilverlight”, new object[] { txtTest.Text });
}
else
_message = txtTest.Text;
}
catch(Exception ex)
{
MessageBox.Show(ex.Message);
}
}
[html Page - Javascript function]
function CallSilverlight(param1) {
if (param1 == “”)
return “empty”;
else
return “ok”;
}
Any ideas?
Thank you, I appreciate your help!
Sergio