Attempting to access VMware View Horizon 5.3’s HTML5 Blast Secure Gateway for HTML access to desktop on port 8443 displays a “HTTP 404 Not found” in Internet Explorer or “Missing route token in request” in Mozilla Firefox

I’ve been getting quite a few calls lately from clients who have been deploying VMware View Horizon 5.3’s HTML5 Blast Secure Gateway for HTML access to virtual desktops and while the solution is rather quite simple, I thought I’d write a short blog post to clarify why they would receive the following errors when access the URL shown in the View Connection Server Settings:

https://<viewConnectionServerFQDN>:8443

Internet Explorer

HTTP 404 Not Found

The webpage cannot be found

HTTP 404

Mozilla Firefox

Missing route token in request

The reason why an administrator would see these errors is because HTML5 access with VMware View is not meant to be access via https://<viewConnectionServerFQDN>:8443

The proper way of access any published virtual desktops with VMware View Horizon 5.x is to use the regular HTTPS 443 URL as such:

https://<viewConnectionServerFQDN>

Note how the options above allow the regular Install VMware Horizon View Client option on the left and VMware Horizon View HTML Access on the right.

I will be writing another post on how to configure VMware Horizon View HTML5 access over the next few days.

Using PowerCLI for Veeam DR replicated virtual machine testing

I recently had to set up Veeam replication for a client who needed a subset of their production environment virtual machines replicated to another site that would provide as their disaster recovery datacenter in the event that their building becomes inaccessible.  As of Veeam version 6.5, the recommended method of testing replicated VMs at the DR site was as follows:

1. Disable the Veeam replication job
2. Create a snapshot of the replica in the DR site
3. Change the port group of the replica VM to one that does not have any network connectivity outside of the vSwitch to prevent unwanted communication to the real world (i.e you don’t want your mail server sending emails out or a trading application making trades)
4. Power on the VMs and begin testing
5. Power off the VMs
6. Revert back to the snapshot created in step #2
7. Delete the snapshot created in step #2
8. Re-enable the Veeam replication job

Fairly easy to do for a small set of virtual machines but as you get towards a larger amount of VMs to test, the more clicking is involved while working through the GUI.

As with all repetitive tasks, PowerCLI would be able significantly decrease the amount of time required by not requiring the manual clicking in the GUI.  The following outlines the steps and the respective cmdlets:

1. Ensure that the replication job is not running and proceed by temporarily disable the job to ensure a replication does not begin while you are running the test.

2. Next, create a snapshot of the replicas using the following PowerCLI command:

Get-VM -Location "<folderName>" -NoRecursion | New-Snapshot -Name "Before DR Testing Sept 16" -Confirm:$false

**Note that the cmdlet above assumes that you have placed all of the replicas you want to create a snapshot in a folder.

This will be used to revert the replica VMDK to its original state after the DR test being completed:

3. Next, we’ll need to change the port group to a network that is not routable to the production network to avoid conflicts between the replica and production virtual machine.  Use the following PowerCLI command to change the port group from VNET-59 to Isolated Network:

Get-VM -Location “<foldername>” | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName “Isolated Network” -Confirm:$false

You should now see the port group for the replicas has been changed:

4. Power on the replica Virtual Machine with the following PowerCLI command and validate the integrity of the data and functionality of the server:

Get-VM -Location "<foldername>" | Start-VM

5. Once testing has been completed, power off the replica Virtual Machine with the following PowerCLI command:

Get-VM -Location "<foldername>" | Stop-VM -confirm:$false

**Note that you can actually skip this cmdlet to power off the VMs because running the next cmdlet that reverts to the snapshot that was created would automatically power off the VM. 

6. With the virtual machines powered off, continue and revert the replica Virtual Machine to the snapshot you have taken in the beginning with the following PowerCLI command:

Get-VM -Location "<foldername>" | Set-VM -Snapshot "Before DR Testing Sept 16" -confirm:$false

 

**Note that there is no need to revert the port group for the Virtual Machine back to the original network because reverting to the snapshot created earlier would reverse the changes made to the port group.

7. Delete the snapshot that was created with the following command:

Get-VM -Location "<foldername>" -NoRecursion | Get-Snapshot -Name "Before DR Testing Sept 16" | Remove-Snapshot -Confirm:$false

These cmdlets saved me a lot of mouse clicks during the setup and cleanup of a DR test.

Listing and removing tags from Citrix Xendesktop VDIs

I recently had to use tags as a way to filter a Machine and User policy for a select group of users with Citrix XenDesktop VDIs across 2 different pools.  Adding the tags were easy from within the GUI but I quickly noticed that removing them wasn’t.  The Citrix XenDesktop Desktop Studio allows you to tag one desktop as such as such:

 

… as well as tag multiple desktops by shift or CTRL selecting them:

The challenge here is that while you can remove the tag by selecting a VDI and selecting Edit tags:

You cannot do the same when you select more than one desktop:

Seeing how there wasn’t an obvious way to do this in the GUI, I went ahead and turned to PowerShell cmdlets.  First off, the cmdlets that manipulate tagging are as follows:

Get-BrokerTag
http://support.citrix.com/static/kc/CTX127254/help/Get-BrokerTag.html

Add-BrokerTag
http://support.citrix.com/static/kc/CTX127254/help/Add-BrokerTag.html

New-BrokerTag
http://support.citrix.com/static/kc/CTX127254/help/New-BrokerTag.html

Remove-BrokerTag
http://support.citrix.com/static/kc/CTX127254/help/Remove-BrokerTag.html

Rename-BrokerTag
http://support.citrix.com/static/kc/CTX127254/help/Rename-BrokerTag.html

As I did not find a way to display the tags for a virtual desktop in the Desktop Studio, I used the following to retrieve the list of desktops with the tag Opt:

Get-BrokerDesktopGroup

The problem with simply using the cmdlet above is that you get quite a bit of information as each desktop has a lot of attributes:

… so to make the list a little easier to read, you can use the following cmdlet to list the desktop and a subset of the attributes associated with it:

Get-BrokerDesktopGroup -Tag Opt | FL HostedMachineName,CatalogName,DesktopGroup,Tags,Uid

… or it can be further simplified with:

Get-BrokerDesktopGroup -Tag Opt | FL HostedMachineName,Uid

The attribute we’re interested in is the Uid because the Remove-BrokerTag expects that value to be provided when removing the tag from the desktop.  Executing the following cmdlet will list the Uid(s) of desktops that are currently tagged with the tag Opt:

Get-BrokerDesktopGroup -Tag Opt | FL Uid

With the Uid(s) listed, you can use the cmdlet:

Remove-BrokerTag Opt -Desktop 296

… to remove the tag from the desktop:

Notice how desktop with the Uid 296 is no longer listed:

I’m sure many may be wondering now whether we can pipe the Get-BrokerTag cmdlet into the Remove-BrokerTag cmdlet so we don’t have to manually remove the tag one desktop at a time but unfortunately, it doesn’t look like the Remove-BrokterTag accepts bundled Uid(s) that the Get-BrokerTag cmdlet returns.  What I would suggest if you have a lot of desktops is to dump the Uid output into a spreadsheet and manipulate it from there to make this easier rather than manually typing a line for each desktop.

If anyone knows of a way to achieve the same results more efficiently, please feel free to post down in the comments.

Adding the required registry keys for Lync 2013 VDI Plug-In for Integration on a Thin Client

As some administrators may know, one of the requirements for configuring the Lync 2013 VDI plug-in for redirecting local audio and video devices on the client requires registry keys to be added to the HKEY_CURRENT_USER of the user who is logged on to the client connecting to their VDI:

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

This isn’t usually a problem for environments where thin clients are joined to the domain as this can be easily configured via Group Policy but is a challenge for non domain joined thin clients because the user login on, say, a HP t610 Thin Client with Windows 7 embedded where the user login prohibits and restricts access to the command prompt, registry editor any most other configuration consoles in the operating system.  I was presented with this challenge and the first thought I had was to create a .reg file adding the registry keys required, place the file on the user profile’s desktop, log in as the user account, execute the .reg file and type in the administrator credentials to apply the registry changes.  This didn’t end up working for me so after a bit of thought, the following was what worked:

1. Log into the thin client as the administrator
2. Start the remote registry service in the Services Console
3. Log into the thin client as the user account
4. Log into another Windows desktop that allows you to launch the registry console
5. Use the Connect Network Registry option to connect to the thin client’s name or IP
6. Authenticate with the thin client’s administrator credentials
7. Add the registry keys

This got the registry keys in for the user account and I was then able to redirect the Lync 2013 client to the local audio and video devices.

For those who are interested in a step by step walkthrough of configuring Lync and VDI integration, see one of my previous posts:

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

Unable to map SMB Windows shares after upgrading to OS X Mavericks Version 10.9.1

Problem

You’ve recently updated your Mac OS X to Mavericks version 10.9.1:

… and noticed that if you attempt to map a SMB share on a Active Directory file server via:

smb://<ipAddress or Name>

You would receive the authentication challenge prompt:

… credentials would be accepted:

… but selecting a volume to mount would shake the window without mapping the drive and you are unable to proceed further:

Solution

A bit of searching through the internet (https://discussions.apple.com/thread/5467191) indicate that the new SMB2 implementation in Mac OS X to Mavericks has compatibility issues with various file storage devices so the workaround is to map the drive as a cifs share:

cifs://<ip or name of server>

Integrating Lync 2013 with Microsoft Lync VDI Plug-in cycles through the “Lync is trying to use your local audio and video devices.” continuously and eventually fails

Problem

You’ve deployed the Microsoft Lync VDI Plug-in with your Citrix XenDesktop VDI but notice that the Lync 2013 cycles through the Lync is trying to use your local audio and video devices. phase continuously to try and redirect the audio and video devices but eventually fails:

 

Solution

While there can be various reasons why the Lync client would cycle through this phase continuously without successfully connecting to the locally connected audio and video USB devices, one of the reasons is if you haven’t entered the credentials for your Lync account.  I’ve noticed that there were a few instances where reconnecting to an existing VDI client that already has the Lync client launched would exhibit this behavior.  One of things you can try is to completely shutdown the Lync client and re-launch it then see if you receive the following logon prompt:

Once you enter the appropriate credentials for the login, you should see the following:

Followed with:

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

Installing an additional x86 printer driver after a x64 driver is installed on a print server throws the error: “The specified location does not contain the driver <printer name> for the requested processor architecture.”

Problem

You’re migrating an old Windows Server 2003 print server to Windows Server 2008 R2 and have decided to build new and manually install the printer drivers as the old Print Migration Tool is not recommended for 2003 to 2008 R2 migration.  The x64 driver installs successfully onto the serer and you are able to send jobs to the printer without any issues but as you attempt to add an additional x86 printer driver after a x64 driver is installed:

You receive the following error:

The specified location does not contain the driver <printer name> for the requested processor architecture.

You attempt to use Server Manager to add the driver but receive the same errors:

Solution

After fiddling around with multiple ways of adding drivers without any success, I realized that the reason why the following HP LaserJet M3035 mfp PCL6 x86 driver wouldn’t install:

… is because I had used the HP Universal Printing PCL 6 driver for the original x64 install on the Windows Server 2008 R2 server:

Once I made sure the x86 driver I used was the same as the x64, the driver finally installed: