Virtually Jason

I was building a VDI solution for one of my customers that leveraged App Volumes to build RDSH servers, which in turn presented applications via Horizon (is it still fair to call it a VDI solution if there's no desktop OS involved?).  We were managing the user experience persistence via User Environment Manager, so the RDSH servers were stateless and no unique data would ever live on any of them.  It's a really cool solution, but we ran into that classic VDI issue: slow logons. Fortunately, since that is such a classic issue, there's a huge list of things to do to alleviate it.  In this case, since the user's profile lives independently of the server to which they've logged on, we have a really powerful tool available to us: the Mandatory Profile. Windows does a lot of profile customization when a user logs in for the first time, which is great on a persistent desktop!  In a nonpersistent environment (which, for all intents and purposes, any RDSH solution is, be...

When rolling out a VDI solution (or really, anything that touches on the user experience), it's crucial to understand how the change might impact the users and to ensure that they are left with a good impression of the solution.  They say that first impressions are most lasting, and the first impression that your users are going to see (for most solutions) is logon time.  That means that it's crucial that your solution does not negatively impact logon times, as that will color the entire experience.  So, how do you accurately measure it? Well, VMware released a Fling called Logon Monitor (and, it's now baked into the Horizon 7.2 agent).  It's a tool that's sole purpose is to measure the logon process and to report on what's happening during a user logon.  After it's installed, it logs (with excruciating detail) everything that occurs during a logon, storing the file in a default location of C:\ProgramData\VMware\VMware Logon Monitor\Logs It creates a fi...

One thing that we always have to do (and people often overlook) when planning a VDI project is to understand the user environment and how to gracefully recreate their current desktop environment on the virtual desktop.  This is a big challenge, as you can tell from the fact that there are so  many tools available to solve it. In my experience the best solution is usually a combination of purpose built tools, of Group Policy Objects, and of the occasional login script.  Before you can even start figuring out which combination of tools and techniques might be most appropriate, you need to understand what currently exists in the environment... and you need a fairly accurate picture of that.  If the environment is already sophisticated with heavy use of GPOs for drive mappings, printer mappings, and critical registry settings, transitioning into VDI will be far easier than if new desktops are configured by an IT guy walking over and making all of those things by han...

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

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

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

When planning a VDI deployment, we all know that it’s important to define your use cases.  VMware’s methodology defines three main categories for these use cases: Task Worker, Knowledge Worker and Power User.  I see a lot of confusion in the field though – these are not use cases themselves.  I have yet to find an organization that can neatly divide their workforce into three use cases.  Instead, those categories are really just shorthand to allow us to roughly describe the resources that are required by the use case. Most environments will have several Task Worker use cases.  There might be a Call Center Task Worker use case, a Data Entry Clerk Task Worker use case and a Secretary Task Worker use case, all within the same organization.  This is perfectly normal, as “Task Worker” really means that the use case employs a very limited set of applications and does not require many resources.  So, how do you actually define a use case then? A us...

I recently had the chance to do some testing with PernixData ’s vSphere solution and it was very educational.  It worked great, doing exactly what it was supposed to do… and it also got me thinking about the nature of storage caching. For just about ever, caching has been the technique that allows storage devices to provide the blazing performance that we all demand.  Monolithic SANs always have some amount of cache on their controllers.  What exactly does that cache do?  As the name implies, it caches data.  On those SANs, we would typically assign some amount of read cache and some amount of write cache (I’ve typically biased my vSphere storage devices heavily towards write cache, but opinions vary).  When a write request comes in, it is very quickly written to that cache and the acknowledgement is sent to the device that is performing the write.  The SAN’s job is then to destage the data from the cache onto the disks for long term storage, whic...

Memory overcommitment remains a contentious topic, despite some really great studies on the topic.  Regarding VDI, I’ve heard opinions ranging from “0 memory overcommitment!” to “200%, 300%, it’s fine!”  I figured that I’d share my thoughts on the topic and see if anyone else wants to weigh in on the discussion.  First though, some points about the decision. The main argument that I’ve heard against memory overcommitment boils down to protecting the user experience.  Since virtual desktops have users actively logged into and using them, even slight performance degradation is immediately noticed.  We all know that hypervisor swapping is Very Bad for performance.  If you don’t overcommit your hosts’ memory, you won’t have swapping, so why overcommit? The simple answer is that, while 2 GB of RAM for a single desktop is no big deal, 2 GB of dedicated RAM for 1000 desktops is a lot harder to accept.  Memory overcommitment can be an important technique for...

I've done some work lately to improve my desktop restart script from earlier in the month. I've made a few important changes - now the script will wait (by default 10 seconds) between restart commands so as to not overwhelm the environment. That wait time is a configurable parameter; just invoke the script with the -wait # option to set it to wait for that number of seconds. This is especially useful for nonpersistent pools, as you can pass it a highish number (such as 45 seconds) in order to ensure that the bulk of the desktops in a floating pool remain available at any one time. I've also improved the script's session handling logic. It will now restart systems with Disconnected sessions (but will still not restart desktops with Connected sessions). It is also no longer sensitive to the domain suffix of the desktops. Finally, I found a condition where it would fail to issue a hard reset for a frozen desktop, if that desktop was so frozen that the VMTools compl...

One of the biggest challenges associated with VDI is supporting applications.  In the server world, we've pretty thoroughly moved to a "one application per server" mentality, so application conflicts don't really happen.  If there's a problem, it's immediately obvious which application is involved.  In general, it makes management much easier. Desktops, of course, are in the far opposite situation.  We shove as many applications into a desktop as the user needs.  This means that, when there is an issue, it can be very difficult to diagnose which application is misbehaving.  I've recently been helping a customer who has been suffering from random disconnects in their VDI environment.  The View Administrator shows the desktops with a status of either "Invalid IP" or "Agent Unreachable" and the Agent logs on the desktop haven't been particularly helpful. Eventually, we installed Liquidware Labs Stratusphere on the desktops, in orde...

When configuring Windows for use in VDI, we disable Windows Update.  Why push updates to 1,000 end points when you can instead update the master (be it a Linked Clone parent or an Operating System layer) and just switch everyone else over to the updated version?  Of course, your admins will still need to be able to update their master image, which isn't allowed if the Windows Update service is disabled. I know that it's easy enough to go in, enable and start the service, apply updates and then disable the service once again... but if something's that easy to do and must be done over and over, it's probably worth scripting.  In fact, referencing the XKCD "Is It Worth The Time" chart  (I'm so happy that I have an excuse to link to XKCD on here), since this is a monthly task and I'm probably shaving about 30 seconds off of the process, I can see that my 10 minutes spent looking up the commands to do this was time well spent! Anyway, the script is supe...

There are two very useful documents around making Windows 7 work in a VDI environment; I find myself searching for these with some frequency, in order to provide links for customers.  Given that frequency, I guess that it’s only appropriate that I make a quick post here about them. The first one is the Windows 7 Optimization Guide .  This guide contains a lot of useful (really, vital) steps that make Windows 7 work well in a VDI environment.  It’s an excellent guide, with information as complex as how to make a customized Windows install or as simple as just running a batch file that makes the changes.  It also explains the changes in great detail, listing requirements vs. recommendations, so it is definitely worth a read. The second one is a KB article.  When using multiple monitors, there will be “hitches” when a user drags a window from one monitor to the other.  To prevent this, you must change some VM advanced settings  on that VM. ...

We’re all familiar with the concept of the core four resources: CPU, Memory, Network and Storage.  These days, we tend to combine CPU and Memory into a single “Compute” resource (since they are both contained within a single object, the ESXi host), but the concept still holds.  When we’re talking about resource utilization for a VDI solution, we’re usually concerned with Compute resources and Storage resources; PCoIP, RDP, ICA – they’re all pretty efficient protocols, so even a single gigabit adapter provides more than enough bandwidth for the VMs on most VDI ESXi hosts (IP based storage, on the other hand, might see more benefit from additional bandwidth). So, how do we scale our Compute and Storage resources, as the project advances from POC to Pilot to a phased production rollout?  The answer to that question depends on how your infrastructure was designed – it was designed to be scalable, right?  At a high level, I’m seeing two different movements within th...

One of my customers has been having an intermittent issue with their Windows 7 VDI Desktops.  Occasionally after they update the Operating System, when the desktops boot back up they fail to use their NICs.  The NIC is still attached to the VM and is still on the right network, but Windows fails to recognize it (it doesn’t get a DHCP address and, in fact, registers within the OS as being physically disconnected from the network).  Restarting the desktop doesn’t help, reinstalling drivers doesn’t help (we’re using the VMXNET3 network adapter, for those who are interested).  Removing the adapter from Windows seems to be the key to getting the desktop back online.  We’ve gotten desktops back online by removing the adapter from Device Manager and then scanning for hardware changes (and rebooting).  We’ve also removed the NIC from the VM (with the VM shut down) and replaced it; that’s also alleviated the issue. Unfortunately, those steps just alleviate the...

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

You’ve rolled out a shiny new VDI solution, but most of your user base is on good physical desktops that don’t need replacing… and that you don’t have the budget to replace with thin clients yet.  What do you do?  I think that most VDI rollouts get to the point where they’re asking that question eventually.  There are two main answers that you get (ignoring the “replace them anyway!” opinion).  You can run your View Client as an Application on the desktop or you can run it as the desktop’s Shell.  In my opinion, they are both viable solutions... but they both certainly have drawbacks.  Let’s talk about the Application option first. The View Client is an application, just like any other.  That means that you can place a shortcut on the user’s desktop and, after they sign in, they can start it and log in to their VDI Desktop.  If they user needs to get out of their VDI Desktop, it’s very obvious that they can simply minimize the window (or even c...

Getting control over your Default Printer in a Windows 7 VDI environment is a little more difficult than I would have expected.  There are a lot of different factors that can come into play and, depending on the type of client connection, you can get some unexpected results.  Here are the factors that I know of that can set a desktop’s default printer: 1) The user’s Profile 2) A logon script/GPO 3) Windows’s spooler behavior when the default printer that it expects is missing 4) The TPAutoConnect.exe program (which executes automagically at PCoIP session connection) My current customer is intending to use a combination of #2 and #4.  The logon script is setting their network printer based on who they are and is responsible for 90% of the printer assignment.  TPAutoConnect.exe is used to install direct-attached client printers and map them into the VDI desktop.  The simple fact that the plan doesn’t involve #1 and #3 doesn’t remove them from the equati...

I’ll say it again – I’m not an Active Directory guy. That said, my customer had me out to implement a VDI solution for them and, as we all know, that’s highly dependent on Active Directory (at least, if you’re using Windows desktops). This particular customer didn’t have any printer deployment solution in place; instead they sent out a member of their IT team to configure each user’s printers manually. Needless to say, that printer solution doesn’t scale very well into a Nonpersistent Floating desktop pool scenario, and just as obviously, it fell upon me to guide them to a better solution. This customer is using Windows 2008 R2 print servers and has Windows 2008 Domain Controllers. There’s some pretty cool GPO based printer deployment solutions in this version of windows, so the first solution that I attempted was to just use Active Directory to deploy printers when people log in. I was able to get this working without too much difficulty, but in the Floating environment, it a...