Sep 092013
 

In working with a customer on a demo yesterday and they asked this question:

So Mirage is licensed by named user, we just need to license it for our users and the number of devices does not matter, correct?

“Yes, that’s correct,” I said.

The reality is that it is correct, although it may not appear to be.  Let me explain:

The best description of this scenario can be found in this VMware KB article entitled VMware Horizon Suite 1.0 licensing.

In the Q&A section in the bottom of this article, you will find the following question (as of this writing):

“Q: When I purchase a particular number of Horizon Mirage licenses, how do I count the named-user licenses used?

A: Each named user who has access to a Mirage-managed endpoint consumes one license. One named user can have multiple Mirage-managed endpoints, and this named user still consumes only one license. The Workstation virtual machines that the administrator creates for ThinApp packaging are not counted as named-user licenses. Nor are the Fusion Pro base restricted virtual machines, which will be distributed to end users.”

That sounds correct, exactly as I understood it.  Each named user consumes 1 license and they can login to as many devices as necessary.

My customer then asked, “Can you show me where I can see the number of licenses in use currently?”

I proceded to go to the license screen which showed our demo license for 500 CVDs.  (CVDs are Centralized Virtual Desktops.  They are a enpoint that is protected by Mirage.)

The customer then asked, “Since a CVD represents an endpoint, how is your 500 user count accurate if the product draws off one license for each endpoint?”

“That’s a great question,” I said.

It would appear that the product is not actually managing the licenses as the software license policy dictates.  I have run into this quandary before in Mirage and I’ve not dug deep into the info to figure it out until now.

Surely I’m not looking at the right screen in the product so I grab my latest version (v4.2.3 as of this writing) of the Mirage Installation Guide and head to the section entitled “Managing Horizon Mirage Software Licenses”.

There I find this: “The Horizon Mirage Management server requires a license. The license file enforces the number of CVDs that you can run on your system and the duration of the license agreement.”  

Uh, wait what???  The admin guide says that the license is consumed by each CVD (or endpoint) and the KB Article says that the policy is per user.  Who’s right?

The answer is the policy.  The reason the product is drawing off licenses for CVDs is because Wanova (the company who VMware acquired who created Mirage) origionally licensed the product by endpoint.  It would appear that VMware changed the licensing policy so that it would work in a unified fashion with the rest of the Horizon Suite.  Unfortunately, it would seem, that the change in policy has not been updated in the current release of the product.

What is a customer to do?

My recommendation to my customers has been that if they find themselves approaching the CVD limit in Mirage but they have not exceeded their named user limit, to file a support request with VMware to request additional licenses for Mirage and reference the KB article above.  I am very confident that VMware will correct the code in Mirage to reflect the current policy in an upcoming release.  Unfortunately this has been confusing customers until the product code and the licensing policy become concurrent.  Hopefully this helps in the interim.

Aug 192013
 

Working with a customer today, they wanted to make some modifications to the Horizon View HTML access page.  Unfortunately, as of this writing, you cannot change the logo to be your company’s logo (hopefully changed soon!).  However, you can change the download link and add/remove the icons for HTML access and the client download.  Here’s how:

On the connection server with HTML access installed, open explorer and navigate to:

CommonAppDataFolder\VMware\VDM\portal\portal-links-htmlaccess.properties  on W2k8 this directory is C:\ProgramData (you will have to set explorer to show hidden files and folders to see it)

As of the time of this writing, there are 3 settings currently available:

enable.webclient = true/false  -This enables or disables the appearance of the icon for HTML access.

enable.download = true/false  -This enables or disables the appearance of the download icon to download the GUI client from the web page.

link.download = https://url-of-web-server  -This allows you to customize the location of where the client download comes from.  Note here: this does not do any checking of client OS to automatically direct to the right OS version of the client.

Please restart the VMware View Web Component Service after making any changes.

For additional information, please refer to this article with more details on HTML access.

Jul 312013
 

For those that may have missed it, VMware snuck out a point release of Mirage labeled 4.2.2 which has replaced the 4.2.0 binaries (even though many of the labels on the download site still state 4.2.0.)  Over the last month, I have had a few customers ask how to do this upgrade.  If you take a look at the Administrator’s Guide or the release notes for 4.2.2, you will find information on installing Mirage to a net-new system but there are really no steps to describe how to upgrade an existing installation to the latest release.  Until now.  This little nugget of information can be found in the recently released Mirage Reviewer’s guide as well as a recently released KB Article.

The procedure looks like this (copied from the Reviewer’s Guide as of the time of this writing, Page 29):

The upgrade procedure to Horizon Mirage 4.0 involves uninstalling the prior Horizon Mirage components and then reinstalling the 4.0 versions.

Uninstall the Horizon Mirage datacenter components in the following order:

  • All Mirage Servers
  • Mirage Management Console*
  • Mirage Management Server

* To uninstall in Windows 7, use the Windows Control Panel > Programs and Features (Add/Remove Programs for Windows XP)

Note: Uninstalling the Mirage Servers does not remove any data from the storage volumes that were connected to the Horizon Mirage System.

To install the Horizon Mirage components with the new MSI’s in the following order:

  • Mirage Management Server
  • Mirage Management Console
  • Mirage Servers

The SSL and port configurations are not preserved; you need to reconfigure these after you install the new versions of the Horizon Mirage components.

After the upgrade of the datacenter components is complete, when a Mirage-endabled endpoint connects to the network, Horizon Mirage automatically upgrades the Mirage Client and prompts for a reboot.

Not too bad of an upgrade but one to be aware of none the less as the previous versions need to be uninstalled.  Make sure to reference the detailed KB article with more detail and caveats to avoid.

 

Apr 022013
 

I’ve been diving deep in the lab with Horizon Workspace (review coming!).  Workspace can be used (with limited functionality) from just the web page portal but it is best used when you install the GUI apps for Windows, OSX, IOS, and Android.  One thing to note is that when the Workspace app for windows is installed, it will automatically deploy ThinApp packages to the clients that have it loaded (if the app is entitled to them of course).  So if you have the Workspace client installed in your View desktops, you can deploy ThinApp packages to them.  If I have the client loaded in my Windows home PC, I can get my ThinApp Apps there as well.  For my View desktops, I may want to stream my ThinApp packages.  If I have a logon storm of 100 users at 8am, I don’t want 100 network copies of Adobe Reader coming off my ThinApp share at the same time, crushing it.  For the home users, I want those pushed down locally.  Let’s remember: Adobe Reader XI comes in about 312MB when ThinApped.  Not exactly a download I want my remote users to start when they click on the Reader icon on their home PC and wait for the download to complete before seeing reader.  So for the home users, I want to have the full app downloaded to their endpoint operating system before the icon appears.  For my View Desktops, I want to present the icon immediately but only download the app when the user clicks the icon (after all, my View desktops are on a high speed network link to the ThinApp Network Share).  How do I accomplish this one way for the View desktops and another for the home users?

First, I’ll mention that there is no way to differentiate this by application in Workspace today (v1.0 remember?).  This is differentiated by the OS instance that the Workspace App runs on.  By default, when you install the workspace client, all ThinApp packages are set to download fully to the Windows Operating System.  If you would like to stream the apps you need to install the Workspace Apps silently using the command line options to change the default as explained in this page from the documentation from v1.0.

Here’s the example from the docs on how to run the installer:

VMware-Horizon-Workspace-1.0.0-12345.exe /s /z HORIZONSERVER=https://HorizonWorkspaceHost.com SSLBYPASS=1 /v DOWNLOAD=0 POLLINGINTERVAL=60

Where /v lets you specify the ThinApp Specific variables.  The one in question is DOWNLOAD=0.  0 means use streaming for your apps, 1 means download the full app to the OS where the workspace app is installed.  1 is the default.

If you have already installed your Workspace apps on your endpoints or in your View desktops, all is not lost.  You can just edit the registry (with a GPO if you like).

Here’s the key:

HKLM/Software/Wow6432Node/VMware, Inc./VMware Horizon Apps/DownloadPackages  REG_DWORD 0 or 1.  (0 is stream ThinApps, 1 is Download (the default)).

One thing to note:  The ThinApp sandbox for that package will not roam to the users endpoint on a home PC (or anywhere without some form of profile management).  The users profile is not in the Horizon Data folder so this information does not get shared with the other Horizon Data.  A little bit of a limiting factor, but something we can hope for in the next version.

Oct 052012
 

Was researching an issue for a customer yesterday morning and ran across a few articles mentioning this “Already Used” issue.  It was not really the problem I was looking for.  Ironically, yesterday afternoon, I had a call with a different customer that described this issue exactly.  At that point, I had to post it.

Here’s the issue:

after a user logs off, a desktop in a linked clone pool goes into an “Already Used” state and stays there.  No users can use it until it is refreshed by an admin.  I found numerous references to this issue but no definitive answers.  I even found this KB Article on vmware.com and it’s resolution is to just refresh the desktop (#EpicFail).  That was until I ran across this post in the Community Forums by Paul Woodhouse.

The issue is caused by the user selecting to shutdown the desktop instead of logoff.  Instead of refreshing the desktop, VMView restarts the desktop and puts it in an “Already Used” state.  I believe this may be by design to protect it from being used until an admin can review it (just speculating here).  Whatever the reason, this desktop cannot be used by anyone else until it is refreshed by an administrator.

Paul writes in the article that you can set the default option to logoff and also provides a script to run thru the desktops to look for any in the affected state and reset them in one shot.  I agree with one of the comments to the article.  I recommend removing the shutdown and reset options from the logoff button completely via Group Policy.  There is no reason to give users those options in a VDI environment.  Especially when you are using linked clones that are refreshed on logoff.  As reported later in the comments, removing the shutdown and reset options  from Win7 eradicated the issue completely from the environment.

Good luck.

UPDATE: It just occured to me that this is a user policy.  If you want to remove these options from the VDI desktops but not the user’s desktop or laptop, you have to turn on Group Policy Loopback mode and apply the GPO to the OU with the desktops.  This will apply this user GPO to all of the VDI desktops only.