Get-GPOReport -All -ReportType HTML -Path C:\GPOReport.htm
Get-GPOReport -All -ReportType HTML -Path C:\GPOReport.htm
Windows Shell Script
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] "Scancode Map"=hex:00,00,00,00,00,00,00,00,04,00,00,00,2a,e0,37,e0,00,00,37,e0,00,00,54,00,00,00,00,00 REGEDIT.EXE /S _____.reg
Wow! What a confusing title. So, why did I use this?
Your feedback tells us there is some confusion over our terminology for our new extension, Group Policy preferences. And I aim to clear up this confusion in this post.
In the beginning of Group Policy evolved out of what was called “System Policies.” These were what we now call the Administrative Template extension or registry-based policy settings. These settings are considered to be “true” policy settings as opposed to what was then termed “preference” settings. What is the difference between GP policy settings and preferences?
GP policy settings will:
Preference settings will:
There was a desire to create a registry-based setting that was a melding of the GP policy settings with the preference settings which became the GP preferences. Unlike, preference settings, GP preference settings’ behavior is configurable to act differently than a preference setting depending on the options you select.
GP preference settings will:
However, you can change the behavior of the GP preference setting by selecting the “Remove this item when it is no longer applied” option for a specific GP preference setting. After selecting this option, the GP preference setting will be removed when the GPO goes out of scope.
If the option to “Remove this item when it is no longer applied” has been selected, the GP preference setting will be removed. The application will use the default configuration value, not a previously set user configuration value.
Now the administrator can select the “Apply once and do not reapply” option. This will change the GP preference setting’s behavior to only apply the GP preference setting value once and not apply again, even if the user has changed the application’s configuration value.
When dealing with registry-based settings the differences between preference settings and GP preferences are subtle. The biggest difference I want to call out here is that while preference settings are always used in connection with registry-based settings, GP preferences can configure more than just registry-based settings. For more information check out the paper providing an overview of Group Policy preferences, http://go.microsoft.com/fwlink/?LinkId=103735.
Remote Desktop Virtualisation is a feature of Windows that allows your users to run windows running remotely from server hardware. This is almost an identical concept with how Terminal Services (a.k.a. Remote Desktop Services, a.k.a. Remote Desktop Session Host) works where the users is sending keyboard and mouse messaged to the server and then receives the screen updates back. It is so similar in fact that both solution use the Remote Desktop Client and they also share the same Windows Server Remote Desktop Connection Broker role for users to connect to the computer they require.
The key difference is that the computer that the user connects to is a completely separate virtual copy of Windows 7 running in Hyper-V on the server. This allows the users to save files and settings to their computer as it can be setup so that users have a “persistent” 1 to 1 relationship to their virtual computer much like they have a 1 to 1 relation with their own computer. This also means that the user is connecting to an actual copy of Windows 7 and not Window Server 2008 R2 so applications compatibility is also better.
ATTENTION!!! A lot of the setting in this post refer to a NATIVE VDI implementation without the third party enhancements such as Citrix XenDesktop. If you are implementing Citrix or VMWare VDI solution some components of this post will not apply.
VDI can also be configured in two ways depending on your companies configuration.
This method is just has a bunch of identical Virtual Machines that a user will randomly connect to when they logon. Then when that user is logged off the session is scrubbed and there is no latent configuration change made. This method consume less disk space as changes are never kept. But it also has the disadvantage that the user has less ability to customize their computer such as installing their own application.
Pooled Virtual Desktop Drive Configuration
Image Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR312
As these computers are all but users normally have different requirements it is highly beneficial to also deploy virtualisation technology such as Application Virtualisation (App-V) and User State Virtualisation (USV). This allows each user to have a custom desktop configuration with their own set of applications with the same generic base OS. I am not going to go into App-V in this post but I do have more on USV later…
This method has a bunch of Virtual Machines configured that have a persistent 1 to 1 relation with the user when they logon. This affinity with a specific VDI computer is configured via the users account under the new “Personal Virtual Desktop” tab.
Note: You have to be running Windows Server 2008 R2 service pack 1 for this new tab to appear.
If the computer is not started when the user is logged on the back end automatically starts it. When the user logs off the computer any changes made to the drive are saved for next time. This method has the advantage of allowing the users to be an admin of their own VDI computer to make changes and install whatever software they like. However the disadvantage of this is that it has to store all the changes for the users thus consuming far more disk space.
Personal Virtual Desktop Drive Configuration
Image Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR312
You may choose to use either or both configuration however which VDI method you chose will also affect the configuration you apply to the computers…
Note: For the rest of the document I will refer to the two types of VID computers as either “Pooled” or “Personal” however you can obviously substitute the name that you use to refer to these types of configurations for your implementation.
VDI also has the overall disadvantage of having additional system overhead as there are multiple separate copies of Windows 7 running at the same time on the same server all with their own memory space. Recently there has been some great improvements with the new Dynamics Memory feature in Windows Server 2008 R2 Service Pack 1 which has yield a 40% increase in density (Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR324 ). That all being said when you compare the user density between of RDS and VDI you STILL only get about half the number of users on the same hardware (See http://www.twitter.com/mkleef/status/136969504185004032 ).
Note: Before I begin however do note that this guidance mainly covers the configuration of the VM’s running in your VDI infrastructure and is not about configuring the underlying VDI infrastructure.
Below I will now go through a number of ways you can use Group Policy (and other ways) to configure your VDI computers for a optimal experience. Generally speaking however much like you do with Remote Desktop Services the theme of all these “optimisations” is disable, disable and disable… Remember you are trying to squeeze number of users onto you VDI hardware so turning off all the un-necessary components to reduce the per user overhead is the best way to do this…
As you can see from the image below the Disk IO on a VDI system is in extreme demand and constraint hit first when scaling.
Image Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL309
The Organisational Unit Structure for VDI computers will probably look something like the image below. This method keeps the OU structure relatively flat but it also means that you need to duplicate some setting in your normal workstations GPO’s. I think this is an acceptable trade-off as these polices will have Loopback enabled so you can apply user specific setting to these computers (more on this later). I also think if you made the VDI OU a sub-OU of your Workstations OU it would be very difficult to troubleshoot issues with conflicted settings. This configuration would also unnecessarily give your normal workstation administrators control over the VDI computers that you normally want to control a LOT more tightly.
In your environment your VDI OU probably won’t be directly under the Top Level of the domain but this should still give you a template that you can use in any part of your AD. If you have read my previous blog posts Best Practice: Active Directory Structure Guidelines – Part 1 and Best Practice: Group Policy Design Guidelines – Part 2 you may recognize that this design is similar to how I split Laptops and Desktops OU’s (You may also notice that I have also kept with a naming convention that adheres to these two blog posts as well.). The reason why this looks similar is that just as workstations can be classified as either Desktops or Laptops so can VDI workstations be classified as Pooled and Personal, hence the similar design. This also means that for this structure to work ALL VDI computer accounts MUST be in either the Pooled or Personal OU. This would therefore make it invalid to have a compute account directly in the VDI OU.
Here is a description of the three main group policy objects that are applied in this configuration:
There are various user setting you may want to apply to your users when they logon to the VDI computer. Just as with Remote Desktop Service the use of the User Group policy loopback processing mode is the setting that allows you to apply these users setting.
Further on in this post I discuss many user setting that you might want to configure however if you don’t have any users setting configured in your VDI Group Policy Objects then there will be no need to enabled loopback.
Note: This following configuration setting will only need to be applied if you are using a native VDI Implementation without third-party VDI software.
It is important that you configure the workstation for VDI as described it this guide Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide . Thankfully there is a PowerShell script that can do all the configuration changes for your VDI workstations image that you can download from http://go.microsoft.com/fwlink/?LinkId=184804 . However scripts are only a one time configuration and I like to re-enforce these changes with Group Policy where possible to ensure the configuration does not vary. Doing this also makes it easier to discover what changes have been made by running a GPResult report on the computer. Another advantage of having Group Policy makes all these changes is that all the configuration changes are automatically applied to your workstations when they are built making the process quicker and less likely to be forgotten.
Warning: Any additional setting via Group Policy could cause extra overhead so you many want to only be selective as to what initial computer setting you apply via Group Policy. For that reason you may want to consider running the PowerShell configuration script as a one time “Immediate” task on the computer via Group Policy instead of configuring all these changes individually.
If you chose to use Group Policy instead of a script (good on you) to setup your VID environment then make the following configuration change in the “Workstations VDI” Group Policy Object.
Enable Remote Desktop
You can enabled Remote Desktop using the Allow users to connect remotely using Remote Desktop Services setting. This will change the configuration of your computer to allow Remote Desktop Connections to the VDI workstation. However as you can see from the image below this does not open up the require firewall port (3389) to allow an incoming RDP connection.
Enable Remote Procedure Call (RPC)
To enable the Remote Procedure Call (RPC) feature all we need to do is use the Group Policy Preference Registry Extension to change registry key “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AllowRemoteRPC” to a value of 1 (see image below).
Adds selected users to the Remote Desktop Users group
You can configure the “Remote Desktop Users” group using the Group Policy Preference Local Users and Group Extension.
Add a Windows Firewall exception for Remote Desktop Services and Add a Windows Firewall exception for Remote Services Management
Now the two “Windows Firewall Exceptions” can be made by adding the following predefined inbound firewall exceptions under “Computer Configuration>Policies>Windows Settings>Security Settings>Windows Firewall with Advanced Security”.
It should then look something like the image below:
The final step you need to perform on the workstation is to :
However these steps are some what more difficult to perform as there is no Group Policy to make these configuration nor is the “Remote Desktop Session Configuration Host” tool loaded to make the changes via a GUI.
If you could load (or remotely connect this tool on Windows 7) it would look something like this by default…
So as much as a loath saying it you will need to resort to a script to perform the necessary configuration using the WMIC command.
To do this just copy the following script and put it on a server share that has the “Domain Computer” group granted read permissions.
wmic /node:localhost RDPERMISSIONS where TerminalName=”RDP-Tcp” CALL AddAccount “contoso\VDI Servers”,1 wmic /node:localhost RDACCOUNT where “(TerminalName=’RDP-Tcp’ or TerminalName=’Console’) and AccountName=’contoso\\VDI Servers’” CALL ModifyPermissions 0,1 wmic /node:localhost RDACCOUNT where “(TerminalName=’RDP-Tcp’ or TerminalName=’Console’) and AccountName=’contoso\\VDI Servers’” CALL ModifyPermissions 2,1 wmic /node:localhost RDACCOUNT where “(TerminalName=’RDP-Tcp’ or TerminalName=’Console’) and AccountName=’contoso\\VDI Servers’” CALL ModifyPermissions 9,1 shutdown /r /t 0
Note: I have used the group called “VDI Servers” so you will need to create this group and add all your VDI server to this group. This way you can use the same script to configure all your VDI workstations.
You can then call this script as a once using the “Immediate Task (Windows Vista and later)” option in the Group Policy Preferences Scheduled Task Extension
Configure the task to run as the “SYSTEM” account so it has the permission to make the required changes and reboot.
Then chose the “Start a program” action and run the script where you have saved it on the network (remember that it must have “Domain Computer” read permission granted).
You have now configured group policy to automatically configured your Windows 7 workstations as a VDI ready computer once it is placed in the VDI OU structure.
However there are still a number of other suggested configuration settings you might want to apply to this computer…
The next session shows a number of suggested Group Policy setting you should apply to you VDI configuration… Of course these are only suggestion/recommendations and you should take into consideration your own requirements before implementing these changes.
Service are of course background tasks that run in Windows. These tasks of course takes some CPU,Memory and Disk overhead to run and therefore it is best that you disable all the non-essential services for your VDI workstations to squeeze in more users. To disable the services I like to use Group Policy Preferences Service Extension as it allows you to specify a custom service name that is not necessarily installed on the computer you are editing the group policy object.
The three service most obvious services I would recommend disabling are:
You of course may have other inbuilt or third-part service that you want to disable and you can also do this by simply typing the short name of the “Service Name” text box when configuring a new service configuration item.
To Disable System Restore is another setting that prevents the VID computer form consuming more disk space. You can disable this setting using the “Turn Off System Restore” policy setting.
Disabling offline files is another way you can reduce your server IO load and disk footprint. You can do this via the “Allow or Disallow use of the Offline Files feature” group policy setting. You may want to configure this setting for only your Pooled VDI Workstations as there can be some performance benefit with having offline files enabled especially if the files you are access are via a slow network link.
Therefore I recommend that you Disallow for Pooled VDI computers to conserve disk space and Allow for Personal VDI computers so long as you have spare disk resources.
Disabled the Outlook Cached mode by using the “Use cached exchange mode for new and existing Outlook profiles” group policy setting would have to be the #1 setting that you should turn off for both Remote Desktop Servers and Pooled VDI Computers. This setting tries to download a cached copy of your entire inbox. This normally only happen during the first logon for a user to a computer, but because each logon to a Pooled VDI computer is like a first logon then this will happen again… and again… and again… if it is not disabled.
That being said for Personal VDI computer there can be some advantage to having this setting enabled as it allows the users to still read their email even when the exchange servers is offline.
So this is another one that I recommend that you Disable for Pooled VDI computers and Enable for Personal VDI computers assuming you have enough disk space.
I am a really big fan of configuring verbose status message’s (See Group Policy Setting of the Week 2 – Verbose vs normal status messages) as it gives the users the feeling that the computer is actually doing something rather than just “Loading desktop…” when logging on. You can enabled this via the verbose vs normal status messages setting under Computer Configuration\Administrative Templates\System.
Screen savers can of course be very graphical and thus consume a lot of system resources. This means that your VDI server could get smashed when all the users go idle and the screensavers kick in… Therefore we want to ensure that users only use the default “scrnsave.scr” screensaver that does nothing but display a blank background. To do this you need to configure the “Force specific screen saver” policy under User Configuration>Administrative Templates>Control Panel> Personalization.
It goes without saying that when users log onto a computer they of course don’t want to setup their environment every time. I have written a VERY extensive blog post about User State Virtualisation called Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization). I strongly encourage you read this blog post as well if you are going to implement USV in VDI as most of these recommendations also apply for a VDI environment.
Below are some points are to why you would want to enabled USV with VDI:
As you can see there are many benefits with using USV with VDI however your decision to use USV may influenced by the method of VID that you implement… Of course as you are offloading the Disk IO from the local HDD to a file server on the LAN it is imperative that the file server is well connected via at least 1gbit low latency Ethernet connection.
If the user has a Personal VDI workstations then USV may not be required as the computer will have saved all the setting and documents from the last time the user was connected. That being said there are still benefits with having USV enabled for a user on a Personal VDI workstations as it allows them to roaming the settings and files between the VDI environment and a real computer. Therefore you may consider VDI an option for users using a Personal VDI session.
If you use a Pooled VDI workstations as then it is very much like logging on to the computer for the first time. Therefore they will be required to setup there environment every time they connect (ANNOYING!!!). So it is somewhat imperative that you do enable USV for the users connecting to a pooled VDI configuration.
So if have decided to implement USV for your VDI user you will need to configure their profile path in their account properties (see image below).
The folder redirection Group Policy setting can however be applied either on the user accounts Organisation Unit OR via Loopback GPO on the VDI computers OU. To ensure complete roaming of the users setting and files I would definitely apply the folder redirection GPO’s on the users account that way they have a consistent user experience when logging onto a physical or a VDI computer.
Note: When deploying folder redirection it is very important that your redirection location is close (network wise) from your VDI servers. This is needed so that users can quickly access their redirected folders. This is even more important if the file server that host the redirected folder only support SMB v1 due to its poor performance on network links with high latency. This is less important if you have a Personal configuration with offline files enabled as the local caching can mitigate some of these performance issues.
Recommended: Due to the improved performance and saleability of the SMB v2+ protocol it highly recommended that your folder redirection file server is at least Windows Server 2008. It would also be highly desirable to make this server x64 bit as this will allow it to scale to a higher number of concurrent file connections.
User Only Folder Redirection
But if the only you have to implement folder redirection is to apply the setting on the VDI computers OU be aware that this might have some pretty big problem. If a user ever logs onto a non-VDI computer their roaming profile may not have any of the documents or files that the users had in the VDI. This can also lead to the users roaming profile growing very quickly as the documents folder on a non-VDI computer is now part of the users roaming profile. However when the user then subsequently logs back onto the VDI computer these documents will be hidden as they folder will again be redirected to the server.
VDI Only Folder Redirection
What you should ABSOLUTLEY NOT do is apply folder redirection on both the users OU and the VDI OU. Doing this could cause your users redirected folders to be moved from two different locations every time they logon greatly slowing down the logon process..
If your VDI infrastructure in a datacentre then you might find that their redirected folders will perform quite slow accessing their redirected folders. In this case you might want to setup a folder redirection on the user account and the VDI Computers OU. If you do make this configuration change make very sure you do not select the “Move the contents of Documents to new location” option as this will cause your users redirected folders to bounce all over the network every time they logon.
While this method would give the users fast access to their folder it would also mean that these files would not follow them when going between a physical and VDI environment.
Dual Configuration Folder Redirection
RemoteFX is a new feature of Windows Server 2008 R2 that allow you you to stream full DirectX applications to your remote clients. This new feature can share the resource of any 3D graphics card in the server to get full hardware acceleration. Some of the other new features of Remote FX is the USB Device Redirection. This allows you to redirect pretty much any type of USB device that can be plugged into the remote client.
But if you want to enable this feature you will need to enable the setting “All RDP redirection of other supported RemoteFX USB device from this computer” that is located under Computer Configuration>Administrative Templates>Windows Components>Remote Desktop Services>Remote Desktop Connection Client>RemoteFX USB Device Redirection.
Note: This setting requires a reboot after being applied.
However if you want to be somewhat selective with what devices (e.g. iPhones) you allow you users to plug into your VDI / RemoteFX environment then you can us the “Prevent installation of device that math any of these device IDs” under Computer Configuration\Administrative Templates\System\Device Installation Restrictions.
There are many other RemoteFX setting you can apply to your RemoteFX/VDI environment under Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment. However these setting will need to “tweak” for your own environment..
So I have covered a few of the optimised group policy settings to your VDI computers however there are also some other group policy setting that you should avoid applying to your VDI computers.
Don’t applying Registry and File System permission via Group Policy as this will apply the permission every 18 hours (approx.) causing a MASSIVE load with IO on your VDI Server. Which is of course you now know a very bad thing…
DONT CONFIGURE THESE SETTING
If you do need to apply custom permission to the VDI computer then consider setting the permission in the master images or push a script out as a one time task VDI workstations.
If you want to configure your VDI users with a different home drive then there is a new group policy setting called “Set Users Home Folder” which allows you to specify what home drive the user receive. This setting can only be applied to the computer and as such makes it only useful for VDI environments when you want to give users a different home drive. For more information on this setting check out my other blog post http://www.grouppolicy.biz/2012/07/how-to-set-users-home-folder-via-group-policy-in-windows-8/
You may find that a lot of the setting you apply to your VDI systems are similar to the same policy you have applied to your Remote Desktop Services servers. This is quite true as just with RDS your VDI group policy setting revolve around reducing the overhead of the VDI workstations so you can squeeze the most out of your hardware… That being said, remember that if what you want is higher utilisation of your hardware you are always going to get more users on the same hardware using Remote Desktop Services…