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.

Oct 262012
 

A updated build of vSphere was released tonight.  Although not listed in the release notes, this build proved very important.  vSphere 5.1 is now supported with View 5.1.x.  Please be aware however, you must be using the new build of vSphere that was released tonight.  If you already have vSphere 5.1 installed and are ready to install View, you can just apply patch ESXi510-201210001 to your installation.

For all the details you can refer to this KB article.

Additionally, the VMware Product Interoperability Matrix has already been updated to reflect the new build of ESXi and vCenter required for View 5.1.x.

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 ConfigurationAdministrative TemplatesSystemUser 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.

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.

Oct 022012
 

I’m kicking off a new series on the site on tips when putting together a VDI environment.  What many admins and architects forget is some of the things we need when building a larger VDI environment.  Here are some of my most common best practices when building one of these environments.  These are specifically around existing infrastructure and I have run into issues with all of these points at customer sites.

  • Active Directory Sites – Many customers create a new network subnet in their environment for a new VDI deployment.  Make sure that you if you create a new subnet for VDI that you add it to Sites and services so AD knows where to authenticate the VDI users.  (I once had a customer whose desktops were authenticating to their DC in their DR site. – not the best use of WAN traffic.)
  • DHCP – This one has been very frequent lately.  You have to remember that VDI can be very fluid, especially if you are using floating desktops with refresh on logoff (my personal favorite.)  Because of this fluidity, you have to make special considerations with DHCP.  If you are not careful, a recompose of a large pool of desktops can deplete your available IP addresses in your DHCP pool.  You should set your DHCP lease to 1 hour for all of the subnets where VDI desktops will reside.  You should also set a script to run, either on shutdown via group policy or by the View agent by configuring the power-off script in the quickprep settings.  For details, take a look at “The Resolution” section in the blog article here.  This script approach will release the IP addresses when the desktops refresh and then renew them when the desktop restarts.  The issue comes when an admin has to delete some desktops.  In this case the scripts do not run to release the IP addresses, however, your shortened lease time will pick up those IP addresses in an hour.
  • DNS – make sure that your forward and reverse zones are working well.  You should have dynamic updates enabled so that you can have the desktops register with DNS correctly.  I have had customers try to use DHCP to update DNS but this always seemed to run into some kind of issue so I typically try to deter customers from using that approach.
  • DNS #2 – Also when using an internal and external facing environment, make sure to set the proper DNS records and their resolution to the correct internal/external brokers for users who may be logging in form both scenarios.
  • Read-only DC’s – If you are using read-only dc’s in your Active Directory environment, you may want to have a look at this MS KB article.  I ran into a few issues with a customer running XP and building their base image, we forgot this and they could not authenticate.  If you run Read-only DC’s, make sure to fully read the article.
  • OU Creation – Make sure when you create a new Organizational Unit in AD that you DO NOT select “Protect container from accidental deletion”.  If you are running XP desktops this setting will prevent them from joining the domain correctly.
  • Firewall ports – make sure the correct ports are open for the security servers and the brokers.  This article is a great reference to make sure you have opened what you need.
  • Group policy loopback processing – You’ll definitely want to have a look thru this MS KB article.  Group policies apply to users or machines.  When you use loopback mode, it allows you to set a policy that has a user policy that only applies to those machines.  So say you wanted to have all users of VDI desktops to have the same wallpaper, but you wanted them to have their regular wallpaper if they log into their regular desktop.  That’s when you would use loopback mode.

These are some of the issues I’ve run into as of late.  Feel free to post any others in the comments.  Next design tips will be: Network.