TechTarget Virtualization Media Geek Week VDI Day 4: Microsoft "in box" VDI solution summary The idea behind Geek Week is simple: Brian Madden and Gabe Knuth examine, as best they can, one vendor's product per day for a week. For this inaugural Geek Week, they chose to take a look at VDI products from the companies that you, the community, wanted to see. This article is an over the shoulder account of their day in the lab where they installed Microsoft s VDI product from scratch, including provisioning desktops for users and connecting remotely. Sponsored By:
Geek Week VDI Day 4: Microsoft "in box" VDI solution summary by Gabe Knuth This post, like all five Geek Week: VDI wrap-up posts, was co-written by Brian & Gabe. Geek Week Day 4 brings in Microsoft, and we were looking forward to getting back into the Windows world. Joining us were two "Softies," Eric Schroeder and Michael Kleef. Our goal for the day was to eventually test VDI Suite, while stopping along the way to test the "in box" VDI solution that Brian wrote about back in February. What we learned is that "in box" does not mean "simple" or "easy," and we never actually did get to the full VDI Suite. We did, however, get to see some pretty surprising performance from RDP in our WAN simulations, and that alone was a pretty positive takeaway from the day. Before we get started, we should mention that lacing all of these technologies together has been simplified through the use of a handful of scripts or small applications. Whenever possible, we linked to them (we should have gotten them all), but if you catch something that we missed, let us know and we'll track these guys down and get it from them. All the scripts and apps that we used are available for free. The whiteboard Before we got started, Michael Kleef spent some time on the white board explaining the bits and pieces of what we'd be doing today. Not more than two minutes after we started recording, yet another organized gathering attended by us was interrupted by a fire alarm that called for evacuation. That brings the total to three (BriForum 2006 at the National Press Club, iforum Edinburgh 2007 closing party, and Geek Week: VDI), plus a bomb scare (also during BriForum 2006)! So, after the evacuation (and an early lunch), we reconvened at the whiteboard where Michael went on explaining the important parts of the "in box" VDI solution. Microsoft "in box" VDI solution installation and configuration With an already shortened day, it was time to get busy. We managed to shorten the video down to about 30 minutes, but it took the better part of the afternoon to actually get this installed and configured. Since the "in box" solution is more or less a collection of loosely joined pieces that just happen to work together, we ended up spending most of our time just getting it to work. To begin, Eric showed us a simple way to create VHD files using an app called WIM2VHD. WIM stands for "Windows Imaging Format," and WIM files exist on the installation media for all versions of Windows made after and including Sponsored by: Page 2 of 6
Vista. In just a couple minutes, the utility converts the WIM file into a sysprepped VHD file that you can import into Hyper-V or Virtual PC, or even boot from natively. After creating our VHD, we created a new VM and used the VHD we'd just created. This entire process is nothing special, except that we went bare-virtual-metal to installed, sysprepped Windows 7 in about five minutes. We still need to give it a name and detect hardware and such, so there's still a reboot to do, but the time to install Win 7 is drastically reduced. Next, Eric created copy-on-write differencing disks that are used by users to maintain state separate from the master (or parent) image. Differencing disks can be configured to be persistent through reboots or to be wiped after each reboot. The main caveat (and the difference between this and the other products we've seen) is that changing the parent image invalidates the differencing disks. Another interesting note is that the differencing disks need to live on the same volume as the parent image. So, for instance, you can't have your parent image on the host and the differencing disks on a SAN. The next step for us was to make some tweaks to the VM, such as enabling RDP, turning on and configuring the Windows Firewall, and enabling some RPC management interfaces for communications with RDS and RDV (the bit that ties RDS into Hyper-V). Eric used a PowerShell script called "Configure Guest OS for Microsoft VDI". This script can be (and is usually) incorporated into the image creation process, but we singled it out to show that it needs to be done. Before continuing, we noticed that we hadn't installed the RDV role on to the Hyper-V host, so we took a minute to do that. It's just a matter of finding and selecting the "Remote Desktop Virtualization Host" role in server manager. It's actually a sub-role under the Remote Desktop Services role. Now we need to enable the Remote Desktop Session Host for redirection. Remote Desktop Session Host is the new name for a plain-old Terminal Server. Right now you might be asking "Why the hell would you need a Terminal Server when using VDI, and while we're at it, what the hell is redirection mode?" The reason for this, as explained my Michael Kleef, is that when Remote Desktop Clients connect to the Remote Desktop Connection Broker, the Connection Broker is expecting to find a session host (Terminal Server). Redirection mode is basically just telling the connection broker "Yeah, I'm here, carry on," so the connection broker can go on its way. While we were installing the Connection Broker via the setup wizard, we realized we hadn't yet configured TS Web Access, so we added that role to the same server as the Connection Broker. To complete the setup of TS Web Access, Eric went to the web site, logged on as admin, and specified the name of the Connection Broker server. We're almost ready to start brokering desktops, but there's still a few more steps. First, we have to go back to the Connection Broker wizard and point it to the Hyper-V server that is running the RD Virtualization Host role. Then, we also need to point the Connection Broker to the RD Session Host (Terminal Server) server. Once the setup wizard is completed, it automatically launches another wizard that allows you to assign virtual desktops to users. Sponsored by: Page 3 of 6
The first thing we do in this wizard is pick a user account and a machine to which that user will have access. When we selected the appropriate machine, we were presented with an error that the name of the VM in the Hyper-V console must match the FQDN of the VM in Active Directory. To fix this, we actually have to go into Hyper-V and rename the VM's to be the same as the computer name. The reason for this, as Eric explains, is that it has to do with how the machine attribute is assigned to the user, and Hyper-V is more or less appending the domain name to the end of VM's name. The main purpose of this is to allow the Connection Broker to keep track of a specific VM in the even that it's moved from one Hyper-V host to another. After we changed the name of our VM in Hyper-V, we finished up the assignment wizard and tested our connection. Now we were ready to move on to the user experience testing. The user experience Before we started testing, we huddled up and tried to come up with a test method for using the "client hints" that are in the Remote Desktop Client. If you're not familiar with that term, client hints are the different connection scenarios that you can select from the Experience tab in the RDC. Each one is pre-tailored for certain connection types and conditions. This can be configured at the web interface, but it's web interface-wide, and isn't using any automatic client detection to pick which client hint to use. The only way to provide, say, three different connection scenarios is to stand up three separate web interfaces, each with their own connection configurations. Obviously this is cumbersome, but it does give the user the best experience based on the connection type. We chose to test a scenario like this, but by specifically setting the client hints in the RDC, not using the web interface (to save the time of setting up two more web interfaces). We also learned dug a little deeper into the Satellite client hint and came a way pretty surprised at the performance, even in our bad WAN scenario. As usual, the best way to convey the user experience is through the video, so check it out. The Bottom Line From Gabe: I think the FQDN thing put me over the top with this solution. Comparing apples to apples, if you remove dynamic provisioning from the equation (since the "in box" VDI solution doesn't have that as a feature) and just compare getting the desktop broker piece up and running, Microsoft is easily the most complex thing we saw. Now, I didn't have very high expectations for Microsoft coming in to the day, since neither VDI solution is really targeted for enterprise-wide implementation, but I was still a little disappointed there. The scripts that Eric used were very helpful, but it would be really great if someone...anyone...create some sort of wrapper for the config in order to make this a simple process. We cut out a lot of footage where we were looking for specific settings in several different places, uninstalling roles so we could put them on a different machine that wouldn't conflict with something else, and so on. Sponsored by: Page 4 of 6
Still, while it was as slick as sandpaper, it did work in the end. So, with a little effort, it is possible to stand up a, more or less, free VDI solution. The highlight of the day was using the "Satellite" client hint when doing the WAN testing. It was really amazing to see the difference in performance between it and the other client hints that we used. We still had some of the same RDP-like issues, and there were no negative surprises when it came to RDP (everything we saw is pretty wellknown), but the Satellite experience was quite a bit better than expected. From Brian: Since Microsoft's VDI solution is based on Terminal Services, I felt that I'd be pretty familiar with how this solution works. I know Terminal Server. I know System Center. And I know RDP. No surprises. I also knew going into this that Microsoft's solution is based on a bunch of loosely-connected components and that it's not exactly what you'd call "simple," so again I felt like I knew what we were getting into. And I can confidently say, for better or worse, that Microsoft's Windows Server 2008 R2 "in box" VDI solution was exactly what I thought'd it be. There are a lot of moving parts that aren't necessarily designed to be used in this way, and even once it's all working it's confusing to keep things straight. (Even with the Microsoft guys onsite, we had more than one occurence of "Oh wait, that's configured over here, not there," and "Where is that setting again?") In terms of practical limitations, the Server 2008 R2 in box solution is mostly missing the ability to thin provision shared master images and the ability to load-balance incoming user connections. Those two things right there limit Microsoft's usefulness to only the simplest or environments. But the irony, of course, is that Microsoft's VDI offering over-complexifies these simple solutions.. Like there are just a ton of moving parts to get integrated and working with no super cool result. (At least Citrix XenDesktop's complexity gives you a great environment when you're done!) If I'm a smaller environment, I'm probably going with something simple to setyup like VMware View Quest vworkspace (or even one of the complete solutions like Pano Logic). I just can't see wading through the Microsoft muck just to end up with what they offer. Oh wait. It's free. ("Free" as in if you buy the requisite MS licenses for any VDI product, you have by definition bought the licenses you need to deploy the Microsoft in box solution.) So if your company is super poor or super cheap, and you like to script things, then the Microsoft in box solution might be for you. (Of course if you're super cheap, I don't think VDI is for you in the first place.) Sponsored by: Page 5 of 6
Resources from VMware Experience the World s Most Amazing View. VMWare View 4 Why VMWare View? Calculate your Virtual Desktop ROI About VMware Manage thousands of desktops from a single console with the world s leading desktop solution VMware View 4. Centralize desktops, applications, and data for increased control, versatility, and security. Reduce your total cost of ownership by 50% with the only virtualization solution specifically built for desktops. Enjoy the view. Sponsored by: Page 6 of 6