Deploying Microsoft Lync 2013 audio and video with Citrix XenApp 6.5

Those who may have come across my previous post about integrating Lync 2013 audio and video redirection to the local client:

Deploying Microsoft Lync 2013 audio and video within a Citrix XenDesktop 5.6 VDI
https://blog.terenceluk.com/2013/10/deploying-microsoft-lync-2013-audio-and.html

… may know that although the requirement for XenDesktop 5.6 is to use the XenDesktop 7 VDA, which renders XenDesktop 5.6’s Desktop Director unusable because it does not support 7.x VDAs, XenApp 6.5 published desktops is a supported configuration as outlined in the following Citrix document:

XenDesktop, XenApp and Citrix Receiver Support for Microsoft Lync 2013 VDI Plug-in
http://support.citrix.com/article/CTX138408.html

I haven’t actually been working with XenApp 6.5 over the last few months and so never tested the configuration but as I to do so today for a client with the legacy architecture, I thought I’d write this short blog post about the configuration.

Environment Information

Citrix XenApp Version: 6.5
Hotfixes: Rollup 3

Lync Client: 2013
Version: 15.0.4454.1506
MSO: 15.0.4420.1017
Bit: 32-bit

Citrix Receiver: 4.2

Step #1 – Update Citrix Receiver on the HP t610 thin client to version 4.0

Begin by checking the existing version # of the Citrix Receiver installed onto the client connecting to the XenApp 6.5 server and update it to a version later than 4.1.02.

Step #2 – Enable EnableMediaRedirection on Lync 2013 Server

Ensure that the Lync Client Policy of users who will be redirecting to local devices has EnableMediaRedirection enabled.  The environment for this demonstration has all the users using the Global policy so executing the Get-CsClientPolicy -identity Global cmdlet will show the following

**Note in the above screenshot that EnableMediaRedirection is not enabled.

Proceed by using the following cmdlet to enable it:

Set-CsClientPolicy -identity Global -EnableMediaRedirection $true

Executing the Get-CsClientPolicy -identity Global cmdlet will now show the following:

Step #3 – Install Microsoft Lync VDI Plug-in on the client connecting to XenApp

——————————————————————————————————————————————————–

**Note that at the time of writing this post, only the 32-bit version of the Microsoft Lync VDI Plug-in is supported and will work for redirecting audio and video.  The 64-bit plug-in is not supported and will not work as described in the following Citrix article:

XenDesktop, XenApp and Citrix Receiver Support for Microsoft Lync 2013 VDI Plug-in
http://support.citrix.com/article/CTX138408.html

Citrix Receiver for Windows requires the 32-bit version of the Microsoft Lync VDI Plug-in on the device, even on a 64-bit Windows machine. The 64-bit version is not compatible with Citrix Receiver for Windows since the bitness of the VDI Plug-in must match the bitness of the Receiver.

——————————————————————————————————————————————————–

Proceed to download the Microsoft Lync VDI 2013 plugin 32-bit and install it onto the thin or thick client that will be used to connect to the virtual desktop:

http://www.microsoft.com/en-us/download/details.aspx?id=35457

Restart the thin client and you’ll notice that when you connect to your VDI, you will see a new green small icon at the bottom right hand corner with a white checkmark:

Clicking on it will show the following:

Lync is all set to use your local audio and video devices.

Note that unlike the thin client I was working with in my other post, I did not have to set the following registry keys on the Windows 7 full desktop I was using:

HKEY_CURRENT_USERSOFTWAREMicrosoftOffice15.0Lync

“ConfigurationMode”=dword:00000001” <—DWORD (32-bit) Value

“ServerAddressInternal”=”yourLyncServer.domain.local” <—String Value

“ServerAddressExternal”=”yourExternalEdge.domain.com” <—String Value

I believe the reason why is because the desktop I was using to connect to XenApp already had Lync 2013 installed on it and although the registry key above did not contain any of the items that had to get manually added to the thin client, the redirection still worked.  It is likely that these registry keys would need to get created if the computer was not joined to the domain.

Sorry about the brevity of this post but I just wanted to quickly demonstrate that this configuration also works with XenApp 6.5.