Virtually Jason

One of my customers recently asked me to help them set up a stand-alone DR solution for their Unidesk + VMware View VDI.  We decided to try out the Unidesk LayerSync utility, to replicate their desktop configurations to the remote site, where we installed brand new View 6.1 connection servers.  There were a few small challenges to getting that running, but it's still in beta so that's perfectly understandable.  After we got the replication working, we stood up a few desktops as a test.  They booted up fine, all of the layer assembling as expected, and we were able to log into the consoles without trouble. We came across an issue though, Unidesk successfully added the desktops into the selected pool, but View reported them as being Agent Unreachable.  I went through the normal troubleshooting steps (testing name resolution, checking HKLM\Software\VMware, Inc.\VMware VDM\Agent\Configuration\ to make sure that the Broker setting is correct, verifying that  ...

One of the big new features of View 6 is the ability to use Terminal Server… err… I mean Remote Desktop Session Host RemoteApp applications .  As you’ve probably seen, the application presentation is pretty slick, behaving very much like natively installed applications even though they’re running on a server in the datacenter.  This allows for neat little tricks like launching Windows applications on an Android device.  In the demonstrations, this feature is just about always paired with Workspace 2.0, showing those RDSH applications in the Workspace 2.0 launchpad. It isn’t really clear from the marketing that’s going on, but RDSH application support is a View 6 feature, not a Workspace 2 feature.  When you want to present a RemoteApp, you must register the RDSH server in View and create an Application Pool.  From there, you can optionally tie it into Workspace or you can just launch it directly from the View Client – your choice.  So, how do you insta...

When working with VMware View (or any VDI solution for that matter), you’ll eventually have to deal with certificates.  Hopefully your organization has a skilled web or security team who can help you install the certificate onto the Connection Servers and Security Servers… but I find that that’s not usually the case.  Usually, someone either just downloads the certificate from GoDaddy (or whatever authority they use) or gives me the credentials so that I can download it myself. The problem is, what you download from GoDaddy isn’t going to work, at least not by itself.  There basically two parts of a certificate: the public key and the private key.  When you go to GoDaddy and launch their interface and download your certificate, you’re downloading the public key (and any intermediate certificates that are required to establish a chain of trust).  In order to install and use that certificate, you’ll need to provide the corresponding private key (which was used i...

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

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.

Ok, this one is going to be another short one - "just a few paragraphs" short, at least.  I was configuring some View Security Servers for a customer today and came across a bit of difficulty.  Of course I had to tweak the physical firewall (I always forget to enable bidirectional esp), so I had to stop the process, make the new rules and then start up the installer again.  No big deal.  I got to the pairing point and, since the prior install had begun, I figured that I'd better make a new pairing password, which I did and promptly entered into the security server. "Invalid Password" the error box glibly told me. Ok, must've been a typo, so I tried another password.  Still, no dice.  4 failed pairing passwords later, I'm starting to think that I've either lost my ability to type or made some fundamental ID:10T error (trying to pair with the wrong Connection Server, setting the pairing password on the wrong Connection Server... something like tha...

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

If you’ve ever set up a View Security Server for external access, you’ve probably invested a fair amount of your time looking at firewall port requirements.  I sure did.  And then, after all that time, I still ended up falling back on trial and error, for at least a little bit.  Rather than repeating that process (and to hopefully help others), I’m putting together a quick post with my notes.  This engagement is using vShield and is securing the Security Servers with these rules, preventing both incoming and outgoing traffic (except for what is explicitly allowed). First, there is an excellent list of general network portsrequired for VMware products , which can give you a good place to begin.  There’s a more detailed list of View Network Port Requirements  as well, which is an even better place to begin (but, if you’re working with other VMware products, the general list is a good resource to have available). Unfortunately, as I’ve mentioned, tha...

We’re working on remote access for a View solution at one of my customers right now.  We’ve got a pair of external user Connection Brokers, each partnered with a Security Server.  We’ve also got an F5 Big-IP load balancer sitting in front of the Security Servers, giving them some protection from the big bad ‘net and, more importantly, providing load balancing services.  We found that the process was a bit more circumspect than I had expected, involving instructions from several documents, so I’m consolidating our process here.   At first, we followed the instructions from the F5 View Deployment Guide , which got us really close to what we needed.  It’s worth noting that the “External URL” and “PCoIP External URL” fields should be the public address of the F5, even though the document uses an internal address in its examples. We were able to connect to the system by our public name and it presented the list of desktops to our test account.  Howev...

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

One of my customers asked me to convert some of their physical Windows desktops into dedicated VDI Clients.  A quick google search revealed a VMware Blog post  with some basic instructions.  They’re written up for Windows XP, but they work fine for a Windows 7 Client as well.  Basically, you just change the registry on the client machine to run a VBS script that calls a batch file that starts the View Client, instead of starting up the normal Explorer shell in Windows.  It’s a very easy change to make and, while it’s quick and dirty, it does what it’s designed to do.  I use a slightly modified view.cmd file, as seen below. Rather than just starting an infinite loop that keeps the View Client running, this version will allow a user to actually log off of their client device when the View Client closes.  If not for that change, when they log out of VDI, they’re right back at their desktop selection screen, since the user is still logged in to the clie...

A customer recently came to me with a very specific request.  They wanted all of the drive mappings that each user had created on their local workstation (their View Client) to be created on their VDI Desktop.  Without roaming their profile, I created a simple logon script for the VDI Desktop to execute (VMware’s Profile Migration does not capture Drive Mappings, at least not when converting from XP to Win 7).  As you’ll see below, I really just found 3 other smarter people’s scripts and mashed them together  (with some minor adjustments to work in the VDI scenario) in order to get them to do what I needed.  Since the results are highly specific (and a bit interesting), I figured that I’d go ahead and post the script.  Be aware that it abuses the fact that, in this environment, everyone is a local administrator on their physical desktop, so I expect that some of the client registry queries might fail under other circumstances. Just so that everyone kn...

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

So, I implemented Persona Management a few months ago and figured that I’d write a quick followup with my experiences since then.  As a technology, it strikes me as both really cool and a little difficult.  It deals with the persistency issues that you would typically enable Roaming Profiles to resolve, and  I haven’t seen any of the profile corruption issues in Persona Management for which Roaming Profiles are infamous.  So, that’s a plus.  It also does what it’s supposed to do, which isn’t always a given when you’re working with relatively new technologies.  That said, there are some issues that it seems to have introduced into this environment. 1) Rapidly logging back in after logging out causes a hung logon. 2) Loopback processing applied logon scripts are ignored after the initial Persona is created. The rapid logoff/logon issue doesn’t strike me as vital.  I’d certainly like to fix it, but that’s a fringe case and it seems to be self-correc...

One of my customers has been trying to figure out how they are going to deal with printer assignment in their View environment.  In truly stateless desktops (without Persona Management, even), you have to completely depend on external printer assignments, either through a logon script or through Active Directory.  I prototyped both solutions for this customer.  In order to minimize our logon times, we preinstalled our printer drivers in the parent image (for both tests). We found that a normal Windows 7 logon onto a stateless desktop (where it’s always the first logon and so has to create a local profile and apply group policy) takes about 20 seconds from the time the user hits “connect”.  Using Group Policy to distribute printers increased that logon time to about 45 seconds… which was a bit too much for my liking.  Using a logon script, on the other hand, does not delay the logon process (even if the printers are not actually present immediately upon log...