Fixing the “We didn’t find an audio device, which you need for calling” issue with Lync 2013 client in a Citrix XenDesktop 5.6 Virtual Desktop

I’ve been working with a client that had two new offices opening in London with HP t610 thin clients as desktops to access the XenDesktop 5.6 environment I built last year at their Bermuda office.  This weekend was the actual deployment and we noticed that the Lync clients within their VDIs wasn’t fully functional which then kicked off a 5 hour troubleshooting exercise on Saturday and another 5 hours on Sunday until we got it going.  As I’ve been extremely busy lately with multiple projects on the go and haven’t been blogging as much, I felt it was important to set aside a bit of time today to just dump all of the information I have in my head that was required to get this going.  Sorry about format as it’s not very organized so I’ll follow up with a proper post demonstrating the process step by step.

Problem

You have the Lync 2013 client installed onto a Windows 7 Citrix XenDesktop virtual desktop and you noticed that the client correctly finds the Video Device as the Citrix HDX Web Camera and it works as expected:

… but when you click on the Audio Device, you see the following:

We didn’t find an audio device, which you need for calling

If you have one already, try checking Windows Device Manager to make sure it’s installed and working.

Learn More

The problem appears to be that the Lync 2013 client does not like or see the Citrix HDX Audio device:

One of the more prominent solutions in Citrix forum posts is to remove the Citrix remote USB bus and Citrix remote USB host controller as such:

 

Citrix remote USB bus

Warning: You are about to uninstall this device from your system.

Delete the driver software for this device.

Citrix remote USB bus controller

Warning: You are about to uninstall this device from your system.

Delete the driver software for this device.

Once removed, restart the Lync 2013 client and the audio device will now get picked up:

Video and audio calls work as expected but as we all know, if the desktop is shutdown or restarted, these drivers would get reinstalled and if they’re not present, USB redirection of, say, USB flash drives does not appear to work.  I suppose it is possible to use the Delete the driver software for this device. checkbox is an option but I prefer not to permanently remove the device or the driver.  The Citrix blog post here: http://blogs.citrix.com/2013/04/05/tech-preview-of-xenapp-support-for-the-lync-2013-vdi-plug-in/ has a lot of comments at the bottom with users discussing the issue but appears to not have a resolution.

Another interesting article from TechNet demonstrating how Lync 2013 should work in a VDI desktop can be found here:

Update: Microsoft Lync 2013 in a Virtual Desktop Infrastructure
http://blogs.technet.com/b/nexthop/archive/2012/07/31/microsoft-lync-2013-preview-in-a-virtual-desktop-infrastructure.aspx

Troubleshooting steps out there:

Removing Power Saving Mode for USB Root Hub

One of the suggestions found here: http://forums.citrix.com/thread.jspa?threadID=332025

… and here: http://social.technet.microsoft.com/Forums/lync/en-US/30ec9d70-2cca-40be-b9dc-be7763e3530a/lync-2013-client-no-audio-device-detected suggests to uncheck:

Allow the computer to turn off this device to save power

… in the device manager for each and every USB Root Hub and Generic USB Hub but the problem with this solution is that the option is not available for the Citrix remote USB bus and Citrix remote USB host controller.  While this option is usually available for the USB Root Hub, the VDI does not have the proper driver installed for this component:

Device status

This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)

Furthermore, the post appears to be for an actual physical desktop.

Solution

As per the following Citrix article, there appears to be a few steps outlined by Citrix to get this to work:

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

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

Finally, I went ahead to check the t610 thin client’s receiver and noticed that it was version 13.x.x.xx so upgraded it to 14.

Step #2 – Enable EnableMediaRedirection In Lync 2013 Server

Begin by logging onto the Lync 2013 Server and use the:

Set-CsClientPolicy -EnableMediaRedirection $TRUE

… on the global policy or whatever policy you use for your users. 

Step #3 – Install Microsoft Lync VDI Plug-in

Install the Microsoft Lync VDI Plug-in onto the HP t610 Windows embedded thin client from here:

Microsoft Lync VDI 2013 plugin (32 bit)
http://www.microsoft.com/en-us/download/details.aspx?id=35457

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Note that if you receive a The installation of this package failed. error while installing the VDI plugin, extract the installer with:

lyncvdi.exe /extract:c:\lync

Then run:

setup.exe /admin

… to bring up the office customisation app, close it then run:

setup.exe

… to get it to install.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Step #4 – XenDesktop VDA version 7

Uninstall the Citrix XenDesktop 5.6 VDA agent on the pooled desktop’s master image, installed XenDesktop 7 VDA and pushed it out.

Step #5 – Enable Remote Recording

Another interesting blog post I found which I’m not sure whether is needed but configured it anyway was the following:

Lync deployment: using Virtual Desktops (VDI)
http://itbasedtelco.wordpress.com/2013/06/17/lync-deployment-using-virtual-desktops-vdi/

… that demonstrated how to configure this for RDS which included an additional registry key to add:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v fDisableAudioCapture /t REG_DWORD /d 0 /f

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Step #6 – Configure additional registry keys to specify internal and Lync Server 2013’s external server address:

With all of the above done, Lync now will now display the message:

Lync is trying to use your local audio and video

… but then displays:

Lync is not yet connected to Local Audio and Video Devices

What was necessary to get Lync to connect to the local audio was to manually add the following registry keys to the thin client:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync]

"ConfigurationMode"=dword:00000001"

"ServerAddressInternal"="yourLyncServer.domain.local"

"ServerAddressExternal"="yourExternalEdge.domain.com"

Step #7 – Install RDP Updates

Ensure that the following RDP updates are installed onto the thin client:

• KB2592687: Description of the Remote Desktop Protocol 8.0 update for Windows 7 SP1 and Windows Server 2008 R2 SP1, released October 24, 2012, and its prerequisite
• KB2574819: An update is available that adds support for DTLS in Windows 7 SP1 and Windows Server 2008 R2 SP1, released October 23, 2012

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

After all the steps have been completed, proceed with restarting the thin client.  The Lync 2013 VDI plugin should successfully pair up with the Lync client once the thin client has been restarted as you will notice a Lync 2013 prompt to enter your Sign-in address, User name and Password.  Both audio and video should work from the Lync client now.  If you’re still having issues, review the applications installed onto the thin client and remove any packages such as ones for the webcam or audio devices that may conflict with the VDI plugin.

I’ll be preparing a more detailed post on how to configure all of this when I get more time.  Hope this helps anyone out there who may be looking for more information on getting this to work.

Digitally signing Adobe Acrobat PDF documents with Microsoft Certificate Authority Certificates

I’ve recently been asked by a client whether there was a way to digitally sign documents with digital signatures that cannot be modified and therefore proves that a signed document is signed by an individual.  In addition to this, they would also like to allow more signatures to be added to it because the document is essentially an invoice that requires 2 signatures of approval and a signature from a person in accounting to verify that it has been entered into the account system.

The client already uses Adobe Acrobat Professional for creating PDF documents and they noticed signature features from within the GUI but wasn’t sure how to use it so they asked me to look into it.  I’m in no way an Adobe Acrobat expert (definitely not my forte) as I don’t use it so I did a bit of research on the internet but while it looks like it can be done, there isn’t a clear document from Adobe that demonstrates how to do it. Furthermore, Adobe appears to promote the EchoSign service which the client didn’t want to use as they didn’t want any additional cost.

Knowing that Adobe Acrobat allows certificate signing, I took a bit of time sitting down at a workstation with Adobe Acrobat Professional to play around with the settings and figured out a way to do it with Microsoft Certificate Authority issued certificates.  My guess is that a lot of others would probably need a quick and cheap solution as this so I thought I’d blog the process.

Step #1 – Create a new Certificate Template for Digital Signatures

Begin by launching the Active Directory Certificate Services console and opening up the templates section, right click on the Code Signing template and select Duplicate Template:

In the General tab, give the Template display name and Template name a meaningful name (I called it Adobe Signature), adjust the Validity period to more than 1 year if desired and check the Publish certificate in Active Directory checkbox:

Navigate to the Request Handling tab and change the Purpose field to Signature and encryption, check the Allow private key to be exported checkbox:

Navigate to the Subject Name tab and if desired, you can change the option to Supply in the request if you want to allow the enroller (the user requesting a certificate signature) to fill out the fields for the certificate or leave it as the default Build from this Active Directory information with Subject name format as Fully distinguished name and User principal name (UPN) checkbox checked.  I actually prefer to leave the setting as the default Build from this Active Directory information because the issued certificates will always be consistent with what fields are filled out and it’s also easier for the enroller to request the certificate:

Navigate to the Security tab, select Authenticated Users and check the Allow – Enroll checkbox:

Step #2 – Publish the new Certificate Template

With the new certificate created, navigate to the Certificate Template node in the Certificate Authority console, right click, select New and click on Certificate Template to Issue:

 

Notice that the new Adobe Signature template is listed:

Step #3 – Request a new certificate for the user

With the new certificate template created and published, go to the workstation of a user who needs a digital certificate for signing Adobe Acrobat PDFs, open the MMC and add the Current User store for Certificates.  From within the Certificates – Current User console, navigate to Personal –> Certificates, right click in the right empty window, select All Tasks –> Request New Certificate..:

Proceed through the wizard:

Select Adobe Signature as the certificate:

Complete the enrollment:

You should now have a signature issued by the Active Directory integrated Microsoft Certificate Authority:

Step #4 – Import Microsoft Certificate Authority Root Certificate into Adobe Acrobat Professional Trusted CAs

What I noticed with Adobe Acrobat Professional is that it does not appear to use the local workstation’s trusted store for Certificate Authorities. This means that even if a certificate is issued by a Microsoft Active Directory integrated Root CA and it is listed in the Trusted Root Certification Authorities, Adobe would not automatically trust it.  So prior to starting to use the certificate enrolled via step 3, we will need to go to every desktop that will be involved with this signing process to manually import the CA. I wished there was an easier way to do this and maybe there is but a brief Google did not reveal a GPO adm available for me to import CAs into Adobe Acrobat Professional (I will update this post if I figure out a way).

Navigate to the Trusted Root Certification Authorities folder in the MMC and right click on the root CA certificate in the store then choose All Tasks –> Export…:

Proceed through the wizard to export the root CA’s certificate:

Open Adobe Acrobat Professional:

Click on the Edit tab and select Preferences…:

Navigate to the Signatures category and click on the More button beside Identities & Trusted Certificates:

Select Trusted Certificates on the left windows and click on Import:

Click on the Browse button:

Select the exported root CA certificate:

Click on the Import button:

A confirmation window will be displayed indicating the certificate has been imported:

Notice that the certificate is now imported.  Before you proceed, select the certificate and click on Certificate Details:

Check the Use this certificate as a trusted root checkbox.  Make sure this step is completed or even though the certificate is imported, Adobe will not trusted it and will display the signatures as signed by an unknown source:

 

Step #5 – Signing PDFs with certificate signatures

From there, there are 2 options to allow users to sign PDF documents:

1. Have them select a certificate already in their local desktop’s Certificate store
2. Have them sign it with a PFX file (an exported certificate in a flat file)

#1 is convenient in the sense that they just select the certificate during signing and a password is not required.  This would be good for users who don’t roam around desktops.

#2 is good for users who may be signing documents from different workstations and the flat file PFX would be easy for them to move around or access via a network share.  Note that the PFX is password protected.

I will demonstrate what both look like:

Have them select a certificate already in their local desktop’s Certificate store:

To have them sign a PDF with a certificate in their local desktop’s store requires no further action.  All they need to do is open up a document in Adobe Acrobat Pro:

Click on the Sign button on the top right corner then select Place Signature:

Click on the Drag New Signature Rectangle button:

Use the lasso to lasso an area where the signature is supposed to be:

Assuming there’s just 1 certificate available, the user’s certificate should already be selected in the Sign As field but if not, select it then click on the Sign button:

Save the document:

Note the signature and the Signed and all signatures are valid. note at the top:

Clicking on the Signature Panel button will show the signatures applied to the document:

Right clicking on the signature will allow you to review the signature properties by clicking on Validate Signature:

Note that if Clear Signature is selected, the signature will be marked as cleared but the line item will not be deleted because this allows a full history of what’s been done with the signatures.

Have them sign it with a PFX file (an exported certificate in a flat file):

To sign with a PFX, we will need to export the issued certificate first similar to the way we did with the root CA certificate.  Navigate to the Personal –> Certificates folder in the MMC and right click on the issued certificate in the store then choose All Tasks –> Export…:

Proceed through the wizard to export the certificate:

Ensure the Yes, export the private key is selected:

Enter a password:

Select a path:

With the certificate exported as PFX, proceed by signing PDF documents by opening up a document in Adobe Acrobat Pro:

Click on the Drag New Signature Rectangle button:

Use the lasso to lasso an area where the signature is supposed to be:

In the Sign As drop down menu, select New ID…:

Select My existing digital ID from: and A file:

Browse to the exported PFX file, enter the password:

Review the properties of the certificate and click Finish:

Proceed by clicking the Sign button:

Save the document:

Note the signature and the Signed and all signatures are valid. note at the top:

Clicking on the Signature Panel button will show the signatures applied to the document:

From here, you can continue to apply other user’s signatures to it as shown here:

Note the second signature that’s listed as Rev. 2:

This may seem like a simple task to Adobe Acrobat Pro experts but for someone like me who don’t use the application, finding information on how signature works took a bit of time so I hope this helps anyone out there who may find themselves in the same situation as I did.