Not everyone is flocking to virtual desktop infrastructure (VDI). Most still have a standard desktop and laptop running the operating system on the actual machine itself.

Your non-Microsoft tablet (dare I say it?), an iPad or Android, for instance, won’t run Windows. So if you want to give someone a remote desktop experience, you can use traditional Remote Desktop Services (RDS)/Terminal Services or create a VDI infrastructure.

A VDI infrastructure is loosely defined as a desktop PC running in a virtual machine on a server using a hypervisor (like Microsoft Hyper-V, Citrix XenApp, or VMware vSphere). These “desktops” can be either persistent or nonpersistent. Persistent means that the user experience feels like a regular desktop. Users’ data and settings are preserved from session to session. Nonpersistent means that users’ changes are wiped out when the session is over.

Creating a VDI infrastructure is way beyond the scope of this book. You can create a VDI infrastructure from only Microsoft components or by using Microsoft and Citrix, VMware, Quest, and many others. You’re on your own for that part. If you’re interested in Microsoft-specific virtualization, check out Mastering Microsoft Virtualization by Tim Cerling and Jeffrey L. Buller (Sybex, 2009).

Also, for the record, I got a lot out of Brian Madden’s “The New VDI Reality” which you can pay for, or get for free here:

http://www.bitpipe.com/detail/RES/1368201274_443.html

However, what I want to do in this appendix is highlight some Group Policy specifics with regard to VDI. We’ll tackle the following topics:

• What is VDI and why is it different?
• Tuning your images for VDI
• Group Policy settings to set and avoid for maximum VDI performance
• Group Policy tweaks for fast VDI video
• And some final thoughts to help you along with your VDI journey

I want to say up front that this appendix was primarily based on two sources from two Group Policy friends.

Source #1 is a great speech that Darren Mar-Elia, fellow Group Policy MVP, did at TechEd 2011. You can find that speech here:

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL309

Source #2 is a great article that Alan Burchill, fellow Group Policy MVP, wrote; you can find it here:

www.grouppolicy.biz/2011/11/best-practice-group-policy-for-virtual-desktops-vdi/

I’ll be sprinkling in as much additional wisdom as I can, but hats off to these guys for doing the hard work for me.

Why Is VDI Different?

VDI is a somewhat different animal than individual desktops and laptops by themselves. That’s because any given desktop or laptop user could be doing something that makes their own machine slower, and no one else really cares.

With VDI, everyone is sharing the same hypervisor and storage. One bad apple makes the whole cart rotten.

Additionally, if you don’t have enough memory allocated per VDI session, those sessions will simply page to disk, causing more disk operations and slowing down everyone on the VDI system.

Before we get going, let’s visualize what happens in a VDI session.

When a VDI session starts up for the very first time from an image, it wakes up, boots, downloads the Computer-side GPOs perfectly normally, and gets fully warmed up. Then a user logs on to the VDI session and processes all User-side GPOs perfectly normally and gets the Start Menu going.

See? The VDI world is not that different than what you already know.

What is a little different between VDI machines and normal machines is that the sessions can either be persistent or nonpersistent. If the session is persistent, then the user gets only the changed GPOs the next time the computer starts and the user logs on. If the session is nonpersistent, the computer throws everything out the window and redownloads all the GPOs (since it’s never seen any GPOs before—as far as it remembers).

So, I want to say that mostly everything you’ve learned so far in this book is perfectly valid. That is, I don’t want you to think too hard about re-crafting your Group Policy world for a VDI rollout. Group Policy will apply normally to VDI sessions as it will for desktops and laptops. What you’re already doing for them (desktops and laptops) is (almost) equally valid for VDI. The dynamic-ness (if that’s even a word) is what you love about Group Policy, and it applies equally to real and virtual machines.

The only big difference is that if you’re using a nonpersistent VDI session, you might want to prebake in some additional settings instead of relying on Group Policy to dynamically deploy them. That way, you’re not downloading the same GPOs again and again—as if it were the first time the computer has ever seen them.

I want to be clear: I’m not saying don’t use GPOs to make dynamic adjustments to your nonpersistent VDI sessions. There are oodles of opportunities to have groups of users get different look-and-feel settings on the fly using Administrative Templates, shortcuts and printers (via Group Policy Preferences), or Firefox settings and UI lockout using PolicyPak. Given all those choices, it still makes sense to use Group Policy with nonpersistent desktops. In this appendix, however, I’ll suggest areas where, especially for nonpersistent desktops, you might want to prebake the settings directly into the image instead of necessarily relying on Group Policy for its dynamic abilities.

And, for persistent VDI sessions, almost certainly do use Group Policy for nearly everything you do now. Because the real Group Policy “speed penalty” occurs only when a machine and user have never seen the GPOs before, there’s little downside to doing precisely what you’re doing now with GPOs. Craft your perfect VDI GPO universe (specifically for VDI machines) and you’re golden.

Tuning Your Images for VDI

All VDI sessions start out life as images. These images then get moved to the hypervisor, and end users “run” them and see a desktop.

So, in the theme of keeping unnecessary disk activity to a minimum, you’ll want to turn off items inside the VDI image that would scan, scrub, or write to the whole disk.

Remember that all VDI sessions start out as some image, which was frozen in time.

The best approach is to plan ahead and turn off the unused services you might or might not want to use. But, ultimately, always, you’ll forget something. Or, you turned something off, and now—oops, some percentage of your VDI population wants it back on.

Good news: I already showed you exactly how to deal with this in Chapter 5, “Group Policy Preferences,” when we leveraged the Group Policy Preferences. You’ll use Group Policy Preferences’ Services extension and specify which users or computers get what directives.

As shown in Figure B-1, use Group Policy Preferences to turn off (disable) any services after the image is finalized.

Remember, anything you bake into your image is static, which means it’ll be faster inasmuch as the service is already off in the finalized image. However, also remember that using Group Policy is the most flexible way to handle turning on or off services.

Specific Functions to Turn Off for VDI Machines

There are a bunch of unnecessary tasks that your system does—tasks that would make total sense if it was a real desktop or laptop but that have little utility in a VDI machine. To that end, to save memory and disk operations, turn off (or don’t install) items like the following:

• Antivirus scans
• Windows Search Indexing
• Defragmentation tasks
• Windows Defender
• Windows Update

In Figure B-2, I’m deleting the unnecessary built-in defragmentation task that comes with Windows.

You might be surprised to see Windows Update and Windows Defender on the list, but here’s the idea. If you’re using nonpersistent desktops (those that ditch whatever users do within the session), then what’s the point of keeping them “updated” and/or “defended”? You could argue that if your machines are unpatched for long periods, the bad guys could infect some other system, which affects your whole VDI population and they in turn become bad guys too. (I’ve seen this with desktops in real life, and it’s not pretty.)

So, I’m not saying don’t ever update your machines. You’ll need some kind of process for updating that’s specific to your VDI world. But you might be able to stop downloading and installing Microsoft patches and such—only to throw them away at the end of a session.

Group Policy Settings to Set and Avoid for Maximum VDI Performance

Again, some items make a lot of sense on the desktop but not on VDI sessions. Here are some favorites you’ll want to make sure are prebaked into your VDI image or always delivered to VDI machines:

1. System Restore VDI by its very nature enables you to snap back a machine to a known state. So, System Restore can be safely turned off. The policy setting is found at Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ System Restore ⇒ Turn off System Restore.
2. Offline Files Users aren’t taking data away with them. So there’s no reason to have Offline Files enabled. This is especially important when it comes to nonpersistent desktops (where the whole system is reset the next time users utilize it). Because of this, there is literally zero utility in having this feature on in those cases. The policy setting is found at Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Network ⇒ Offline Files ⇒ Allow or Disallow use of the Offline files feature. Ensure that you set this setting to Disabled to prevent Offline Files from operating. This policy setting is further discussed in Chapter 10, “Profiles: Local, Roaming, and Mandatory.”
3. BitLocker Disk Encryption Since the disk that users are writing to is in the data center, there’s no reason at all for BitLocker to be enabled. Standard users on a system cannot perform BitLocker operations anyway, so there’s nothing you need to do in Group Policy to turn it off.
4. Outlook and Exchange Offline Cached Mode In a similar vein, if you’re using Outlook and Exchange, consider turning off Exchange Cached Mode for Outlook. All it does is pull down the whole mailbox to the machine, which you definitely don’t need. If you add the Office 2010 templates, the setting is located in User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Outlook 2010 ⇒ Account Settings ⇒ Exchange ⇒ Cached Exchange Mode ⇒ Use Cached Exchange Mode for new and existing Outlook profiles. Set to Disabled.
5. Using File System or Registry ACLs In Figure B-3, you can see two areas that are part of Group Policy Objects but are, in general, a terrible idea on VDI machines.

1. Those two areas are file system and Registry security settings.
2. While these two areas let you re-permission the file system or Registry, this is not something you would want to do inside Group Policy since it’s soooo slooooow. And, moreover, as you learned in Chapter 3, “Group Policy Processing Behavior Essentials,” all security settings reprocess every 16 hours, even if nothing has changed. There’s no reason to saddle your VDI machines with that kind of burden.
3. Using the “Right” Screen Saver Everyone loves those “bells and whistles” screen savers. Problem is, they’re CPU and sometimes disk intensive. Really, anything that uses any visualizations and such eats CPU and ultimately bandwidth because VDI sessions’ displays are remote to whatever device the user is using. To that end, consider setting the blank screen saver. Do this using User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Control Panel ⇒ Personalization ⇒ Force specific screen saver. Set the value to scrnsave.scr, which will establish the blank screen saver for the user.

Group Policy Tweaks for Fast VDI Video

If you use a Microsoft VDI environment, your “work” is happening on the server, and your display is happening on the device your users are using.

Tweaking RDP Using Group Policy for VDI

That protocol performing the displaying is RDP. To that end, you should investigate the RDS settings available to you within Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Windows Components ⇒ Remote Desktop Services ⇒ Remote Desktop Session Host ⇒ Remote Session Environment, as seen in Figure B-4.

To maximize display performance, consider tweaking the following policy settings:

1. Limit maximum color depth Every “bit” counts. You can reduce color depth and save bandwidth across every connection using this policy setting. However the benefit of this is somewhat limited as Microsoft already optimizes the compression for 32-bit color. Best to test this at 16-bit color and compare the difference, then make a call if the reduced quality of the screen is worth the marginal improvements. A good read on this idea can be found at

http://blogs.msdn.com/b/rds/archive/2009/03/03/top-10-rdp-protocol-misconceptions-part-1.aspx

1. Enforce Removal of Remote Desktop Wallpaper Those pretty desktop backgrounds look great. But when RDP has to paint them and all the pixels next to a background over and over again, it’s costly. Enabling this setting makes the backgrounds go away.
2. Limit maximum display resolution The tighter the resolution, the less is transmitted between the server and the client. Enable this setting and specify the resolution to guarantee that users cannot utilize a really big screen and pass around all that drawing data.
3. Use the hardware default graphics adapter for all Remote Desktop Services sessions This setting can enable GPU (graphics processing unit) hardware acceleration if you have supporting hardware on your server, making drawing multiple sessions even faster.
4. Do not allow font smoothing Enabling this policy setting could speed things up under some circumstances. Of all the tuning you could do, this would likely have the least impact if you wanted to try it.

Tweaking RemoteFX using Group Policy for VDI

In Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Windows Components ⇒ Remote Desktop Services ⇒ Remote Desktop Session Host ⇒ Remote Session Environment, you’ll also see mention of Microsoft’s RemoteFX protocol. This protocol can perform some fancy footwork and give high-resolution experiences to VDI and remote desktops.

The following policy settings can be tweaked to maximize speed (and minimize bandwidth) at the sacrifice of some fidelity:

• Configure RemoteFX Adaptive Graphics
• Configure compression for RemoteFX data
• Configure Image Quality for RemoteFX Adaptive Graphics

There are also three settings tucked within a node called “RemoteFX for Windows Server 2008 R2,” (which only apply to Windows Server 2008 R2 and Windows 7, as seen in Figure B-5).

These settings specifically work with RemoteFX on Windows Server 2008 R2:

• Configure RemoteFX
• Optimize visual experience when using RemoteFX
• Optimize visual experience for Remote Desktop Service Sessions

Managing and Locking Down Desktop UI Tweaks

Windows provides a lot of desktop-driven UI settings that you can’t manipulate using Group Policy. Figure B-6 shows the Performance Options Control Panel applet, available in Windows 7 and later. The figure shows the Visual Effects tab, featuring a menagerie of look-and-feel settings that make the desktop more pleasant but put a strain on the CPU and the bandwidth.

The optimal settings here would be to disable all things that produce shadows or transparency. The problem is, doing so is simply not possible using Group Policy settings in the box. Those settings are stored within the operating system as REG_BINARY values, and Group Policy doesn’t have a way to deliver and tweak those specific bits.

It should be noted that PolicyPak can manage these; it has a preconfigured Pak for this that can flip every important bit and also lock down the user interface so users cannot work around it.

Final Thoughts for VDI and Group Policy

In this book, you’ve created OUs that mirrored who would be managing them. We had Frank Rizzo managing the Human Resources OU. And that OU contained sub-OUs—one for users and one for computers.

However, you might want to manage your VDI machines differently than a desktop or laptop. To that end, consider having a separate OU structure for your VDI machines that makes sense for you. I can’t give you specific guidance here, but the point is to separate the computer accounts that represent the VDI computers from the ones that you already have for your real machines.

This arrangement gives you three big benefits:

• You can specifically link GPOs to this structure (and thus avoid affecting your real machines).
• These machines are different (by definition) and hence will be managed differently. And you won’t be able to forget that these machines are different if they’re in a different OU.
• If you use Loopback policy processing for VDI machines, it’s way easier to do.

That final bullet is the next thing I want to talk about here. That is, like RDS machines (aka Terminal Services), VDI sessions are often a good choice to utilize Loopback mode (specifically Loopback—Replace). This enables you to have an environment in which people using the VDI machines get an experience specific to their VDI world. And, when they’re in their normal desktop and laptop world, they get the normal desktop and laptop experience.

I’ve already talked about Loopback policy processing in detail in Chapter 4, “Advanced Group Policy Processing,” and provided examples on when to use it and how it works. Be sure to reread Chapter 4 for more information on Loopback if you need to.

The final thought about VDI machines is that, as with regular machines, the information you learned about profiles in Chapter 9, “Profiles: Local, Roaming, and Mandatory,” and the information you learned about Folder Redirection in Chapter 10, “The Managed Desktop, Part 1: Redirected Folders, Offline Files, and the Synchronization Manager,” is 100 percent valid. That means, when you follow the instructions in this appendix properly, you can have a smooth roaming experience between real and VDI machines, and users will share their profile correctly and see all their redirected files.

And they’ll still like you.