Guest Bloggers

Perspectives on VDI from a total n00b

Justin Meisinger — Fri, 09 Sep 2011 13:00:00 GMT

I’ve been with TechTarget & BrianMadden.com for exactly one year now. In my initial interviews with Brian and Gabe, they asked whether I knew anything about virtual computing. I answered "yes," which wasn’t a lie, but now I realize it wasn’t exactly true either.

Up until that point, my experience with virtualization was limited to using the Windows RDC client on my Macbook so I wouldn’t have to get up to add torrents to my desktop computer’s download queue. (Yes, I’m that lazy.) I had also dabbled with an, umm.... “evaluation” copy of Parallels Desktop for Mac thanks to the aforementioned torrents. (Although it never worked right for me and I gave up on it pretty fast.)

But what a difference a year makes! In the past twelve months I’ve attended two VMworlds, Citrix Synergy, two BriForums, read countless Brian and Gabe articles, and shot videos with knowledgeable people such as Atlantis Computing’s Jim Moyle. I now know that desktop virtualization isn’t just a single protocol or product, and may be comprised of RDP, PCoIP, SPICE, RemoteFX, EOP, HDX... the list goes on and on, seemingly growing with every vendor show we hit.

And this all got me thinking: How does anyone jump into this and expect to understand it? I mean there are dozens, if not hundreds of vendors with multiple solutions--some proprietary, some not. Some vendors like Ncomputing sell an end-to-end solution controlling the hardware, software, and everything in-between while others try to slip into your existing setup on nothing more than a flash drive and a prayer.

And of course there's the fact that the majority of the discussions on this website center around whether or not VDI is even for you and your business. And I'll tell you what: I’ve read every article published in over the past year and I still don’t have a clue. As an industry, VDI can’t even seem to be defined with precision.

As Brian has written before, we don’t use VDI at TechTarget. It doesn’t suit our use cases at all. Especially mine... You ever try video editing a high definition video file over a WAN? Me neither, and it likely isn’t happening anytime soon even with all the fancy HDX3DRDPCoIP (George Lucas, this is not the droid you’re looking for) blah-bity-blah coming out this year. Earlier this year, Brian tried setting up VDI for just himself, running a server out of his closet at home. It had a dedicated cable line out and he tried to access it from work on our DSL. Success was non-existent. And he KNOWS what he’s doing! What the hell am I expected to do?

We’re not the typical use case, though. Then again, is there a typical VDI use case? I guess one could say businesses with sensitive material and a penchant for letting their employees work remotely is the ideal case. Beyond a few government agencies, I honestly couldn’t think of too many examples that fit this paradigm. Price-points are dropping for virtualizing desktops in the office, I guess, but it still has a lot of the old gremlins. Janice over in Accounting still tends to lose her LOLcat wallpaper every time she ‘reboots’ her VM. My takeaway from all this is that, no matter how seemingly mainstream this all is, it’s really still niche. Your IT guy might get all giddy but it's unlikely The Situation will be all over a bare-metal hypervisor anytime soon unless MokaFive starts handing out spray tans.

A friend of mine recently asked about my work and I threw out a few examples of companies we work with. She had actually heard of Citrix, and we talked a little about possibilities. In the end, we decided we still couldn’t stand trying to use Windows 7 on an iPad. It felt like trying to drive a remote control car with my hands tied behind my back in a snowstorm.

So, what’s my point to all this hating?

Put away the pitchfork, it’s actually the opposite. This stuff is really exciting. Think about it: you have your computer, that thing that was either tethered to your desk like a boat anchor or you carried around in a giant padded bag, for the past 20+ years all of a sudden accessible from ANYWHERE. If I drop my Chromebook down one of San Francisco’s gorgeous sewer drains or my iPad gets run over by a bus, it’s a bad day but I’m not left sobbing because my drunken college photos are gone forever. I just need a new endpoint.

What we’re seeing now is the tip of the iceberg, the Wright Brothers flyer of methodology. Steve Jobs likes to say we’re in a post-PC world, but I disagree. I think we’re entering a post-physical PC world. Your PC experience will be alive and well, just not strapped down like the old ball and chain. The public is all “cloud-happy” now with the consumerization of IT, but I think what you’re really seeing is two technologies destined to get together and birth the next iteration of our computing experience. Your apps, your data, your stupid cat wallpaper, your everything, accessible anywhere, on any device, delivered remotely over blazing 4G networks and deliciously fast FIOS. And not just companies, but everyone.

Imagine instead of needing a new computer, you just pop on to your Wyse thin client, log on and “upgrade” your $10/month subscription from the 2 GHz PC experience to the $20/month 4 GHz with GPU acceleration version. You’d never buy another computer again…even upgrading a Mac isn't that easy. No longer does VDI seem scary but even less scary than the current purchasing cycle, and way easier for the consumer.

Will all this come to pass? I don’t know. I’m dreaming pretty big here, but it’s not like companies aren’t toying with it. This is all coming from someone who gains all his knowledge from trade show demos whichdon’t even always work right when being hosted on a carefully manicured local server. But even a noob like me can see the value and the future in it. I guess I've learned something after all.

Subnote: If anything here is wrong, remember, I’m your typical consumer. We don’t always get Ghz vs. Megabytes or GPUs vs CPUs. We definitely don’t understand what a thin client vs. a zero client is. And there are literally billions of me who haven’t discovered any of this yet..but they will.

Can V3's specialized VDI host/storage solution compete against the big boys of HP, Dell, and Cisco?

Jack Madden — Fri, 12 Aug 2011 04:01:00 GMT

Startup hardware vendor V3 Systems is offering VDI-specific servers with claims of high performance and ease of use. But some people wonder whether they’re nothing more than just a fancy bezel on a Super Micro server with a Fusion-io card.

V3 came on the scene about a year ago promising to make VDI practical for the masses, with co-founder Peter Bookman bringing his experience at Fusion-io to the table. Their website claims reduced CapEx and OpEx, simplicity, and ease of use, all through a 1U plug and play box that can deploy 50-300 desktops in an hour. They have shown demonstrations of VDI desktops that are 2 to 8 times faster than physical desktops, using a solid state infrastructure from Fusion-io.

In marketing materials, V3 compares their solution to SAN-based VDI deployment, which is somewhat of a polarizing issue. More importantly, though, we also have to remember that VDI is not for everyone, but rather for limited use cases. Like Brian said, “Most people need VDI like [they] need a hole in their head.” Also, we know how suspect claims about anything to do with cost models can be. With that disclaimer, we have to look at V3 just within the context of other high IOPS VDI solutions.

It turns out that V3 is coming into a space that’s already pretty full. At first glance, it even seems like V3 is a bit late to the Fusion-io party, too. IBM was partnering with Fusion-io since Project Quicksilver was wowing people back in 2008, and is now even offering a discount on its products. Dell has had a relationship with Fusion-io since its early days, and HP also offers Fusion-io products.

So if you can buy a Fusion-io card bundled into a “real” server, why buy a Super Micro from V3? On one hand, this appliance could make a first-time VDI implementation easy and fast. On the other hand, if an IT department can’t figure out how to pick out a server from one of the big guys, then they have no business doing VDI anyway.

Beyond the offerings from the bigger companies—companies that IT departments already have relationships with—there are other solutions out there—Whiptail, XtremIO, STEC—that remind us that V3 is not alone. Whiptail markets their XLR8r (“accelerator”... get it? :) for VDI among other uses, not in the focused way of V3’s marketing. XtremIO seems to be going in a similar direction; while they don’t have any products yet, they did get $14m in Round B funding last month. Pivot3 is doing some interesting things area with its vBank, then there’s also Xiotech’s hybrid solution, the list just goes on and on.

With all of these competitors using similar or identical technology, why choose V3? True, it is really cool to see their demos of a slickly-packaged, VDI specific appliance out-performing the fastest traditional desktops. And their marketing seems to cut through the crowd, essentially saying, “Look, we can actually, finally do this VDI thing now, with a cool, sexy appliance built from scratch!” But it remains that there are many other products out there can do the exact same thing.

So will a small, highly-targeted company have the advantage in a crowded field? Or will more established companies or different technologies edge them out?

Do SIDs matter anymore? Do we really need Sysprep for VDI?

Rick Mack — Wed, 13 Apr 2011 19:21:00 GMT

I had another reminder today that SIDs *do* matter in a virtual Windows environment!

We used to religiously change SIDs with a variety of third-party tools (e.g. Ghostwalker, newSID, etc.), but between Mark Russinovich stating that SID changes were no longer necessary and the speed advantages of various “Quick prep” tools which I’ll define below, everyone kind of forgot why we bothered changing machine SIDs.

I’d like to start by talking about what happened to me today, and then expand a bit about the scenarios where SIDs matter very much indeed.

Never Clone a Domain Controller without Sysprep

I was working in a new sandboxed lab environment, where I had cloned an existing server, changed the server ID and IP address, and started building servers. The first server cloned became a domain controller, the next a management server, the third a file/print server. Logging on as the local or domain administrator, everything worked fine.

But when another domain administrator account logged on to the management or file/print server, things were decidedly odd. Stuff like trying to ping the DC failed with an “Unable to contact IP driver. General failure” error. A lot of network stuff just failed and yet you could do an nslookup. It turned out to be a SID issue which was resolved by changing the machine SID (management and file/print) with sysprep. There’s a lesson here somewhere because if I’d sysprep’d the DC beforehand I wouldn’t have noticed.

So why did this happen and why don’t we see this problem normally?

When you dcpromo a machine to turn it into a domain controller, the first DC uses the machine SID as the domain SID, whereas subsequent DCs pick up the same SID as the first DC. In the good old days you could create a remote DC by using newSID (Sysinternals) to change a machine SID to match the SID of an existing domain controller. In this case, all the clones had the same SID so the domain SID and the local machine SIDs were identical.

A user SID consists of two parts, a domain/machine part and then a user number or more correctly relative ID (RID), for example S-1-5-21-636461855-2365528612-2953867313-67402, where S-1-5-21-636461855-2365528612-2953867313 is the domain SID (or machine SID if logged on as local user) and 67402 is the RID. It’s important to stress that this is normally a unique identifier for that user.

Well as you’ve probably figured out, this is not quite true, because we have a special case here. The administrator account always has a user id of 500, so in our sandbox lab, both the domain administrator and local administrator account on all the machines had the same SID. Where it gets more interesting is when a domain admin (not administrator) logs on to one of these clones, because the domain SID is the same as the machine SID. So the operating system thinks this is a local user, but the RID isn’t in the local SAM database and gets very confused and peculiar things start happening. Run sysprep and things work as they should.

Cloned “Quick prep’d” Virtual Desktops and Local Administrator Security

Desktop virtualization (VDI specifically) is another scenario where having identical SIDs can potentially be a problem. There are a number of technologies, which I’ll call quick_prep as a generic term because a whole lot of other word combinations are proprietary. In the virtual machine (VM) provisioning context, quick_prep is a way of cloning or creating new virtual machines (VMs) quickly without running sysprep. Quick_prep generally involves cloning an existing image that is domain joined, changing the machine ID and hostname of the target VM and re-joining the target VM to a domain using pre-created domain machine accounts.

Early versions of Windows had issues with identical SIDs and security equivalence between machines, but I didn’t think this would still be true for Windows 7. After all, both Mark Russinovich and Pete Downing (Citrix and formerly Ardence) suggested it wasn’t a problem from a security viewpoint. Both VMware View and Citrix XenDesktop (Provisioning Services) offer “quick_prep” methods and while the technology is a bit different, the end result is the same. So, armed with this knowledge, and despite the errors above that I got from cloning a Domain Controller, I thought we would still be on safe ground when cloning Windows 7 virtual desktops with quick_prep.

I should point out that today in Quest vWorkspace we use Microsoft sysprep, because it’s the only method officially supported by Microsoft. (Note that even sysprep has a restricted list of supported configurations.)

I’m going to present an example, which happens to be XenDesktop because it was handy, but any quick_prep technology is likely to give you the same result. The screen shot below is from a newly-provisioned Citrix XenDesktop 5.0 Windows 7 VM. Both machines are domain members but the logged-in user is the local (not domain) administrator (xdwin7-008\administrator).

Note that I was able to open the c$ share on another newly cloned XenDesktop 5 Windows 7 VM for read/write access without authentication! This isn’t supposed to happen! Windows 7 is a lot more secure?

While I had assumed that additional user credentials would be required, they weren’t. What we see here is user equivalence between two VMs having the same SID, because both users have the same name, SID+RID and password. If I change the local administrator’s password, log out and back in again I need credentials to get to the other VM’s C$ share.

That isn’t so bad because even if you have local administrator rights and can change the common admin account password, that doesn’t give you open access to other VM’s. But how easy is it to find the local admin password?

Most of the password cracks for Windows 7 depend on accessing the Windows 7 system disk after booting to a linux CD with SAM cracking tools. That’s not going to work in this scenario, but if you could get a copy of the security account manager (SAM) hive to crack offline, then it wouldn’t be that hard.

There’s an old NT 4 resource kit tool called regback that used to do a nice job of backing up and restoring registry hives. It turns out that regback still works with Windows 7, provided you have administrator rights.

Once you’ve got a copy of the SAM, it’s just a matter of using a password cracking tool to crack the NT hash.

That gives you the credentials to get network access (via default C$ and admin$ shares) to any other quick_prep’d VM made from the same template. Sounds bad, but when you considered that any provisioning technology, sysprep included, generally has a common local administrator account, quick_preped machines are from this viewpoint no more or less secure. Except for one area that is sufficiently important that it has to be highlighted. Anything running in the local administrator context has unsecured access to any other VM made from the same parent. That has some really interesting ramifications when it comes to a virus/worm that infects one VM and then has full access to all the other VMs because of the security equivalence. If that happens I hope you’ve got a good antivirus!

SCCM and KMS

Of course sysprep does a lot more than just change a machine’s SID, it also changes the CMID (client machine ID) which is used by KMS for licensing, and so tracking the number of Microsoft licenses in use might get a whole lot harder too. (See http://support.microsoft.com/kb/929829)

The last, rather broader SID-related issue comes about because a number of machine management products use the local machine SID or a derivative as an identifier in their inventories. Even Microsoft has SID dependencies.

If we look at SCCM it doesn’t look like a good an example because it uses a non-SID identifier, an SMS GUID. Provided the SCCM client is installed after cloning, you don’t have a problem. If you’re unfortunate enough to have the SCCM client already installed on the VM before you converted it to a template, you will have a major house-keeping problem resolving duplicate GUIDS.

Of course, there is a mechanism to change the SMS GUID if any of the following parameters change:

The SMBIOS serial number (no change in quickprep)
The machine SID (no change in quickprep)
The hardware ID (see below)

The HardwareID may change if any 3 of the parameters below are changed:

FirstdriveSerial (no change in quickprep)
MAC Address (yes – will change)
CDROM device (no change in quickprep)
DisplayAdapter (no change in quickprep)
HWIDVersion (no change in quickprep)
ProcessorSerial (not sure here)
DiskDevice (no change in quickprep)
SCSIAdapter (no change in quickprep)
DiskAdapter (no change in quickprep)
ProcessorType (no change in quickprep, in homogeneous cluster)
RAMSizeMB (no change in quickprep)

Since we’ve only got 1 or 2 changes it’s probable that the HardwareID won’t change so our VM will have the same SMS GUID as the parent template. So unless you’re careful, quickprep and SCCM aren’t a good pairing if you want to manage your persistent VMs.

Conclusion

So, do SIDs matter? I guess it depends. In a scenario of non-persistent VMs where you can blow away and re-provision the whole fleet if there’s a problem, where you don’t let users have local administrator rights, the answer is a slightly qualified “no”. If you’ve got persistent VMs, let users have local administrator rights and intend to use something to manage the VMs, quick_prep may not be a very good idea and you may need to stick with the full “sysprep”.

Reverse Seamless & RES VDX: Separating facts from fiction

Max Ranzau — Wed, 09 Mar 2011 05:00:00 GMT

[Note from Brian: We've had an interesting conversation the past few days on BrianMadden.com and SearchVirtualDesktop.com about RES Software's Reverse Seamless product. I first wrote "RES Software launches standalone reverse seamless VDI tool" where I generally praised the product's awesomeness. Then earlier this week we published a blog post from AppDetective called "Why reverse seamless is not as cool as Brian thinks it is." After dozens of comments it's become clear that this is a hot topic, so I thought it made sense for RES themselves to join the conversation. And that's what today's post is. (But don't worry. This is it! I promise no more posts on this topic for awhile. :)]

Let me first start this article off by providing some context. My name is Max Ranzau, and yes, I do work for RES Software. However, I've been running my own independent blog (as in "not RES sponsored") for well over two years, giving me a certain level of impartiality. I work with the RES technology, and that's it. In the last decade I've made my living doing just that, even for seven years prior to joining the company in 2007.

I’ll cite and paraphrase P.T. Barnum's; "there's no such thing as bad publicity." I'm not sure my esteemed colleagues in marketing would agree, which is exactly why I'm not in marketing :) However, it's blatantly obvious that some have an axe to grind with RES for having the audacity to file for a patent on something that was invented and put into production years ago and then actually sell this patented product to customer who will benefit from the solution. Hence, there is a need for clarifying a few misconceptions and dispelling the associated myths. I’d like to thank Brian for providing us with the opportunity to do so.

So, let's set the record straight:

Myth: VDX is not secure!

What is there to secure? The remote session is completely and utterly separated from the local session. If you're worried about sending certain MIME types or file extensions over the wire, then just switch them off. It's all fully configurable via the server side component (called the "VDX Engine"). See the guide here for details.

Second, if the local windows endpoint is a security concern, there are solutions available to solve that issue, (like RES Workspace Manager and several others).

Third, sending information over the wire is not a security concern because we use the virtual channels inside the carrier protocol (HDX or RDP). Both can be encrypted. Additional encryption can also be added on top--VDX doesn't really care. While security folks can be perceived as the party-poopers of the industry, their jobs are usually justified. It's those few individuals among them who cry wolf in a misguided quest for job security that we need to worry about.

Myth: VDX is not cool!

Actually, it's very cool. At least that's what our thousands of customers tell us. Especially with the Z-order stuff enabling a local app to be able to be sandwiched in-between a remote desktop and a remote application. This makes the blendign very convincing for the user. (For more info about how VDX actually works, see this article on my blog.) There is a definitely a need for it and we're seeing them hotcakes sell quite well already!

Myth: VDX does not use virtual channels!

Yes it does. Period.

Myth: Danger! Danger! Third party!

It almost sounds like this is supposed to be a bad thing. Yet on a Windows platform, everybody except Microsoft is a third party — Citrix, VMware and RES included. Take the Wikipedia definition for reference: "In computer programming, a third-party software component is a reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform." So yes, per definition RES VDX is indeed a third party application, but can we please dispense with the negative implication? It’s like complaining that water is wet.

Myth: RES Software is a small vendor: It's risky!

Everybody has an unpleasant vendor experience sooner or later, but let's try not to judge a book by its cover--or the number of pages for that matter. RES Software has been around for over twelve years, and if I've got anything to do with it, we'll be here for at least another twelve. The numbers are solid, the technologies are sound (we happen to have multiple other products in addition to VDX) and we are continuing to form strong alliances with the major players in the market. Also remember that all the big guys were also once the size of RES Software.

Myth: VDX may not support Aero!

[Max: Post publishing--I had to do a slight redaction here] VDX is Aero aware. However it's not currently possible to bring the "glass-effect" into a remote session. What happens is that the VDX Plugin component on the client side disables the Aeroglass effect locally while the remote session is in effect, and then re-enables it when the session ends. Just for the record VDX also works fine with x64 systems.

Myth: VDX should be free!

No it shouldn't. At least not yet. RES has never registered this or any other patent just to sit on it and milk it for cash. Our major revenue streams comes from selling RES Workspace Manager and RES Automation Manager. In regards to reverse seamless windows, RES Software has provided value to customers for the last eight years starting with the Subscriber and the Workspace Extender agents. These were baked into our own Workspace Manager product (formerly known as PowerFuse) for years. (See this article for the development history.)

Now since RES released VDX as a stand-alone product, if someone feels it should all of a sudden be a part of someone else’s protocol, feel free to encourage that vendor to talk to RES about this. I'm sure the "powers that be" are busy sorting it out one way or the other. That's above my pay grade to discuss anyway. Either way, until whatever happens, RES Software will exercise its right to develop, patent and sell great technology like any other vendor on the market. And, ultimately, that’s a benefit for our customer base.

Thank you for your attention

Max Ranzau (@resguru)

A closer look at the new "Dynamic Memory" feature of Hyper-V: is it worth it for VDI?

Michel Roth — Thu, 27 Jan 2011 05:27:00 GMT

Microsoft Windows Server 2008 R2 Service Pack 1 will introduce two major new features: RemoteFX and Dynamic Memory. I've written about RemoteFX before (as has Brian), so today's focus is Dynamic Memory (from the VDI perspective). We'll also look at the inevitable question of how it compares to the memory management technologies in VMware ESX.

What is Dynamic Memory?

Dynamic Memory is a new feature of Microsoft Windows Server 2008 R2 Service Pack 1, or more specifically Hyper-V in Microsoft Windows Server 2008 R2 SP1. It lets you to take all of the memory in that Hyper-V host and dynamically distribute it across all of the VMs. (Hence the name "Dynamic Memory" -- possibly the first time a Microsoft feature name actually makes sense!) Dynamic Memory changes the way Hyper-V manages memory and makes it closer to the way CPU resources are managed, namely, shared across all VMs on the host. While I wish Dynamic Memory was as exactly as "dynamic" as CPU, we aren't quite there yet. In reality, the Dynamic Memory feature basically automates hot adding and removal of memory to a guest VM. (Super virtualization geeks might remember that the hot adding of memory in Hyper-V was actually planned for the first release back in 2007 but never made it.)

How does Hyper-V Dynamic Memory work?

The best non-technical way describe how Dynamic Memory works is to say that Hyper-V will give the guest VMs the right amount of RAM based on their actual usage. Of course there's a little bit more to it than that. Dynamic Memory works with the ‘driver enlightened’ architecture of Hyper-V. On the Hyper-v host, the Virtual Service Provider (VSP) manages the allocation of physical memory resources between the various virtual machines running on the host. Inside the enlightened guest, the Virtual Service Consumer (VSC) collects the information to determine virtual machine’s memory needs and executes necessary operations to add or remove memory.

Sounds cool right? Just "enable" it and be done? Unfortunately like I said, we're not quite there yet. You still need to configure some other parameters. Take a look at this screenshot:

Specifically, there are these 4 Dynamic Memory parameters:

Startup RAM is the amount of RAM that Hyper-V will always give the host. Microsoft recommends that this is set to the minimum RAM system requirements of the guest OS.
Maximum RAM is the upper limit of how much RAM the guest can grow to. This defaults to, and has a max value of, 64GB
Memory buffer is slightly more complicated. It's the amount of extra memory that's reserved for the guest in addition to the committed memory that the guest VM is asking of Hyper-V. Think of it like the desired "extra" memory for that guest.
Memory weight allows you to specify the importance of a VM in actual RAM allocation. The higher the memory weight, the higher the likelihood that VM will indeed get that memory. Memory weight will only kick in when the host is almost out of RAM.

Is Hyper-V Dynamic Memory any good for VDI?

Definitely! I love it.

I'll qualify by saying that I'm a ‘desktop virtualization guy,’ not a ‘server virtualization guy.’ (In this case that's a very good thing.) Let me explain: Desktop virtualization was hard enough when it was just Terminal Server, and the addition of VDI meant that things haven’t got any easier. If anything, it's made desktop virtualization harder. My personal opinion that VDI should be a lot easier and there are many steps that can be taken to achieve that, and making sure you use the RAM on your host as efficiently as possible is a great example of that which the Dynamic Memory feature gives you.

But while Dynamic Memory simplifies memory assignments, it creates new questions to answer like What should the memory buffer be? or How important is this VM? which are not that simple to answer. This is the part where it's great to be a ‘desktop virtualization guy’ because for VDI you shouldn’t care! :) There should be no reason why you'd need to change the memory buffer or the memory weight in a VDI environment. You can even keep the Maximum RAM left at its default (64GB) in most cases. So knowing that, Dynamic Memory comes really close to fulfilling the goal of memory being a completely shared and transparent resource like CPU.

That said, it may be worth experimenting with various Dynamic Memory configurations for your VDI environment. For example, you could provide Windows 7 virtual desktops with the minimum required memory (or even less!) to really put Dynamic Memory to work. You can also consider setting the ‘Maximum RAM’ to a lower limit: 2GB for example. This could possibly improve VM density since it limits the impact of VMs that eat up heaps of memory (for either good or bad reasons). Either way, make sure you watch the “Available Memory” performance counter in “Hyper-V Dynamic Memory Balancer” on the R2 SP1 Hyper-V host to make sure that you don’t overcommit memory on your host or else performance will plummet when you start paging too much. Some paging can be okay and safe (because the kernel is never paged out), but too much paging will definitely kill performance. Making the most of Dynamic Memory can really be worth your while. In fact Microsoft has seen improvements of up to 40% (!) in density for VDI workloads.

So it's all good?

It is for the most part. Without going into extreme detail on how Hyper-V assigns memory, it's important to know that Hyper-V talks to the guest OS to find out how much memory it actually needs and then allocates it as needed. Just be aware that if you run apps in your guest that query the OS for the amount of memory available on launch or use product installers that check the amount of memory before the install starts, these might cause a problem because sometimes they won’t continue when they ‘determine’ there's too little RAM available.

The reason for this is that Hyper-V allocates the extra memory when it's actually being requested by the OS, not when some random application queries from within the guest for the available memory. So if you do run into that situation, you'll need to set the minimum memory parameters of the guest to match the memory requirements of the product installer. In practicality this shouldn't be a big deal biggie because you'll probably use a ‘golden image’ of sorts so that install will be a one-time thing anyway. The problem becomes larger when an application queries for a certain amount of memory at launch and fails to start correctly if it doesn't find what it's expecting. The only option you have in that case is to set the minimum memory parameters of the guest to match the memory requirements of that application (but at the expense of limiting the efficiency of Dynamic Memory).

Finally you might also run into some weirdness with apps that do their own memory management. Some apps will grab all the memory they can in order to get the best performance. While this might be fine on a single-use PC, it's not such a good idea on a Dynamic Memory-enabled guest. The best option for these scenarios is to lower the Maximum memory for that VM, but again, this limits the efficiency of Dynamic Memory.

And of course, the fine print leads to one big caveat

It's important to know that in order to use Dynamic Memory, you need to upgrade not just Hyper-V (to 2008 R2 SP1), but also the in-guest ‘integration components’ (which are what allow the guest OS to be able to use the Dynamic Memory feature.) Unfortunately Dynamic Memory will only work on these guest operating systems:

Windows Server 2008 R2
Windows Server 2008 (SP2)
Windows Server 2003 R2
Windows Server 2003 (SP2)
Windows 7 (Enterprise and Ultimate only)
Windows Vista (Enterprise and Ultimate only)

That’s right. No Windows XP! And only the Enterprise and Ultimate Editions of Windows 7! (Although it really isn't that bad because you need the Enterprise or Ultimate Edition of Windows 7 to be able to do VDI anyway.)

Doesn't VMware ESX have this as well?

Yes and no.

VMware ESX has memory management techniques of its own (and has had most of them for a long time now). The most important techniques (great doc here) are Idle Memory Tax (IMT), Second Level Paging (Hypervisor swapping) and Memory Compression (new in ESX 4.1). Instead of scrutinizing all the different technologies VMware uses and how these compare to Dynamic Memory, let’s have a look at the goal of both Microsoft and VMware with their techniques.

Both companies have the goal to maximize the RAM usage on the host which is exactly what's needed for VDI. The most important difference between VMware's and Microsoft's approach in my mind is that Dynamic Memory allocates memory on demand (in ‘real-time’) whereas VMware’s memory management techniques pre-allocate memory and then uses several memory management techniques to reclaim unused memory. With VMware it's also easier to oversubscribe the physical memory of the host (note how I didn't use the word overcommit!) and I think that's a risk in most current VDI deployments. No matter how you slice it or dice it, when RAM is oversubscribed it introduces a higher probability of paging. This in return means a huge increase in IOPS. I guess it should go without saying that this is something you should avoid at all costs in VDI environments.

So should I move my VDI environment to Hyper-V now?

It’s interesting to see how the same questions keep popping up. In the past, every time a new version of Terminal Server came out, people would ask Do I still need Citrix? This question about Hyper-V feels the same and the answer is also the same: it depends. It depends on what you need out of your hypervisor. From the VDI perspective you should want to maximize the usage of the RAM on your host to its guests in the most flexible and efficient way. That’s exactly what Hyper-V 2008 R2 SP1 gives you. But of course it's also in ESX today. I don’t think Dynamic Memory will be the reason for people to abandon ESX en masse. I do think that, looking at memory management from a VDI perspective, Hyper-V fits the bill just as well as ESX does, if not better.

An introduction to VMware View 3, Part 3 of 3 – Special Considerations and Best Practices

Roland van der Kruk — Mon, 26 Jan 2009 19:01:00 GMT

In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 provides information and insight on new features, Part 2 looks at Linked Clones, and Part 3 (this article) will look at special considerations and best practices for deployment.

High available, secure remote access

Unfortunately, a high available configuration to access VMware View while being outside the corporate network can be very different between organizations. I have been doing some research reading the VMware VDM 2 Load Balancing Guide to find out more about load balancing and secure remote access. In today’s enterprise environments, gateway devices like Citrix Netscaler/Access Gateway or Cisco ASA are more or less common practice. They are configured as a mandatory termination point for sessions originating from outside the corporate network connecting to resources inside the corporate network.

Initially, two http sessions are set up between the client and the Connection Servers to which the load balancer redirected the client request. One session is for communication with the web page, the View Portal, and one is for the RDP connection that can be configured to be packed into http or https. By default, a Connection Server replies to the client http request with a response in which its own hostname is sent back to the client. Using the default configuration of a Connection Server would then result in having to open up the necessary ports on the firewalls between the Gateway device and all Connection servers as the client will try to communicate directly with the Connection Server once it received the Connection Servers’ hostname in the http response. In the configuration page of the View Administrator however, you can modify the default behavior by configuring an ‘External URL’ that will be given back to the client. The External URL will have to be configured on each Connection Server that you have.

Picture 16 – Part of the screen that appears when clicking a Connection Server and choosing ‘Edit’.

An External URL can be configured and also a direct connection to desktops, resulting in bypassing the Connection Server for direct communication with the virtual machine that a user needs. If you configure the External URL to be the DNS name of the load balancer, you will have two moments on which load balancing will take place; initially to set up the communication to the View Portal, and subsequently, if a session to a Virtual Machine is started.

According to VMware in the Load Balancing Guide, for proper load balancing to work the load balancer needs to be configured for SSL Offloading. SSL Offloading is necessary because a load balancer cannot see what’s inside an SSL request. All requests are coming from one Gateway device, which means that all the load would go to the initially chosen Connection Server. Also, sticky sessions need to be configured on the load balancer to support RDP connections over http. This means that SSL connections can be setup to the load balancer, but the load balancer will strip off the encryption and forward the requests to the Connection Servers as http. This actually means that communication from the load balancer to a Connection Server is going over HTTP where, for example, a cookie insert by the load balancing device will result in being able to provide RDP sessions consistently going to the same Connection Server

This also means two more things:
Username and password are passed to the Connection Server in clear text between the load balancing device and the Connection Server.

As the Connection Server is configured for http and not https, the RDP sessions will be packed in http as well. This might not be a problem because the connection from the internet to the Gateway device is already tunneled in https, but I wanted to point that out anyway.

Compared with Citrix Web Interface, where integrated logon with Kerberos authentication is an option, this seems like an issue that VMware could address better. Also to get a Cisco ASA to work, probably a View Plugin for ASA would be a GREAT idea...

Server Provisioning

When I made the comparison of View 3.0 with Citrix Provisioning Server, I wondered how View 3.0 could be used to deploy Terminal Servers or even Citrix Servers. The official line from VMware says that only Desktop Operating Systems are supported. I tried it for myself and, indeed, a Virtual Server with a snapshot and a View Agent installed is not ‘discovered’ in a desktop pool deployment wizard. Too bad, because a tool for cloning Citrix servers, like the one from CitrixTools.net could do a good job here, handling all Citrix specific services and settings with Sysprep being used by Virtual Center to deploy uniquely identifiably virtual machines. Active Directory policies could be adjusted to make all this work without further administrative interaction.

Maybe I’m going too far here comparing View with XenDesktop/Provisioning Server? I see a lot of similarity between the two products, even though entirely different techniques are used. I might say that putting OS changes in a ‘memory state cache’ as Provisioning Server does is a more elegant solution than creating and deleting snapshots, but the result can be the same; Instantly provisioned machines that are deleted as soon as they reboot.

Machine Account password

A virtual machine with a snapshot can only be used by View 3.0 (or probably VMware ESX) as a master image if the machine is joined to a domain. For this reason, I would apply the same local policy as I would normally do with a sequencing or packaging machine, and then disable Windows machine account password resets. If your company policy or personal preference requires machine account password changes, you can change the default ‘change password interval’ to the maximum of 999 days. Both of these options can be changed in the Group Policy editor:

Start/run/gpedit.msc >

Computer configuration/Windows settings/Security settings/local policies/Security options:

- Domain member: Disable machine account password changes - enabled

- Domain member: Maximum machine account password age – 999 days

Display Protocol

I have to mention that I was at least a little disappointed when I noticed that nothing was done about optimizing RDP. It is especially important if you plan to deploy Windows XP, which probably has the worst version of RDP still available, and you have to provide desktops to users over high latency connections. I must admit that I haven’t yet tested performance using RDP with a typical Indian latency of (so the story goes) up to 300 milliseconds, but I can image implementations being cancelled because of this shortcoming. The Group Policy Administrative Templates provided with View will really be necessary to optimize RDP as far as possible, but of course the advanced options available in ICA are really an entirely different story.

In the Reference Architecture Kit on the VMware site, VMware actually acknowledges this problem by stating that RDP is a good protocol for LAN connections or WAN connections with up to 150 ms latency. If you have to provide virtual desktops over high latency connections however, using RDP might not be a good idea. VMware mentions solutions like Sun Microsystems’ Appliance Link Protocol™ (ALP) used in Sun Ray™ thin client implementations and Pano Logic’s Console Direct, but getting into those is out of the scope of this document. I did find a network tool that can configure latency up to 400 ms, so I will test this in the near future.

Sizing

Also in the Reference Architecture Kit, a setup is described for separate ESX clusters for VDI. For my customer, I will also use separate ESX clusters. Although, since clusters cannot contain more than 8 nodes, my customer will have to change from their standard cluster configuration of 13 hosts per cluster. I found that approximately 17 power users can be placed on a machine with two quad core CPU’s and 24 Gb of memory. Because of the memory sharing feature, ESX even promises to be the best option on which to run VDI environments, as other hypervisors do not support memory sharing. I plan to use the same Virtual Center that I already have running for my server environment, which already is one of the largest in Europe. However I will probably have to keep a close eye on performance, as Virtual Center probably also has its limits.

User experience monitoring

When you are planning to use VMware View, I recommend looking at ‘User Experience Monitoring’ products. Products from eG Innovations and RTO PinPoint can provide valuable information on both frond end and back end performance, giving you great insight in what delay is caused where. Implementing that could save you a lot of time in the end.

A final word or two…

VMware did a good job with View 3.0. They put all configuration options for the View 3.0 product into one console, which is really excellent work. The console is intuitive and fast. Options are logically grouped and put into only four distinct console windows. The new linked clone technology is probably a bit harder to understand as consequences for disk space usage are not properly documented by VMware. (Linked clones were covered in Part 2 of this article series)

The term ‘persistent desktop’ needs some explanation because it can be misunderstood as a desktop for power users – like a dedicated desktop. In actuality, it means that all the desktops are kept in a consistent state by the administrator, which is certainly not a “power user” type desktop.

Furthermore, most essential options are available; universal printing, single sign-on, instant and automatic desktop creation, even the experimental ´offline desktop feature´ can be used. Unfortunately, optimizations on the RDP protocol are lacking, which in some cases might result in unworkable situations because of network latency. Customers using VMware ESX could strategically choose for View 3.0 because of the tight integration with Virtual Infrastructure. With the Premier license bundles that also includes ThinApp/Thinstall, the combination makes for a promising offering in the VDI market. I wonder what VMware´s next move will be.

Useful links

VMware VDM 2 Load Balancing Guide

Administration Guide - View Manager 3.0

VMware View Reference Architecture Kit

Part One of this article series

Part Two of this article series

Roland van der Kruk is a freelance consultant in The Netherlands. He currently works with server-based computing and desktop delivery solutions. Roland can be contacted by email at roland@sbcprojects.com or through his website at http://www.sbcprojects.com.

An introduction to VMware View 3, Part 2 of 3 – Linked Clones

Roland van der Kruk — Sun, 18 Jan 2009 13:56:00 GMT

In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 provides information and insight on new features, Part 2 (this article) looks at Linked Clones, and Part 3 (released later this week) will look at special considerations and best practices for deployment.

Linked Clones

The big question to most people is probably: ‘What are linked clones and how do they work?’. Some of you may expect similar functionality to Citrix Provisioning Server where optimization in disk space can be significantly realized, and indeed VMware does somewhat the same, but with very different technology. Let’s see how VMware does it.

The essence of linked clones is Thin Provisioning; saving on expensive storage cost. Thin provisioning with View 3.0 can be realized using a “master virtual machine”, which is just a regular virtual machine that you create and then take a snapshot. That virtual machine will be used as the basis for rapid and thin OS deployment. Please notice that I mentioned a virtual machine “snapshot”, not a virtual machine “template”.

You prepare a virtual machine with the Desktop OS of your choice (Server Operating Systems are not supported) exactly the way that you like your master image to be. When all components and settings are properly set, you then have to install the VMware View Agent (which contains the components mentioned in the previous article), shut down the virtual machine and take a (first) snapshot. I might add that the master virtual machine has to be domain joined, for which I could not find the reason. After that, desktop deployment can start.

In the View Administrator console, choose the ‘Desktops and Pools’, as this is where desktops and desktop pools can be added and/or edited. In the right pane of the ‘Desktops and Pools’ tab, five other tabs appear, the most left being the ‘Desktops and Pools’ view. Here you can choose ‘Add’ to start a wizard that guides you through the steps necessary for adding a desktop or a desktop pool. The following choices are presented:

Individual Desktop, this option will start a wizard to provide users with access to a single virtual or physical computer on which the View Agent is installed.
Automated Desktop Pool, this option starts a wizard to automatically create one or more desktops in a pool. The explanatory text for this option states that desktops are based on “virtual machine templates,” which is wrong. You need to have a normal virtual machine from which you will take a snapshot (as mentioned above).
Manual Desktop Pool, this option will start a wizard to provide access to an existing set of virtual or physical PC’s that have the View Agent installed.
Microsoft Terminal Services Desktop Pool, this option starts a wizard to publish Terminal Server desktops to View Portal users.

I don’t want to get into details with every option mentioned, but continue with the most eye catching option, the Automated Desktop Pool. The automated desktop pool can consist of any number of persistent or non-persistent desktops.

After a persistent desktop pool is created and a user is assigned a certain desktop, the mapping between user and assigned desktop is written to the ADAM database (see Part 1 for more information on how ADAM is used). Every time the user logs on to the View Portal, the same desktop will be available and the state of the virtual machine is exactly the way he or she left it with the previous logoff. This option is similar to the ‘permanent disk’ in Citrix Provisioning Server. A persistent desktop pool can contain any number of desktops, and once created, the pool can also be edited to increase the number of desktops in the pool. In the wizard, as depicted below, the initial number of desktops to be created is set to 5, the total number of desktops in the pool is set to 100 and as soon as the number of available desktops falls below 5, the number of available desktops is matched to meet the configured criteria by creating more machines in the pool, until the maximum number of desktops in the pool is reached.

Picture 6 – Advanced configuration of the number of desktops in a pool in the Deployment Wizard

Both persistent and non persistent desktops can be created using the ‘linked clone’ technology, which in fact means that deployed desktops can be altered by assigning the desktops to a different snapshot or even to an entirely different virtual machine. The main difference between a persistent and a non persistent desktop is that persistent desktops can contain a second virtual disk to which the ‘Documents and settings’ folder is moved. User data is effectively put on another disk, so in case an administrator decides to assign a different snapshot or image to a user, all user data in the ‘Documents and Settings’ folder will still be available. Of course, this can also be accomplished by modifying the User Shell Folders of each user with Active Directory GPO or script to alter all default folders, but with the View 3.0 option, user data will be locally available, presumably resulting in better performance.

I wonder if this is really a useful option, as user data can only be reached by going to the machine itself and opening the folder, whereas with folder redirection, all user data can be redirected to a central network share, substantially simplifying central administration, in my opinion. If the central network share is located on fast NAS heads, performance might still decrease a little, but management of user data only locally available on virtual machines is not a very attractive option in larger environments.

Picture 7 – A separate disk for personal data, available in a linked clone.

What actually happens as the wizard is finished is that a copy of the master virtual machine is made, together with a copy of the snapshot. The size of the copies, however, is not a complete copy of the master virtual machine. I deployed a master image with a system drive of 20 GB with a snapshot, which resulted in a copy of 6 GB for the system drive and a few Kb for the snapshot.

Picture 8 - User data drive of a persistent desktop for a specific user.

The folders and disks are automatically created and the folders and files contain some GUID that is associated with master desktop and user.

To (hopefully) clarify the components, the following Virtual Center folder arrangement is depicted:

.jpg">

Picture 9 - Virtual Center containing all folders necessary for a View 3.0 deployment.

The above picture shows that

VMware virtual machine templates can be used to deploy master images
Master images with at least one snapshot are best placed in a separate folder to make sure you don’t mix things up
Linked Clones are best placed in a separate folder, where subfolders can be created to place non persistent and persistent linked clones
You can (and probably will) have other virtual pc’s or virtual servers in your Virtual Center
On the bottom of Picture 9 the automatically generated folders are shown, which are all created by View 3.0 as a result of a desktop pool deployment wizard in the View Administrator console. A replica folder and a source folder are created for each desktop pool that uses linked clone technology. All folders created automatically are fully managed by View 3.0 and are only to be administered through the View Administrator console.

Linked Clone disk characteristics

So, how does View 3.0 handle disks and disk space for linked clones?

In my tests I created a Windows XP SP2 image with a system drive of 20 GB. In the Automated desktop pool wizard, I chose to configure 5 linked clones, where initially 1 linked clone was created immediately after finishing the wizard, and where always 1 desktop would be available for new user logon until the maximum number of desktops in the pool has been reached. Also I chose to create a separate User data disk of 2 GB for the ‘Documents and Settings’ folder to be placed.

Picture 10 - Step in deployment wizard where OS Data and User Data stores can be selected with.

After finishing the wizard, a replica folder and a source folder are created which are used as templates, of which clones are created by View 3.0

Picture 11 - Replica folder of an automated, persistent desktop pool, derived from a 20 GB system disk

Picture 12 - Source folder of an automated, persistent desktop pool with a configured user data disk of 2 GB

Picture 13 – System disk of a linked clone, available to an end user using a system disk of 20 GB

Picture 14 – User data disks, mapped as D-drive in the users’ virtual desktop, for two users with a maximum of 2 GB per user

In the table below, all components are mentioned to deploy at least one desktop pool based on one Desktop Operating System. The ‘linked clone system disk’ will initially be around 100 MB and can grow up to the original size of the Master VM. A Desktop Refresh (discussed below) can be scheduled or executed manually to return the linked clone system disks to its’ original size.

System disk of Desktop OS template, used to create ‘Master Image Virtual Machines’	20 Gb
System disk of a ‘Master Image Virtual Machine’, containing a Desktop OS including (a) snapshot(s)	20 Gb
Replica folder and source folder derived from the ´Master Image´, created for a desktop pool with an unlimited of linked clones	6 Gb
Linked clone system disk per OS	100 MB - ??
Linked clone user data disk per user	2048 MB (configurable)

Table 2 – Linked Clone disk size example

Desktop recompose, refresh, rebalance

At all times, deployed desktops can be altered when created using the linked clone technology.

A Desktop Recompose means that a deployed desktop state is altered. It can be assigned a different snapshot of possibly even entirely an different master virtual machine.

A Desktop Refresh means that a linked clone desktop is brought back to the state of initial roll out. This actually means that the system disk is reverted to the moment it was deployed, including its size and contents. If a separate user disk was used in the deployment wizard, all user data on that disk remains intact.

A Desktop Rebalance means balancing virtual machine disks across available data stores (LUN’s). If a VMware ESX data reaches its capacity, a rebalance can take care of automatic data migration of deployed virtual machine disks to different ESX data stores.

Picture 15 - View on a persistent desktop in the ‘Persistent’ desktop pool, which can be removed, reset (OS reset), edited (recomposed or refreshed) or rebalanced

Linked clones, persistent desktops and OS maintenance; 1 + 1 + 1 = 1?

Another thought came to mind worth mentioning. In my test I created a desktop pool with the combined technologies of linked clones and persistent desktops. Of course on these desktops, I do have to perform maintenance, as Microsoft hotfixes come out the second Tuesday of the month and who knows what else needs to be updated. Initially I thought I could use the linked clone technology for this; update my master virtual machine with hotfixes, take a new snapshot and link all deployed desktop to the new snapshot. If all is well this will work, however, what happens to my ‘persistent desktops’ if I do that? In fact, all users having made changes to the OS (I chose to allow certain users to install their own applications) lose their OS customizations and their applications.

After linking desktops to a new snapshot, it appears that the only thing that is really persistent about the ‘persistent desktop’ is what is on the user data disk, which contains the ‘documents and settings folder’ and maybe some data, but not the entire installed application the user needed. Ergo, if I want to maintain my OS with hotfixes using linked clone technology or ‘Desktop Recompose’, while at the same time keeping users’ customizations to the OS, I will have to use a tool like SMS/SCCM, Radia or whatever your standard corporate application distribution method is. My question then is: what does ‘Persistent Desktop’ really mean?

I performed one more test to see how intelligent the linked clone snapshotting technology really is when it comes to managing disk space. I started off with a Persistent Desktop:

- System disk: 230 MB

After I logged on as an administrative user, I copied an installation of Eclipse, sized 354 MB, to the System disk of my virtual machine.After the file copy, my System disk looked like this:

- System disk: 607 MB

I decided to delete the Eclipse folder. After deletion, the system disk looked like this:

- System disk: 607 MB

Conclusion: The Eclipse folder doesn’t seem to be deleted and the data is still available in the snapshot.

I decided to copy the exact same Eclipse folder again to the same destination on the system disk, which then looked like this (I also tested another destination; c:\temp, which had the same result):

- System disk: 623 MB

Apparently, some check was done as the linked clone disk reused the data that was marked as ‘deleted’.

After I removed Eclipse again, the system disk looked like this:

- System disk: 640 MB

Now since Eclipse is deleted off disk and the system disk still has the size of 640 MB, which means the data is still there, maybe the snapshot technology is intelligent enough to mark the space as deleted so it can be filled up with other data. I copy some other data to the system disk that is smaller than the size of the data that could be ‘marked for deletion’. After copying a 219 MB folder, the disk looks like this:

- System disk: 852 MB

Conclusions:

Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.

An introduction to VMware View 3 features and best practices, Part 1 of 3

Roland van der Kruk — Thu, 15 Jan 2009 14:50:00 GMT

In this three-part article series, Roland van der Kruk, a freelance consultant in The Netherlands, takes a look at the new features of VMware View 3, as well as best practices learned while doing a deployment for a customer. Part 1 (this article) provides information and insight on new features, Part 2 looks at Linked Clones, and Part 3 will look at special considerations and best practices for deployment.

Introduction

Early December 2008, VMware released their new product for the VDI market, VMware View 3.0. As a rather substantial update to the former version, VMware VDM 2.0, apparently the product name also had to undergo a change to underline the differences between the new product and its predecessor. In this article I will discuss the (new) features in View 3.0 and the way they work. I will first describe the components on which the product is based. Then I will focus on the different deployment types possible with View 3.0 and what happens during and after deploying different types of ‘desktop pools’.

My experience with the new product is mainly based on an implementation that I did for a customer, who had a specific use case to provide desktop operating systems to developers around the globe. I will sometimes refer to other use cases as there are quite a few, however perhaps the biggest question that everyone probably has will remain unanswered, as the technology that makes up VDI is still developing. Where we can speak of an accepted and well known technology like Citrix XenApp, VDI is not nearly there yet. The question of how VDI will result in better return on investment than desktop deployment methods being used for many years now is not clear. It all depends on use cases and things like high availability requirements and hardware cost. Financial differences and justifications for using VDI or a traditional desktop model are not discussed in this article.

Let’s first start with a description that VMware uses to describe the product and take it from there.

VMware describes View 3.0 as follows:

‘The Next Generation of VDI, delivering rich, personalized desktops to any device with all benefits of centralized management’.

View 3.0 was created using different technologies that are found in other VMware products. Examples of technology used in View 3.0 include snapshotting as seen in VMware Workstation (see picture 1); VMware OS cloning as used in ESX; and Tomcat is used for the Web based administration console, which we have seen before in the free VMware Server product (including the “self-signed, untrusted certificates” ‘feature,’ which is enabled by default ;-).

Managing View 3.0 is fairly straightforward. It is quite easy to use once you are accustomed to the components and terminology used with this product. Troubleshooting might turn out different, so let’s hope this product is as stable as should be.

Picture 1 - Snapshotting in VMware Workstation

VMware View 3.0 only supports VMware Infrastructure and is not a hypervisor-independent product. In fact, due to the new technologies that were added to View 3.0, it also imposes some requirements to the Virtual Infrastructure you are using. Before installing the first bit of View 3.0, you should check the version you are running on. View 3.0 is supported starting with VMware Infrastructure 3.02, however VI 3.5 u3 is recommended since linked clones are supported, which is probably the part raising most questions but also promising the best use cases. Both ESX 3.5 as ESX 3.5i can be used for View 3.0.

Components and terminology

Although setting up View 3.0 in fact can be quite straightforward, at first I found it difficult to figure out which components were doing what, communicating where, and for what purpose. I will try to explain the product by naming and describing all of the important components and terms used in the product.

View Connection Server

A connection server is a server acting as desktop broker. It facilitates two web sites; one for users that want to access a virtual desktop and one for administrators managing the View 3.0 environment. The Connection Server communicates with Active directory and maps Active Directory users and groups to virtual desktops and desktop pools. This information, together with configuration data, is stored in a local LDAP database, for which VMware decided to use ADAM (Active Directory Application Mode). The ADAM database can be viewed through the locally installed ADAM AdsiEdit.

Although the choice for ADAM as a database seems a good choice, unfortunately this also causes confusion, as with ADAM, a second LDAP database is introduced next to Active Directory. Confusion can arise when looking at the log messages in the Event log of the View Administrator console, where sometimes errors point to the ADAM LDAP database, while the actual error might be caused in communication towards Active Directory or vice versa.

When the Connection Server software is installed, the ‘VMware View Connection Server’ service is added, running under ‘local system’.

View Replica Server

The installation package for the Connection Server also contains the installation source for the ‘View Replica Server’. A View Replica Server is a Connection Server with its own replica of the ADAM database stored locally. All configuration data and changes are instantaneously replicated to all replica servers, resulting in entirely independent Connection Servers, being able to act on their own in case of failure of other replica servers.

View Security Server

The installation package for the Connection Server also contains the installation source for a ‘View Security Server’. A View Security Server acts somewhat like a Citrix Secure Gateway Server (the free software version) and is typically placed in a DMZ. Installation is very straightforward and the only important thing to configure is a 1-on-1 connection to a View Connection Server. After having connected a Security Server to a Connection Server, all instances of all Connection Servers are added to the configuration of the Security Server, not introducing awkward availability situations where a Security Server is available but its attached Connection Server is not. No ADAM database is stored locally and in fact the Security Server only function is to tunnel communication from the outside world users to the internal Connection servers over SSL. By simply entering the hostname of the security server in a web browser, the View Portal page is displayed, which actually is the View Portal page of a connection server.

View Portal

View Portal is the web page that facilitates users in accessing their desktops and is run on the Connection Server. After pointing a web browser to https://connectionservername, a logon screen appears in which all domains are available that are trusted by the domain to which the Connection Server was added. View Portal is the default web page on each Connection Server and is secured with self-signed certificates out of the box. Unfortunately with View 3.0, access to the View Portal is still not possible from Windows Server 2003 R2 machines, as was the case with VDM 2. Surprisingly enough, it is possible to access virtual desktops from Windows Server 2003, but only with the View Client software installed.

View Administrator/View Manager

The console from which all View management can be done, like View configuration, desktop deployment, user session management and log event viewing has in fact two names; ‘View Administrator’ and ‘View Manager’, as can be seen when the web based console is started. To start managing View 3.0, point a web browser to https://servername.domain/admin. Make sure you read that correctly; it is NOT https://servername.domain/adm, a little something that could eat you up for awhile if you don’t pay attention ;-). View configuration is done from one console that contains all possible configuration settings; a relief if you are accustomed to the different consoles that Citrix offers with their VDI product :) (see picture 2). Licenses, the connection to the Virtual Center server(s) and the account to perform all necessary actions in Virtual Center, the accounts to use that have permissions to add computer accounts in Active Directory, smart card support, a current usage overview, session timeout settings, SSL communication to the broker, login messages and more, it can all be accomplished using this one console which is even conveniently arranged. Hurray for VMware!

Perhaps a disadvantage would be that no real delegation of control can be configured; either you are a View administrator or you are not. No room for user session management only, or permissions to only modify specific desktops or pools; one down for VMware…

The four tabs in the administration console are:

Desktops and Pools - An overview of all desktop pools and other resources like Terminal Severs or bare metal pc’s, which can also be offered to users if the View Agent is installed. If the tab for Desktops and Pools is selected, sub windows appear on which all active sessions, accessible desktops, offline desktops and desktop policies can be viewed and managed.
Users and Groups - An overview of desktop entitlements to Active Directory users and groups
Configuration – All configuration for View 3.0 can be done here as mentioned before
Events - All events about desktop pool creation, desktop refresh etc. Events can be searched and filtered on number of days through the always-good-to-know symbol that VMware uses to show that more options are available: the triangle ;-) which looks like this:

Picture 2 – VMware View Administrator, configuration tab

Picture 3 - An view on the ‘Desktops and Pools’ tab in the View Administrator console, showing two desktop pools; one non persistent, one persistent

View Composer

View composer is a separate piece of software that has to be installed on the Virtual Center server if you want to use linked clones. Prior to doing that, a database needs to be created for which I used an MS SQL 2005 database, but SQL Express is also supported. You might consider using a separate account for the View Composer to run under, however I used the Active Directory Service account that Virtual Center is running under and granted the account dbowner rights on the LinkedClones database.

While installing the View Composer software, the ‘VMware View Composer’ service is added as a Windows Service, however I could not finish the installation until I changed the logon credentials to run under the same account that ‘VMware Virtual Center Server’ service is running on. In the Administrators’ guide for View Manager 3.0, page 104 or in Table 1 below, you can see exactly which permissions are needed for View Composer to work.

Privilege	Group Privilege(s) to Enable
Folder	Create Folder
Data store	Browse Data store, File Management
Virtual Machine	Inventory Configuration State
	Provisioning > Clone
	Provisioning > Allow Disk Access
Resource	Assign Virtual Machine To Resource Pool
Global	Enable Methods, Disable Methods

Table 1 - View Composer Account – Minimal Privileges in Virtual Center

View Agent

View Agent is the component that you install inside the virtual machine that you want to use as a master VM. With the machine that you decide to make the ‘Master Virtual Machine’, you can deploy other virtual machines that are cloned from the Master VM. The VMware view agent consists of the following components:

Picture 4 – Custom setup window of the View agent which is installed on the master VM

· VDM Secure Authentication – This feature will install a piece of software that handles single sign-on. A user has to enter his credentials either on the View Portal or in the View Agent that is installed locally on his computer, and these credentials can be passed to the virtual desktop provided by View 3.0. This works in conjunction with the View Client, in which you can configure to use SSL for your communication or not.

· USB Redirection – This feature handles connections from the clients’ desktop USB devices to the virtual machine. I’ve already found out that HP USB keyboards with integrated smart card readers are not supported and requested an update for that particular device. There are probably more devices that are not yet supported, so make sure you test the devices that you might plan to use in your company’s View 3.0 future.

· VMware View Composer Agent – This feature needs to be installed if you plan to use linked clones, more on that in Part 2 of this article.

· Virtual Printing – This feature installs ThinPrint universal printing software. I found version 7.8.0.3 of the ThinPrint Output Gateway, dated 07/12/2007 and version 1.0.0.11 of the PostScript driver, which is more recent, dating from 6/18/2008. I concluded that with advanced multi-functional devices, not all options like stapling your papers are supported, in contrast to the Citrix Universal Printer driver, in which you can open the client devices’ local printer properties window and access all options available in the native client driver. However, most options like paper size, orientation and duplex printing are available with the Virtual Printing feature.

View Client

View client is the component that end users have to install on their own system. With this client, USB redirection and single sign-on are supported. The View client installation package is automatically pushed if users having logged on to View Portal do not have the Client installed. The installation is straightforward, but unfortunately not available as web plug-in, so administrative permissions are required for the end user to install it. The view agent looks a bit like the regular RDP client from Microsoft; you start the client, enter the connection server that you want to logon to and after successful authentication, available resources are displayed in the View Client (see picture 5).

Picture 5 – Logon screens of the View Client, which needs to be installed on the client pc of end users.

Part 2 will be released in the next few days and cover Linked Clones. Part 3, available early next week, will discuss VMware View 3 best practices.

How to Deploy the XenApp Web Plugin (ICA Web Client) v11 via Web Interface 4.6 and Web Interface 5.0

Katie Koepke — Mon, 10 Nov 2008 22:20:00 GMT

For those who would like a quick “Google-able” article on how to deploy the new XenApp Web Plugin (formerly known as the web client) this is the article for you.

To do this, you basically follow the instructions from CTX114097, “Deploying the Web Client 10.1 for Windows through Web Interface 4.6” but with a few modifications.

First, download the XenApp Web Plugin from Citrix.

For Web Interface 4.6

Rename XenAppWeb.msi to Ica32Web.msi.
Copy Ica32Web.msi to \Program Files\Citrix\Web Interface\4.6.0\Clients\ica32. (Create the ica32 directory if it does not exist.)
From a command prompt run iisreset.

For Web Interface 5.0:

Copy XenAppWeb.msi to \Program Files\Citrix\Web Interface\5.0.1\Clients\ica32.
(A rename of the file is not necessary.)From a command prompt run iisreset.

Automatic Deployment and Installation of the Web Client

Web Interface 4.5 was the last version of Web Interface where automatic deployment and installation of the web client was an option. This is due to increased browser security in Internet Explorer and Vista making this capability too difficult. That said, you can only configure "automatic detection" in versions 4.6 and 5.0 as described above, versus "automatic deployment."

You should run Web Interface 4.6 instead 4.5 but if you must know how to configure automatic deployment, refer Citrix's article "How to Deploy the ICA Web Client Through Web Interface 4.5."

*Special thanks to Bertine Luzincourt and Scott McDonald from Citrix for their help!

Vista Aero Glass for VDI: What's real today

Glenda Canfield — Sun, 24 Feb 2008 22:00:25 GMT

Recently at the Citrix Summit I collaborated with the Citrix Multimedia Virtualization Team to present a demo using XenDesktop / PortICA to deliver Vista Aero Glass from HP 2500 series blade PCs to HP's t5730 (XPe) / t5735 (Linux) thin clients. (PortICA is "port ICA," which is a Citrix implementation of the ICA protocol being served by a Vista workstation for VDI scenarios. The demo we presented was completely dependant on PortICA which requires XenDesktop. This is not officially supported by Citrix or HP at this time.)

I also participated in a panel discussion with two members of the Citrix's Multimedia Virtualization team: Derek Thorslund, Product Strategist, and Juan Rivera, Sr. Development Manager. We discussed Project Apollo as well as the various protocols and what the use case would be for each. If you attended Summit you should be able to download the video recording and slide deck from the session. (Session ID 806 - Multimedia Requirements for Desktop and Application Virtualization)

In this article, I would like to discuss a bit about how this demo worked and review some of the technical components required to deliver a Vista Aero Glass desktop to a remote client. Before I do this, let's review the two different protocols that I'll reference:

Citrix Project Apollo (PortICA, via the Thin Wire Virtual Channel): Project Apollo is currently pre-alpha, but my understanding is that the graphics travel inside the ICA Protocol over the Thin Wire virtual channel. Glass graphics are compressed on the backend (or the VDI instance, in this case of a blade PC or workstation blade) and then decompressed on the client side using a CODEC that will probably be embedded in the ICA Client. The Connection Broker for this will of course be the XenDesktop broker.

HP Remote Graphics Software (RGS): HP's RGS is a protocol that allows realtime remote access to graphics over a LAN providing a local user experience. RGS uses a proprietary HP3 CODEC. A key benefit here is if you're using a pure HP-based solution, this protocol can be brokered by SAM (Session Allocation Manager, a broker which is sold with HP solutions only.)

Both of the above protocols work in essentially the same way. They're both screenscrape-based protocols. The graphics are compressed on the backend resource and decompressed on the end point using a CODEC. Both PortICA/Apollo and RGS are capable of remoting Vista Aero Glass to NON-Vista Aero end points. (UPDATE: Since writing this article, HP contacted me to clarify that remoting Aero Glass is not "officially" supported over RGS, despite the fact that the lead RGS developer told me otherwise. So take that for what it's worth!)

What's the difference between a Blade PC and a Workstation Blade?

Now that we've looked at the protocols, let's look at something else that I'll discuss in this article: "Blade PCs" and "Workstation Blades." Most people probably use the two terms interchangeably, but hardware vendors like HP do not. To HP, these are two different things. The main difference is the hardware specs of the two, although there's a cost difference as well. (Although in reality, any high-end graphically-intense VDI solution is going to be expensive. In most cases when it comes to a solution around high-end graphics, money is not the key factor and the decisions are based on performance and end user experience/perception.)

HP 2500 series "Blade PC"

AMD Athlon 64 X2 3000+ dual-core processor
80GB Serial ATA 5400 RPM hard drive
1GB DDR2 SDRAM PC2 5300 (667 MHz) expandable to 4GB (2 SODIMM slots)
Two Broadcom 590 10/100 Integrated NICs, capable of PXE Boot
Embedded ATI DirectX 9-compliant graphics card

HP Documentation indicates this is “ideal for knowledge workers requiring cost effective access to many applications with increased graphics”.

HP xw460c "Workstation Blade"

1 or 2 Intel Xeon dual-core processors running at up to 2.66 GHz
NVIDIA Quadro FX high performance graphics adapter
Up to 16GB of ECC, DDR2 memory running at 667 MHz
Two 1 GB/s NICs
1 to 2 high-speed Serial Attached SCSI disk drives

HP Documentation indicates this is “ideal for engineers, designers, and traders with applications requiring more demanding 2D/3D graphics and/or the support of more than two displays”

As you can see, a "Workstation Blade" is a much higher-end device, with more processors, more RAM, and a SCSI disk. It is truly an Engineer's Workstation in a blade form factor, whereas a "Blade PC" is more like a typical end-user's computer.

The collaboration between HP and Citrix

What made the collaboration between HP and Citrix on Project Apollo interesting in my mind are two things:

The first is that most servers do not have a GPU in them, and even if they did, you cannot share the GPU in a hypervisor solution because of I/O issues. So to provide a full multimedia experience you only have two “realistic” choices: a blade PC or a workstation blade because each is a 1-to-1 connection which means each user gets their own GPU. You must have a resource on the backend that is Vista Aero Glass capable in order to deliver it to an end point such as a Thin Client. (Of course it's also necessary to have an protocol algorithm that can support it, i.e. PortICA or RGS.)

NOTE: For those of you unfamiliar with the recommended hardware requirements for Vista Aero Glass, they are a 1GHz processor, 1GB of RAM, and a DirectX 9-capable 3D graphics system.

The use case for this would be end users who are working with graphically-intense applications. As the .Net 3.0 architecture becomes more widely adopted and more WPF and 3D applications are deployed, people will be forced to migrate to Vista to take advantage of them. It is not currently possible to get this experience from XP. Nor can you get it from Vista in a virtual machine because Aero Glass is not supported in VMs. Most users are leveraging productivity applications today so for the most part hypervisor-based VDI is sufficient to meet their needs.

However, the more common VDI becomes, the use case for Blade PCs and Workstation Blades will become more compelling as a solution. Certainly some of the existing barriers to adoption will be a thing of the past. The way I see it, with servers becoming more commoditized (with the advent of hypervisors in general, but especially with the embedded hypervisor), the more important the end user experience will become. That means MULTIMEDIA!

A potential road block that I see is having a broker to manage the connections. I understand that at this time the only qualified connection broker is HP's SAM Broker. A key benefit here is if you're using a pure HP-based solution, the RGS protocol can be brokered by SAM (Session Allocation Manager). Both RGS and SAM have been fully qualified on both the HP Blade PCs & Workstation Blades. Today you can remote Vista Aero to XP with RGS but it is not available for Thin Clients.

The second interesting thought is the idea of delivering Vista Aero Glass to a thin client, particularly a Linux-based thin client. Linux is becoming a very attractive option for customers as VDI is becoming more popular simply because the idea of paying for a license for two Microsoft operating systems is unappealing to pretty much everyone. There are also a lot of customers who look at Linux and think “zero maintenance.” In some cases they see that as being more important--more so even than the cost of two Microsoft licenses. A barrier here is end user acceptance. You have to get buy-in from them for this to be successfully deployed. I can say having worked with Linux thin clients, most are starting to look and feel closer to Windows but there is still a marked difference in how you navigate.

I see a great future for VDI, but until the server GPU I/O problem is solved Blade PCs and Workstation Blades are really the only viable solution if you want a complete Vista Aero Glass and Multimedia experience in a VDI scenario. Both HP (RGS) and Citrix (PortICA) are doing some pretty cool work around this and I find it intriguing that it will soon be possible to get a Vista Aero Glass experience using Blade PC's/Workstation Blades to deliver a real-time multimedia experience to a Thin Client, whether it is XPe or Linux.

VB Script to Backup / Restore CPS policies

Mark Elliott — Thu, 06 Dec 2007 06:31:46 GMT

In response to several requests in our forums, Mark Elliott has written a couple of VB scripts that backup and restore policies stored in a Citrix Presentation Server 4.0 or 4.5 farm.

The backup script is pretty straightforward. It allows you to parse two (optional) parameters:

Logging detail level
XML file name the policy information is written to

The restore script has some more parameters, all of which are optional. For example, you can:

Specify the logging detail
Whether or not to apply the policy filter
Whether or not to overwrite a policy if it already exists
The name of the XML file that you're restoring (from the backup script)
The policy name (if you only want to restore a subset of the policies in the XML file)

Download a ZIP file containing these two scripts here.

How to Automate the Backup of a SQL Server 2005 Express Data Store

Katie Koepke — Mon, 07 May 2007 07:13:31 GMT

I recently built a Presentation Server 4.5 (PS 4.5) farm where the decision was made to use a SQL Server 2005 Express database as the IMA data store. When it came time to create an automated backup of the data store, I soon realized the process was not at simple as creating a SQL job in a friendly GUI as with a full-blown SQL Server install, or running DSMAINT BACKUP. This article describes how automate the backup a SQL Server Express data store without having to purchase a third-party tool or without having to learn SQL programming. That said, this document is intended for the non-SQL savvy administrator unfamiliar with creating T-SQL statements.

As you may know, it’s very easy to install and use a SQL Server Express database as your data store since Citrix provides at custom batch file in the PS 4.5 Support folder. Running \Support\SqlExpress_2005_SP1\SetupSqlExpressForCPS.cmd automatically installs and configures a SQL Server Express instance named CITRIX_METAFRAME. By default, three SQL Server Express configuration tools (SQL Server Configuration Manager, SQL Server Error and Usage Reporting, and SQL Server Surface Area Configuration) are also installed on the server, but none of these can be used to configure a backup.

Creating the Database Backup Script

For further SQL Server Express management options download and install SQL Server Management Studio Express . This is a free tool from Microsoft and will be used to create a script to backup your data store.

Once the tool is installed, launch Microsoft SQL Server Management Studio Express and connect to the CITRIX_METAFRAME instance.
Expand Databases and you will see the MF20 database. (This is the default name of the database that was created when creating the Presentation Server farm.)
Right click the MF20 database and select “Tasks | Backup”. A dialog box appears allowing you to define different options such as what type of backup (full or differential) you want to do, backup destination etc. Configure the available options as desired then click the “Options” page on the left-hand column. Continue configuring options accordingly. For example, you may want to select “overwrite all existing backup sets.”
Once all desired options are set, select “Script | Actions to File” and enter a desired file name, for example, “DatastoreBackup,” and specify the location where to save the file.

This creates a .SQL file which scripts the options you defined in the prior step. The contents of your .SQL file may look like this:

BACKUP DATABASE [MF20] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\MF20.bak' WITH NOFORMAT, INIT, NAME = N'MF20-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO

To test your .SQL file run the following from a command prompt.

sqlcmd -S .\CITRIX_METAFRAME -i "C:\<enter path to .sql file>\DatastoreBackup.sql"

If the MF20.bak file was created with the correct data and time stamp then you know your script works. By default the MF20.bak is located in C:\Program Files\Microsoft SQL Server\MSSQL\MSSQL\Backup. (This folder might be “MSSQL.1” or “MSSQL.x” depending on what else is on your server.)

Automating the Database Backup

You can automate the backup process by creating two Scheduled Tasks.

SQLCMD Scheduled Task

First, create a Scheduled Task to automate the .SQL script created above. Use the Scheduled Task Wizard and when asked to select a program browse to use browse to C:\Program Files\Microsoft SQL Server\90\Tools\binn\ SQLCMD.exe. Define the Schedule Task parameters accordingly and click “Finish”.
Go the properties of the newly created Scheduled Task and edit the Run command as such.

"C:\Program Files\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE" -S .\CITRIX_METAFRAME -i "C:\Program Files\Microsoft SQL Server\DatastoreBackup.sql"

Copy MF20.bak Scheduled Task

Next, create a simple batch file to copy the MF20.bak from the local server to a network share located on server being backed up regularly. For example, create a file named, “CopyMF20bak.cmd”, with the following contents.

copy "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\MF20.bak" "\\<servername>\<sharename>\"

Lastly, create a simple Command Prompt Scheduled Task and configure accordingly. (Make sure to run this Scheduled Task after the SQLCMD Scheduled Task.) Go to the properties of the newly created Scheduled Task and edit the Run command to point to the location of CopyMF20bak.cmd (or your respective batch file name).

Resources

http://www.sqldbatips.com/showarticle.asp?ID=27
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=487021&SiteID=1
http://msdn.microsoft.com/vstudio/express/sql/download/

Login Consultants releases free tool for converting MSI packages to SoftGrid sequences!

Jeroen van de Kamp — Tue, 06 Mar 2007 12:10:00 GMT

Now that Softricity has been acquired by Microsoft and its price has been decreased so much, interest for SoftGrid is rapidly growing. Most enterprises have invested in MSI-based application packaging, and converting these packages into SoftGrid sequences can be laborious. To address this, Dennis Damen and Rodney Medina have created the SoftGrid Migration tool (SMGT). The SoftGrid Migration Tool is an add-on for the native SoftGrid Sequencer that helps you quickly “convert” existing automated application setups to SoftGrid Virtualized Applications (a.k.a. "streams" or "sequences") with the least possible amount of user intervention. This tool can be a huge benefit if you're planning to integrate SoftGrid with an existing software distribution sytem like SMS or Altiris. (If you want to virtualize applications that only have a manual setup, we still recommend using the native SoftGrid Sequencer.)

When using the SoftGrid Migration Tool for converting applications the SoftGrid sequencing, best practices still apply. (Check out Microsoft KB article 932137 for a list of sequencing best practices.)

The SoftGrid Migration Tool was written in Visual Basic 2005 and requires the .NET Framework 2.0 or higher in order to work. It's very easy to use:

From the zip file, copy the SGMT.exe, defaults.ini, and SettingsChanged.exe to the sequencer machine and start the SGMT executable.
Add the automated application setup(s) that needs to be converted to one virtual application.
Enter the appropriate SoftGrid Sequencing settings.
Click Start.
When done, copy the content of the entered output path to the SoftGrid Server’s content folder.
Import/Add the application to the SoftGrid Management Console.
Always test the application afterwards!

The tool is 100% freeware and available from Login Consultants download section (free registration required).

Updated: Lanmanserver and Lanmanworkstation Tuning

Michel Roth — Tue, 20 Feb 2007 00:00:00 GMT

Fileserving in Windows environments is usually of critical importance. After all, if you can't reach your files or have to wait five minutes every time you browse a share, the heat starts to build up in the IT department.

File serving is more than just saving a file to your home directory. I wrote a two-part article on MSTerminalServices.org on file serving and Terminal server environments. I suggest you read that article (Part 1 and Part 2 ) first to get a feel for the proper context of this article.

One of the main reasons I wrote that article is that fileserving can easily become a bottleneck if not configured properly, especially in Terminal Server environments.

To solve these performance problems, you sometimes have to tune the fileserver (lanmanserver) and the “fileserver-client” (lanmanworkstation). However, this isn’t for the faint of heart and can cause huge problems if you do it wrong. Unfortunately, documentation on these tuning parameters is rather scarce.

So in this article, I’ll try to explain what the important parameters are, what they do, and how they relate to each other. Once you know this, you'll be able to tune your fileserving environments yourself.

Before we jump into this, please note that there are also a great deal optimizations that you can do in the "Terminal Server Terminal Server Client" hemisphere. Although the basic fileserving principles also apply in that area, this article is not meant to help you perform those optimizations. Also, there is a lot of additional tweaking you can do in other parts of the (Terminal Server) registry. I've purposely left these optimizations out because I wanted this article to focus on the performance of Fileserving components only.

This article was written assuming you’re running Windows 2000 (SP4+) or Windows Server 2003, Service Pack 1.

Core Components

Before we get down and dirty, we need to take a look at the core components that the Windows file serving environment is made of. File serving in Windows is a classic example of a Client-Server mechanism. All you have to do become a file server is to check the box “file and printer sharing for Microsoft networks” in the network connection properties box. On the other end all you have to do to “use” this file server is to check the box “client for Microsoft Networks”.

Both the server and the client components are run as a service. Not surprisingly, this is the "Server" service for the server component and the "Workstation" service for the client components.

Settings for these services are stored in the Windows registry. For the Server service this location is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver. The corresponding location for the Workstation service is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation.

Lanmanserver

By default, the lanmanserver registry key on a freshly installed Windows Server 2003 Service Pack 1 machine looks like this:

The first sub key we encounter is the “AutotunedParameters” key. If you look at it you'll see that it's empty. Don’t worry--it’s supposed to be empty. This registry key exists because, by default, the Server service is auto-tuning. This means that every time the system boots, the server takes a look at the hardware configuration and incorporates any changes in the configuration of the Server service. Changes in hardware that are monitored are the amount of memory and the number of processors. There’s even a formula for it:

(4*(MB*SMBServerPerfSetting)*OSVersion/1)*(#Processors)

where:

MB = Megabytes RAM on the server
SMBServerPerfSetting = .5 if "Minimize Memory Used"
SMBServerPerfSetting = 1 if "Balance"
SMBServerPerfSetting = 2 if "Maximize Throughput for File Sharing"
OSVersion = 2 if running NTServer with > 16MB RAM
#Processors = is the number of processors in the system

In the formula you’ll notice that it refers to the SMBServerPerfSetting. This brings us to the only GUI ‘tool” native to Windows that you can use to “tune” the Server service. When you select the properties of a connection and then select the properties of “file and printer sharing for Microsoft networks”, you should end up with a window like this:

This is where you can optimize the Server service for a specific role. Consequently, if you do the numbers you’ll see that the higher you set the SMBServerPerfSetting, the higher the outcome of the formula is. But what is this number? Good question.

This number represents the value Windows will use for the MaxWorkItems, an important value in tuning the Server service. However, MaxWorkItems is just one of the parameters you can set to tune your fileserver. Let’s take a look at the (registry) values.

Parameters

Before we begin discussing the relevant parameters you can use to tune the Server service you should know that you should create them in the parameters sub key of the lanmanserver registry key. Let’s take look at the most important parameters:

MaxWorkItems

As said, MaxWorkItems isn’t the only thing tuning the Server service. It is one of the most important parameters though. What does this parameter mean? Well, MaxWorkItems specifies the maximum number or work items (receive buffers for file requests) that the Server service is permitted to allocate at one time. If this limit is reached, you get really bad performance out of your file server on even no performance (new connections to the file server are denied).

Possible values: 1-65535

InitWorkItems

This configures the number of work items allocated to a processor during startup. (The "initial" work items.) If this number is too low, it can significantly reduce performance or even deny new connections to the file server.

Possible values: 1-512

MaxMpxCt

This parameter permits a fileserver to provide a suggested maximum number of simultaneous outstanding client requests to itself. During negotiation of the Server Message Block dialect on this initial connection, this value is passed to the client's redirector where the limit on outstanding requests is enforced. A higher value can increase server performance, but requires more use of server work items (MaxWorkItems).

Possible values: 1-65535

MaxWorkItems and MaxMpxCt Relationship

The value for MaxWorkItems must be at least four times as large as that for MaxMpxCt. For example, if MaxMpxCt has a value of 4096, then MaxWorkItems needs to have a value of at least 16384.

MaxRawWorkItems

This value determines the maximum number of raw receive buffers that a server can allocate. If this limit is reached, server performance may be degraded.

Possible values: 1-512

MaxFreeConnections

This value controls the number of free connection blocks that are maintained for each endpoint.

Possible values: 2–4096

MinFreeConnections

This value specifies the minimum number of free connection blocks to be maintained for each endpoint. This setting can sometimes dramatically improve performance.

Possible values: 0–256

SizReqBuf

This specifies the size of a WorkItem (see MaxWorkItems) that the Server service uses. Small WorkItems use less memory, but large WorkItems can improve performance.

When running applications that use a lot of copy or move functions to a remote server (profiles anyone?), the speed at which this function completes is determined by network speed (of course) and by the SMB size. By increasing this WorkItems size, you will allow the server to complete its file copies faster. This will increase the performance of the application making the copy/move calls.

For computers running Windows Server 2003 and with 512 MB or more of physical memory, the default size of the request buffers is 16,644 bytes; for servers with less physical memory, the default size is 4,356 bytes. If this entry is present in the registry, its value overrides the default value.

Possible values: 1-65535

Lanmanworkstation

This key is where all the configuration data for the Workstation service is stored. The lanmanworkstation key by default, looks like this on a freshly installed Windows Server 2003 Service Pack 1 machine:

As you can see, there’s no “AutotunedParameters” here. However, there is a "parameters" sub key in which we can do some tuning. It is not uncommon (especially in Terminal Server environments) to have to tune the Workstation service to alleviate performance problems. This is due to the nature of Terminal Servers. My article on MSTerminalServices.org discusses this in detail, but in a nutshell it’s like this: the workstation service was (and is) designed for a single workstation (like your desktop). However, a Terminal Server can easily host 50 desktop sessions, but unless you do manually intervene this server most likely is still configured just as your desktop would be. It’s pretty obvious that this could lead to some performance problems.

Parameters

Although there aren’t that many important parameters like in lanmanserver, there are still a few parameters of the Workstation service you should definitely know about.

MaxCmds

Specifies the maximum number of network control blocks that the redirector can reserve. The value of this entry coincides with the number of execution threads that can be outstanding simultaneously. Increase this value to improve network throughput, especially if you are running applications that perform more than 15 operations simultaneously.

MaxCmds actually serves the same purpose as the MaxMpxCt on the Fileserver. Not surprisingly these two parameters have a special relationship. It’s like this: whenever an SMB session is setup (i.e. a shared file is accessed), the SMB session is negotiated. During this negotiation the Fileserver passes down the value of MaxMpxCt to the client (a Terminal server for example). The client then compares this value to his own MaxCmds value. The lower of the two values then is used to set a maximum on the number of outstanding client requests to the File server.

Possible values: 1-65535

MaxThreads

The MaxThreads specifies how many threads are allowed to run at once. (Each thread allows one outstanding operation.) By increasing this you can increase the amount of simultaneous work. Each extra execution thread will take 1 Kbyte of additional NonPaged pool memory.

Possible values: 1-255

MaxCollectionCount

Specifies the amount of data that must be present in the buffer of the redirector to trigger a write operation. If the amount of data in the buffer meets or exceeds this value, then it is written immediately. Otherwise, it is retained in the buffer until either more data is added or the value of the CollectionTime entry expires.

Possible values: 1-65535

Monitoring

Problems stemming from poor fileserving performance can sometimes be a bit tricky to pinpoint. One way to make sure is by using good ol’ perfmon. The problem with interpreting perfmon counters is that you can never know what the "right" value is unless you have baselined your environment properly. So what to monitor and how to interpret those values is entirely up to you. However, there are some counters you can monitor that I can give some basic tips on. Configure perfmon to monitor the following counters:

Physical Disk

You can measure this on the Terminal Server as well, but you should start at the file server. If the queue length is more than one for a sustained period of time, then your disks are hyperventilating. Give them some air: up your I/O throughput. Look on the software-side: are you paging a lot? (that'll kill your I/O throughput right there) or is your system disk heavily fragmented? Or on the hardware side: buy faster disks (15K SCSI) or upgrade your RAID controller.

Redirector

This is something you should only measure on your Terminal Server(s). You should monitor the "current commands" in the Redirector object. If the value is higher than 20 during sustained periods of time then you could have a bottleneck.

Server Work Queues

The Server Work Queues object should be monitored on the File server. You should monitor the "Available WorkItems" counter. Sustained values smaller than ten mean that the File server is running out of work items. When it does, performance really starts to plummet. Make sure this doesn't happen by upping the MinFreeworkItems value.

Server

In this object there's a counter called "Work Item Shortages". This value represents the number of times no work items were available or couldn't be allocated to service a file request. Obviously if you see any other value than zero, you need to start worrying. Upping the InitWorkItems or MaxWorkItems could help out here.

Again, there's so much more you can monitor but interpreting the results depends heavily on your environment. Just browsing the performance monitor objects I mentioned and playing around with it will give you a lot more information.

Tuning

So what do I set these registry values to? Unfortunately it’s not that simple. For starters, it depends on your specific environment. Also, an unfortunately side effect of almost every one of these registry values is that when they are increased, they consume more kernel memory. Seeing as (the lack of) kernel memory is often a bottleneck in scaling up in Terminal Server environments, you should be very careful in adjusting/creating the registry settings we discussed. If you are not careful, you could end up having more performance problems than you started out with. You need to know why.

Tuning LanManServer and LanManWorkstation in the registry, requires the use of more Non-Paged Pool memory. This can be a real issue on the File Server (LanManServer). Let me briefly explain where Non-Paged pool memory fits into the whole “2GB-Kernel--Memory-Bottleneck-Of-32-Bit-Windows”.

When you have a 32 bit operating system, this means that you have a 32 bit address space. That translates to 4GB of addressable memory space (2 to the power of 32). This 4GB is evenly shared between the user mode and kernel mode. User mode is the memory space that applications run in and kernel mode is used by the system for everything else. This 2 GB kernel mode memory is divided into several areas, amongst which is the NonPaged Pool. Because there’s only 2GB to share, the NonPaged pool gets configured with a maximum size at boot time. By default this is 256 MB. This 256 MB is the area in which you should perform your (LanManServer) tuning.

Why should you worry about this 256 MB? Well, because if the NonPaged pool is depleted then your system usually becomes unresponsive until some NonPaged pool becomes available again. So how does this apply to LanManServer tuning? Well, if you tune LanManServer in such a way that it allocates memory than the NonPaged pool has available and you indeed use up ALL of that allocated memory then you have effectively pushed Windows beyond its limits.

So what should you do? A safe way of doing it is to tune LanManServer in such a way that it can never deplete the NonPaged pool. The amount of memory LanManServer allocates in the NonPaged Pool is primarily determined by two parameters: MaxWorkItems and SizReqBuf. So if you set MaxWorkItems to 8192 and SizReqBuf to 16644 (default) (which in reality is 20480 due to tracking overhead) the amount of memory LanManServer will allocate is (8192 x 20480 bytes) 160 MB. This fits nicely into the 256 MB NonPaged Pool area.
So it basically boils down to this: If you have more than 512 MB of memory in your Terminal Server (which is every Terminal Server on earth and adjacent planets) then SizReqBuf starts out at 16644. This allows you to push the MaxWorkItems value to 8192. If you try higher numbers to create more of these similar sized WorkItems AND your File Servers tries to use these, you run the chance of running out of NonPaged Pool.

So there is however a decent chance that having 8192 WorkItems does not cut it for you. This is when the bits start to hit the fan. If you’re in that rather sad place, you really have only three options, with option 3 being the safest choice:

Try making the size of the WorkItems smaller (trough the SizeReqBuf parameter) so you can safely set higher MaxWorkItems values. For example: If you set SizReqBuf lower to 8322 (plus a overhead of 3836 makes 12158 bytes) then this would allow you to have 13800 WorkItems ( 160MB / 12158 bytes).
You could even try to up the MaxWorkItems and SizeReqBuf values further with the risk that you run out of NonPagedPool. Now, you should also know that you can tune the Kernel Mode memory in such a way that more memory is allocated to the NonPagedPool. The downside to this is of course is that this memory is taken away from other parts of the Kernel Mode memory. I wouldn’t go there if I were you (unless you’re up there with the likes of Mark Russinovich).
Make sure that less Work Items are demanded from the File Server. This is a topic on its own but quick suggestions are: limit folder redirection (especially Application Data) or / and distribute File Services (put for example home directories on one Fileserver and redirected folders on another).

.ADM Templates

I have provided two .adm templates, one for lanmanserver and one for lanmanworkstation. I've separated these purposely because the lanmanserver adm template should be applied to your File Server and the lanmanworkstation adm template should be applied to your Terminal Servers.

Thincomputing.net Lanmanserver Tuning.zip

This template (download) contains all of the Lanmanserver parameters discussed in this article. When you import the ADM template and enable the policy, it will set the following parameters to the maximum recommended, safe values:

MaxWorkItems
InitWorkItems
MaxMpxCt
MaxRawWorkItems
MaxFreeConnections
MinFreeConnections
SizReqBuf

These optimizations should applied to your FILESERVER, not your Terminal Server. I've included the possibility to 'undo' the optimizations made the template. You can do this by selecting -Undo Lanmanserver Optimizations- and REBOOTING.

Thincomputing.net Lanmanworkstation Tuning.zip

This template (download) contains all of the discussed Lanmanworkstation parameters in this article. When you import the ADM template and enable the policy, it will set the following parameters to the maximum recommended, safe values:

MaxThreads
MaxCollectionCount
MaxCmds

These optimizations should applied to your TERMINAL SERVER, not your File server. I've included the possibility to 'undo' the optimizations made the template. You can do this by selecting -Undo Lanmanworkstation Optimizations- and REBOOTING.

Final Thoughts

Although some settings have been improved in Windows 2000 and even more in Windows Server 2003, I must say that I’m a bit disappointed that file serving problems like I discussed in the article are still quite common in Terminal Server environments. These problems have been around just as long as Terminal Server has, and one would think these problems would at least be a lot less common, but maybe that’s just my point of view.

Microsoft, finally, recently has published an excellent article which discusses these issues in very good detail. This article isn’t just about Terminal Server environments but it is still the best article Microsoft has ever written on the subject. Bookmark KB317249.
I hope that this document has provided you with enough knowledge to combat file serving performance problems.

There’s however a good chance that these problems with the file serving components of Windows will relatively soon be something of the past or at least be a lot less common. Windows Vista and Longhorn server will incorporate many changes, amongst which are major revisions in the file serving components. For example Vista comes with a major revision of the SMB protocol identified as SMB 2.0. The current protocol (SMB 1.0) was built to support file-serving solutions a couple of decades ago and was based on the assumptions existing then.
These are some of the key enhancements in SMB 2.0:

SMB 2.0 supports an arbitrary, extensible way of compounding operations to reduce round trips. This makes the protocol less chatty as compared to SMB 1.0. Chattiness of SMB 1.0 has often been a major pain point.
SMB 2.0 supports much larger buffer sizes compared to SMB 1.0.
SMB 2.0 greatly grows the restrictive constants in the protocol, so we never need to worry about the protocol itself being the limiting factor for scalability. This includes increasing the number of concurrent open file handles on the server, and the number of shares that a server can share out, among other things.
SMB 2.0 supports durable handles that can withstand short network glitches.

All these enhancements in SMB 2.0 will result in better performance and security over LAN and WAN.

Sounds good huh? I’ll believe it when I see it, but the file serving future looks bright!

How to use hot-pluggable client USB storage devices with Citrix Presentation Server

Dennis Damen — Thu, 15 Feb 2007 00:00:00 GMT

A lot of people have been complaining about USB disk support in Citrix Presentation Server. When a user connects a USB drive while working in a Citrix ICA session, the drive will not become visible in that session. While Microsoft has already added support for this in their RDP protocol, Citrix lags behind on implementing this in ICA.

While researching the possibilities of adding support for this ‘hot plugging’ myself, I stumbled upon a great tool called ‘USBDLM’ written by Uwe Sieber. By default, Windows allocates the first available drive letter to an inserted USB storage device which makes management of this device somewhat troublesome. USBDLM installs as a service on a Win32 client and enables YOU, the administrator, to predefine where and how USB disks are made available to your operating system using a simple ini-file. (Just the way we like it!)

While reading the manual, I also came across the possibility to mount USB storage devices to a predefined folder. This is when I realized that this tool could be of great value to the Citrix community. Below you will find a set of instructions on how to make hot plugging USB disks possible within your environment.

The How to Guide

First of all, download USBDLM from http://www.uwe-sieber.de/usbdlm_e.html, extract it, and follow the simple steps as described below. Mind you, USBDLM is NOT free for commercial use so please read the license agreement.

Step 1: Edit the configuration file (on the client)

In the UBDLM directory you will find a USBDLM_example.ini file. Copy this file, rename it to “USBDLM.ini,” and open it using notepad. Scroll down to the [setting] part and add the “ForceDriveLetters=1” setting. Now, scroll down to the [DriveLetters] section and change the “Letter1=” to “Letter1=C:\USB\%DiskName%”. Make sure you save the ini file in ANSI format. UNICODE is not supported.

Step 2: Creating a mount folder (on the client)

As said, USBDLM is able to mount a USB storage device to a folder instead of assigning a drive letter to it. To enable this feature we need to pre-create a folder where USBDLM can mount the USB storage device. Following the previous step we need to create a folder called “C:\USB”. The folder %DiskName% will be auto-created.

Step 3: Making all USB storage devices available through one drive letter (on the client)

Substitute the folder that we created in the previous step using the user’s login script. CMD-based login scripts could add the following line: “SUBST X: C:\USB”. From now on all client USB devices will be available though this drive letter.

Step 4: Enable Client drive mappings (on the server)

There are a number of ways to enable client drive mapping for your Citrix farm. Use the method that best suits your environment.

Step 5: Log on to Citrix farm

Log on to your farm with client drives enabled. The substituted drive will be visible as a normal client drive. Now insert your USB storage device and wait for the contents to show up.

Here's a screen shot from the client showing the local USB device and the remote folder.

Have fun!