Virtually Jason

A few of my customers have large teams managing their VDI and all of the desktop layers that make up those desktops.  One of them asked for help creating a policy to track changes to those layers, as they had run into trouble with accidentally rolling out desktops using a layer version that was still undergoing testing or not knowing what changes had been made on a specific version of a specific layer.  This is a little outside of the normal content that I like to post about on this blog, but we came up with a solid policy that has helped them to get their environment under control, and so I’m going to do my best to explain what we came up with here. The first important detail to the policy was a strong naming standard.  We decided that layer names should be based on two factors, a group specific notation and the name of the application (or set of applications) in the layer.  Most applications are not group specific and so do not need a group notation, but occasionally there will be

One of my customers needed to do a complicated migration recently.  They wanted to move their View + Unidesk VDI environment from vCenter 5.1 on Windows to the vCenter Server Appliance running vCenter 6.  We moved the ESXi hosts and used them to carry the desktops over, just like we do with servers in this sort of situation, but the View stuff added to the complexity.  On the Unidesk side, there's a nice KB article that we followed, but there isn't such guidance for View. You may not have noticed it (I sure didn't until this migration), but on the list of desktop pools, there's a column that lists the vCenter server on which that pool was created.  It turns out that the pools are irrevocably associated with the vCenter server itself and so, when you migrate vCenter servers, you have to recreate all of your desktop pools.  This customer had about 2 dozen pools; an arduous task, but ultimately not all that time consuming... until you think about the ramifications of de