Posts

Showing posts with the label Unidesk

VDI Layering Naming and Change Control

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 occasio...

Horizon View with Unidesk Network Flows and Operations

One of my customers recently asked me a question about his VDI environment.  I had given him a copy of my View 5 network flows diagram , but he was curious about what those flows actually do during day to day operations.  This struck me as a pretty important question, as the diagram is useful by itself when planning a new deployment, but when troubleshooting a problem it doesn't really help you to know where to look.  So, I typed up some explanations of what the system is doing on the back end during some common front end operations.  Since that's useful info, I figured that I should probably post it here in case it can help anyone else. External User Connections The External View Client initiates the TCP 443 connection to the Security Server.  This connection is used until the user selects the desktop to which they want to connect After the user initiates the TCP 443 connection, the Security Server connects to the Connection Server The Connection S...

Unidesk 2.6 Upgrade Problem

One of my customers was upgrading their Unidesk environment to 2.6 and we ran into a problem.  It proved to be an incredibly specific problem and not at all tied to Unidesk (just tied to the way they push this particular upgrade), but the troubleshooting process was very interesting and so I think it's worth putting this knowledge out there. As part of the upgrade, the Unidesk Management Appliance needs to install an OVF of itself (which is an uncommon but not unprecedented behavior for virtual appliances).  That is the step that was failing.  The most common source of that failure is a firewall; if port 443 is blocked between the Management Appliance and the ESXi host, that deployment will fail.  We went round and round with the network team, checking firewalls and couldn’t find any records of ports being blocked, but we couldn’t communicate with the ESXi hosts (although we could communicate with the vCenter server just fine). Eventually, we did a TCPDump ...

View 5 Network Flows with Unidesk

Image
Simon Long put together an amazing View 5.2 Network Flows diagram  a few months ago.  I recently had a customer doing a View + Unidesk deployment, so I figured that I'd put together a version that shows how such an environment works.  I didn't cover all of the View 5.2 features that Simon did, but I made sure to show how the various Unidesk components link into and talk to the VMware components, as well as how those VMware components work between themselves.  Since this was inspired (and largely informed) by Simon's work, I figure that it's only fair to post it here.

Followup to the Unidesk Deleted Layer from a CachePoint Issue

One of my customers deleted their Unidesk desktops from the View Administrator again and, once again, the system happily deleted a layer from the CachePoint.  This causes a problem in that you can no longer build desktops on that CachePoint that use that Layer (read that linked older post if you want more detail about that situation).  Last time this happened, we knew which Layer was affected because it was a rarely assigned application, but this time we didn’t have any such indicator.  We went through a discovery process this time that we didn’t go through last time and we came up with a far easier solution this time, so here’s the scoop. First, we had to figure out which Layer was affected.  To do so, I used the Datastore Browser in the vSphere Client.  I knew which CachePoint was missing the Layer, for that CachePoint was the one that was failing to build out the desktops.  I simply Browsed the datastore that that CachePoint manages, as well as th...

Recovering Unidesk Desktops, Deleted from View/vSphere

Update:  I just posted a followup to this post with an easier process for recovering a lost Unidesk Application Layer VMDK .  This post still has a lot of good information about what's going wrong with the system when one of those VMDK files are deleted, so it's still probably worth a read. We had a bit of a PEBCAK issue recently where an administrator (read: me) was cleaning up some older View only desktop pools to clear up resources to bring in more Unidesk desktops.  Inadvertently, a Unidesk desktop pool was deleted from the View Administrator and the option to delete all VMs from disk was selected.  Oops.  By and large, you could probably do this and get away without any issues (aside from needing to restore those desktops), unless you deleted all of the desktops that are using a particular instance of an Application Layer.  Let’s look at what happens in that situation (based on what happened when we accidentally did just that). When you op...

Recovering Unidesk Desktops from a Catastrophic Host Failure

I've recently had the opportunity to deploy Unidesk at one of my customer sites for their VDI solution.  I was preparing to write up a post about the install process, but it was actually very simple and is extremely well documented on their site (which is sadly behind an authentication wall so is not google indexed).  If I did end up writing such an article, it would end up just being a big love letter and wouldn’t be particularly interesting to anyone (well, with the possible exception of the Unidesk sales team).  Instead, I’m going to write this article about some of the things that I've broken and fixed, and some of the interesting things that you can do from a troubleshooting perspective. First, a brief overview of Unidesk.  It’s a Layering technology.  A given desktop is basically a collection of read-only vmdk files that are all stacked up together with their specialized driver in Windows to make it look like a single hard drive....