Quantcast
Channel: TechNet Blogs
Viewing all articles
Browse latest Browse all 34890

Running Lync 2013 WebApp plugin in locked down Terminal server environments

$
0
0

Hi there,

 

In this blog post, I would like to talk about running Lync 2013 Webapp in Windows Terminal server environments. Lync 2013 Webapp feature has a client side plug-in which provides audio/video/application sharing functionality and this plug is installed per user, in other words installation program installs files and creates registry settings in user specific areas of the system. Most of terminal server environments are locked down in production networks and users are generally not allowed to install softwares.

I recently dealt with a couple of cases where it was required to find a solution to this problem. One possible solution is to create exceptions in your software restriction softwares (it could be a 3rd party software or it could be a Microsoft solution (Software restriction policies or Applocker)). You will find steps below to create such exceptions in Software restriction policies and applocker:

 

Software Restriction policies (That could be applied if the Terminal server is Windows 2003 and later)

Note: Please note that we don't support Lync Webapp on Windows 2003, it's supported on Windows 2008 or later. Please see the below link for more details:

http://technet.microsoft.com/en-us/library/gg425820.aspx Lync Web App Supported Platforms

 

a) First of all, Lync webapp plugin (LWAPlugin64BitInstaller32.msi) file includes a number of executables each of which needs to be defined within software restriction policy rules. You can extract the MSI file itself with 7zip or a similar tool. Once the msi file is extracted, we have the following executables:

 

AppSharingHookController.exe

AppSharingHookController64.exe

LWAPlugin.exe

LWAVersionPlugin.exe

 

b) So we need to create 5 additional rules (1 MSI rule and 4 executable file rules) in Software restriction policies in addition to your existing software restriction policy rules as given below:

 

 

Note: It’s best to create File hash rules for the MSI file itself or the other 4 executables that are extracted from MSI file

 

So if Software restriction policies is already deployed on your network, there could be an exception created for the Lync web app plugin so users will still comply with the application installation/execution policies

 

Applocker: (That could be applied if the Terminal server is Windows 2008 R2 or later)

 

a) As mentioned in previous scenario, Lync webapp plugin (LWAPlugin64BitInstaller32.msi) file includes a number of executables each of which needs to be defined within applocker rules. You can extract the MSI file itself with 7zip or a similar tool. Once the msi file is extracted, we have the following executables:

 

AppSharingHookController.exe

AppSharingHookController64.exe

LWAPlugin.exe

LWAVersionPlugin.exe

 

b) So we need to create 1 MSI rule and 4 executable file rules in applocker as given below:

 

 

  

Note: It’s best to create File hash rules for the MSI file itself or the other 4 executables that are extracted from MSI file

 

So if Applocker is deployed on your network, there could be an exception created for the Lync web app plugin so users will still comply with the application installation/execution policies

 

The only drawback in regards to file hash rules is that once Lync server Web components are updated with a cumulative update on Lync server side, you’ll have to create those file hash rules one more time (because probably the content of msi file that is shared from FE server will be different and hence the file hash will change) but considering that the web components are not frequently updated this may need to be done 2 or 3 times in a year. Alternatively there could be file path rule or publisher rule created instead of a file hash rule to avoid such maintenance.

 

Hope this helps

 

Thanks,

Murat


Viewing all articles
Browse latest Browse all 34890

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>