Deploying Microsoft Lync 2013 audio and video with VMware Horizon View VDI

I’ve noticed that one of the most common questions I’ve been asked over the past year and a half is whether I had written a blog post to demonstrate how to configure Microsoft Lync 2013 audio and video with a VMware Horizon View VDI infrastructure and what I’ve typically done is refer them to one of my previous posts written in October 2013 which demonstrates how to do this with Citrix:

Deploying Microsoft Lync 2013 audio and video within a Citrix XenDesktop 5.6 VDI

http://terenceluk.blogspot.com/2013/10/deploying-microsoft-lync-2013-audio-and.html

… as well as the document that VMware provides:

http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-microsoft-lync-install-configure.pdf

Since there has been times where I had to further explain the process, I thought it would be worth the time to write this blog post to provide a simple demonstration.  Before I begin, let me highlight the known limitations as outlined by VMware in the PDF I provided the link to:

Known Limitations

Certain limitations are known to apply to the deployment of Microsoft Lync with Horizon View. These include:

• Although customers can download both a 32-bit and 64-bit version of the Horizon View client, the PCoIP process running on the Horizon View client operates only in 32-bit mode. Therefore, customers can use only the 32-bit version of the Lync VDI 2013 Plug-in on the client endpoints.
• Customers will not be able to use a 32-bit version of the Microsoft Lync VDI 2013 Plug-in from a machine that has the 64-bit version of Office 2013. This is a known issue and a configuration that is unsupported by Microsoft. The bit-level of the Plug-in must match the bit-level of any local Microsoft Office installation.
• From a client device perspective, this initial solution is only supported on Windows 7 client machines with SP1 applied.
• From a virtual machine perspective, this solution is only supported on virtual machines running Windows 7 with SP1.

One of the most common mistakes I’ve seen for deployments is when the administrator downloads and installs the 64-bit Lync VDI Plug-in onto either the thin client or PC that would be using the VMware Horizon View Client to connect to the virtual desktop.  This could either be because the Windows Operating System is 64-bit or because the installed Office 2010 or 2013 is 64-bit which would not allow you to install the 32-bit Lync VDI Plug-in.  Using the plug-in on a thin client isn’t usually an issue since Office does not need to be installed but if you are using a regular thick client such as a PC, then you absolutely would need to install the 32-bit version of Office.  This is obviously quite disappointing and may not be an option in some environments depending on the type of work the user performs with files such as spreadsheets but this is a limitation with no workaround.  To avoid confusion, I will itemized the following important considerations:

End Point Operating System (e.g. Thin Client or PC): Can be 32 or 64-bit

Lync VDI Plug-in installed on End Point OS: Must be 32-bit Lync VDI Plug-in

Virtual Desktop’s Lync Client: Can be 32 or 64-bit

VMware View Agent: Needs to be 5.2 or higher

With the prerequisites out of the way, the following outlines the steps for the deployment.

Step #1 – Enable EnableMediaRedirection on Lync 2013 Server

Begin by ensuring 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 #2 - Install Microsoft Lync VDI Plug-in

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

The package you’ll receive is named lyncvdi.exe with a size of 223,651 KB:

I never had much luck just running the install on a HP t610 and Wyse clients as the install will fail once the files are extracted:

The installation of this package failed.

Proceed by extracting the package with the command:

lyncvdi.exe /extract:c:\Lync

Then run the setup.exe executable to install the plugin:

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

Lync is trying to use your local audio and video devices when you hover the mouse over the icon or click on it:

 

Step #3 – Configure the registry of the Lync VDI plug-in on the End Point with Lync Server information

Since the Microsoft Lync VDI Plug-in does not prompt the user to sign in, there is not really a way for the plug-in to use the user’s sign in information to automatically discover the internal and external Lync server address so to get around this, the following HKCU registry keys are required to be added:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync

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

"ServerAddressInternal"="yourLyncServer.domain.local" <—String Value

"ServerAddressExternal"="yourExternalEdge.domain.com" <—String Value

What I usually suggest is if your thin clients are going to be joined to the domain, use a GPO with Group Policy preferences to create these 3 registry keys on the thin clients. If the thin clients are not joined to the domain then add the keys by manually logging in as the generic User account to enter them or putting in a batch file on startup to add it to the user’s account if you’re configuring local accounts for separate users.

Step #4 – Install Audio and Video device drivers onto End Point

Make sure the drivers for the headset is installed onto the thin or thick client:

Step #5 – Test Audio and Video Redirection

With the above steps completed, proceed by ensure that your thin client and VDI has been restarted (or at the very least restart the Lync 2013 client in the VDI) then confirm that the audio and video device is NOT connected into the VDI as shown in the following screenshot of the banner:

Pay attention to the two small computer flashing icons at the bottom right hand corner of the Lync 2013 client and if you click on it fast enough, you would see the message:

Lync is trying to use your local audio and video devices.

You should see a green circle with a white check mark at the bottom right hand corner once Lync successfully connects to your local device’s audio and video device.  Clicking on the icon on the bottom right hand corner will display the message:

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

Opening the Options window:

… and navigating to the Audio Device setup would present the following message:

This audio functionality isn’t available when Lync is being used in a remote desktop

Audio device tuning is not supported when Lync is running in a remoted environment. To tune your audio device volume levels, please see guidance from your IT administrator.

Navigating to the Video Device setup would present the following message:

This video functionality isn’t available when Lync is being used in a remote desktop

Video device tuning is not supported when Lync is running in a remoted environment. To tune your audio device volume levels, please see guidance from your IT administrator.

Fixing Failed Exchange 2010 Database Content Indexes

I recently assisted a client over the weekend to patch their Exchange 2010 infrastructure with the latest service pack and rollup packs, and one of the issues I came across after the patching was that some of the database content indexes would be listed as Failed. This problem is one that I encounter quite frequently but never remember the exact cmdlet to correct the problem so this blog post serves to be something I can reference to in the future.

The following cmdlet can be used to list all of the databases and the health of the Content Index State:

Get-MailboxDatabaseCopyStatus -server <mailboxServerName>

The following cmdlet can be used to list only the databases with failed database content indexes:

Get-MailboxDatabaseCopyStatus –server <mailboxServerName | where {$_.contentindexstate -like "Failed"}

The following cmdlet will retrieve all of the databases with the content index listed as failed then use the Update-MailboxDatabaseCopy cmdlet to fix the indexes:

Get-MailboxDatabaseCopyStatus –server <mailboxServerName>| where {$_.contentindexstate -like "Failed"}

| Update-MailboxDatabaseCopy -catalogonly

The following is a sample output of the series of cmdlets used:

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server exmb01

Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex

Length Length State

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

DB06\EXMB01 Healthy 0 0 3/28/2015 6:17:07 PM Healthy

DB05\EXMB01 Healthy 0 0 3/28/2015 6:15:10 PM Healthy

DB04\EXMB01 Healthy 0 0 3/28/2015 6:10:34 PM Healthy

DB03\EXMB01 Healthy 0 0 3/28/2015 6:17:26 PM Failed

DB02\EXMB01 Healthy 0 0 3/28/2015 6:15:19 PM Healthy

DB01\EXMB01 Healthy 0 1 3/28/2015 6:17:40 PM Healthy

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server EXmb01 | where {$_.contentindexstate -like "Failed"}

Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex

Length Length State

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

DB03\EXMB01 Healthy 0 0 3/28/2015 6:17:26 PM Failed

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server EXmb01 | where {$_.contentindexstate -like "Failed"}

| Update-MailboxDatabaseCopy -catalogonly

[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus -server EXmb01 | where {$_.contentindexstate -like "Failed"}

[PS] C:\Windows\system32>

Using PowerCLI to create new role and assign service account used by VMware App Volumes service account permissions for vCenter Server 5.5

One of the most exciting products I've been working with recently has been VMware App Volumes as most of the clients I work with that currently use VMware Horizon View have a need for customizing their virtual desktops but do not want to additional overhead of managing multiple master images. The deployment is actually quite simple (I'll write another blog post demonstrating this) and one task in particular that I've been performing frequently which could be automated is the creation of the service account that the App Volumes Manager uses to access vCenter. Those who may have come across my previous blog posts would know that I'm a huge fan of automating mundane and repetitive tasks so this post serves to do so for configuring the service account used by App Volumes Manager.

The permissions required for the service account that App Volumes Manager uses to connect to vSphere vCenter is displayed in one of the steps during the initial configuration:

Required vCenter Permissions

• Datastore
• Allocate space
• Browse datastore
• Low level file operations
• Remove file
• Update virtual machine files
• Folder
• Create folder
• Delete folder
• Global
• Cancel task
• Host
• Local operations
• Create virtual machine
• Delete virtual machine
• Reconfigure virtual machine
• Resource
• Assign virtual machine to resource pool
• Sessions
• View and stop sessions
• Tasks
• Create task
• Virtual machine
• Configuration
• Add existing disk
• Add new disk
• Add or remove device
• Change resource
• Remove disk
• Settings
• Interaction
• Power Off
• Power On
• Suspend
• Inventory
• Create from exising
• Create new
• Move
• Register
• Remove
• Unregister
• Provisioning
• Clone template
• Clone virtual machine
• Create template from virtual machine
• Customize
• Deploy template
• Mark as template
• Mark as virtual machine
• Modify customization specification
• Promote disks
• Read customization specifications

Manually configuring the permissions from within the vCenter client would look as such:

Datastore

Folder

Global

Host > Local Operations

Resource

Sessions

Tasks

Virtual Machine > Configuration

Virtual Machine > Interaction

Virtual Machine > Inventory

Virtual Machine > Provisioning

The cmdlet to execute to automatically create a role named App Volume Manager Service and assign the permissions as displayed in the screenshots above are as follows:

$priv = Get-VIPrivilege -ID Datastore.AllocateSpace,Datastore.Browse,Datastore.FileManagement,Datastore.DeleteFile,Datastore.UpdateVirtualMachineFiles,Folder.Create,Folder.Delete,Global.CancelTask,Host.Local.CreateVM,Host.Local.DeleteVM,Host.Local.ReconfigVM,Resource.AssignVMToPool,Sessions.TerminateSession,Task.Create,VirtualMachine.Config.AddExistingDisk,VirtualMachine.Config.AddNewDisk,VirtualMachine.Config.AddRemoveDevice,VirtualMachine.Config.Resource,VirtualMachine.Config.RemoveDisk,VirtualMachine.Config.Settings,VirtualMachine.Interact.PowerOff,VirtualMachine.Interact.PowerOn,VirtualMachine.Interact.Suspend,VirtualMachine.Inventory.CreateFromExisting,VirtualMachine.Inventory.Create,VirtualMachine.Inventory.Move,VirtualMachine.Inventory.Register,VirtualMachine.Inventory.Delete,VirtualMachine.Inventory.Unregister,VirtualMachine.Provisioning.CloneTemplate,VirtualMachine.Provisioning.Clone,VirtualMachine.Provisioning.CreateTemplateFromVM,VirtualMachine.Provisioning.Customize,VirtualMachine.Provisioning.DeployTemplate,VirtualMachine.Provisioning.MarkAsTemplate,VirtualMachine.Provisioning.MarkAsVM,VirtualMachine.Provisioning.ModifyCustSpecs,VirtualMachine.Provisioning.PromoteDisks,VirtualMachine.Provisioning.ReadCustSpecs

New-VIRole -Name "App Volume Manager Service" -Privilege $priv

With the role created, you can execute the following cmdlet to assign the domain service account to the vCenter object (top most level):

$rootFolder = Get-Folder -NoRecursion

$myPermission = New-VIPermission -Entity $rootFolder -Principal “domain\service-avm” -Role “App Volume Manager Service” -Propagate:$true

Note that the cmdlets above were tested with VMware vCenter 5.5 Update 2d and VMware App Volumes Manager 2.6.0.1226.

Windows Mobile 6 Classic handheld device is not detected in a VMware Horizon View 6 virtual desktop as a USB device

I was recently asked by a client to look at an issue with a device that her land survey team used which was not being detected as a USB device in a VMware Horizon View 6 virtual desktop.  The device is made by a manufacturer named Nomad and its operating system details are as follows:

Windows Mobile 6 Classic

CE OS 5.2.1946 (Build 18550.0.7.4)

2007 Microsoft Corporation

The device the user is using to access the virtual desktop is an HP t520 thin client with the Smart Zero operating system as shown in the following screenshot:

The handheld device was previously working when the user used a full Dell PC to access the view desktop so the first item I checked was whether the device was detected from within the thin client’s operating system and I could see that the device was present and mounted.  I then went to check the Device Manager list of the VDI’s Windows operating system to see if the device was present but it wasn’t.

As I was beginning to run out of ideas, I went ahead and tried searching on the internet to see if there were any known issues with this device and was able to find the following Microsoft KB:

You cannot synchronize a Windows Mobile-based device by using ActiveSync 4.x
https://support.microsoft.com/en-us/kb/938323

Although the KB wasn’t specific to VDIs, I went ahead and tried disabling the Enable advanced network functionality on the device:

I noticed that the virtual desktop immediately detected the device, started installing the driver and eventually displayed the device in Device Manager as a Portable Device with the name Tripod Data Systems Nomad:

Windows Mobile Device Center was what the user used to access his files so I went ahead and launched the application:

… and the application immediately displayed the status as Connected:

I was also able to browse the device’s drive through Windows Explorer:

Hope this helps anyone out there who may experience the same issue.