Horizon Workspace and View Persona: They’re dating, but not married.

 Desktop Virtualization, Tips and Tricks, Troubleshooting, VDI Design  1 Response »
Apr 172013
 

Here’s what I want to do:  Login to my View desktop, create a word doc.  Save it to my Horizon folder and then open it on my mac as Horizon data sync’s it down to me.  This process works by design and works very well.

Here’s were we go astray:  Now I want my VDI desktop to be a floating pool with Persona Management.  I use Persona in the lab because I want a floating desktop but still want my profile (IE links bar, etc) saved between sessions.  Now let’s try this scenario:

Login to VDI desktop.  Save a document to my horizon folder.  Logout of VDI desktop (persona is saved to network share, horizon data copies file to all my devices).  Open horizon Workspace on my iPad and delete the document (the document disappears from all my devices). Login to my VDI desktop (persona pulls down my profile – including the Horizon directory from the CIFS share).  Unfortunately Horizon data now sees this document as a new version and it reappears on all my devices.

The solution to this dilemma is to exclude the Horizon directory from persona management (via GPO).  However, when you do this you get a warning message that your Horizon Folder has been deleted upon each logon.  When you click OK, your Horizon folder is recreated and all of your data comes down from the server.  However, if your Horizon data repository is large, this could be a huge chunk of data each time you login to your floating-pool VDI desktop.

Hopefully VMware will correct this in the future with Workspace, these two features are great to use together.  Persona for the quick login with user persistence and Workspace for sharing data between all your devices.

I’ll post any updates here if I find a workaround.

 

 

 

Utilize ThinApp Streaming with Horizon Workspace and View Desktops

 Administration, Desktop Virtualization, Tips and Tricks, VDI Design  Comments Off
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.

32-Node VMFS Clusters and Sparse Virtual Disks for View? Not just yet.

 Desktop Virtualization, Storage, VDI Design  1 Response »
Oct 312012
 

I was doing a little research for a customer yesterday and they asked a great question: “Now that View 5.1 supports vSphere 5.1, can we use 32-node clusters with View 5.1?”

First a little background.  Today you can only create 8-Node Clusters in vSphere if you are using iSCSI or Fiber Channel storage.  The reason is because the number of hosts that can share a file on VMFS in vSphere 5.0 and prior is limited to 8.  If you are using NFS with View 5.1 and vSphere 5.0 or higher, you can have 32-node clusters for your View desktops.  vSphere 5.1 changed this limitation by changing the file locking mechanism and now allows for 32-node clusters to share a read-only file.  Secondly, vSPhere 5.1 introduced Sparse Virtual Disks.  These Sparse Disks are virtual disks presented to the desktops that can shrink as easily as they expand.  This is a real benefit and may rival linked clones one day to most efficently deliver a pool of desktops on storage.  You can read more about these two technologies from Cormac Hogan, Sr. Technical Marketing Architect at VMware.

As I’m sure you know by now, as of last week, View 5.1 and 5.1.1 are now supported with vSphere 5.1.0a.  So the question was asked: now that they are supported together, do we get those cool new features that Cormac was referring to?  Unfortunately, the answer is no, not yet.  I searched for a long time trying to find an answer.  When I came up empty, I just emailed Cormac directly.  He responded this morning, “…both features are waiting on a future release of View.”

Bummer.  Hopefully we’ll get the chance to get these two great features very soon.

Have a great and safe Halloween.

Gaining Administrative Rights to the Persona Management Share

 Desktop Virtualization, Tips and Tricks  Comments Off
Oct 102012
 

One of the challenges I’ve run across recently is when using Persona Management in View, the default permissions on the Persona network share are only for the user.  If an administrator tries to take a look at the share, they are denied.  If an administrator tries to “Take Ownership” of the user’s persona folder, it can cause numerous issues and cease to function for that user (requiring a restore of that users Persona directory or total deletion and regeneration with a new clean profile – losing the user’s data in the process.)

So how does an admin get rights to the user’s persona directory to repair a single file without destroying the persona completely?  There is an MS group policy object that applies here.

Computer Configuration\Administrative Templates\System\User Profiles

Add the Administrators security group to the roaming user profile share

By enabling this policy, administrators will have additional rights to the profiles so that they can edit them if needed.  Perhaps you corrupted your sandbox environment for a specific ThinApped application, now the admin can erase just the sandbox for that app and not have to restore or erase any more information than is needed.

Additional Notes:

  • This works for the user’s persona only.  If you are also using redirected folders, those targets will still only give the user permission to that data.  This policy does not apply to redirected folders.
  • This does not add administrator permissions to persona folders that already exist on the persona network share.
  • The group that gets added is local administrators for the server that the share is on.  This may be an issue if you are using MSCS for your network share.  If the share switches MSCS nodes, those administrative permissions will not apply.

Good luck.

VMware View desktops appear in an “Already Used” state

 Administration, Desktop Virtualization, Tips and Tricks  Comments Off
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.

 Older Entries