11:52 AM
MISDUONG
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.
VDI Pooled or Non-Persistent
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…
VDI Personal, Persistent or Private
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
Organisational Unit Structure for VDI
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:
- Workstations VDI – This GPO will have all the setting that need to be applied to all your VDI workstations.
- Workstations VDI Pooled – This GPO will only have all the setting applied specific to your Pooled VDI workstations.
- Workstations VDI Personal – This GPO will only have the setting applied specific to your Personal VDI workstations.
Loopback for VDI
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.
Initial Computer Configuration for VDI (Native Only)
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”.
- Remote Desktop
- Remote Service Management
- Remote Desktop – RemoteFX (If required)
The final step you need to perform on the workstation is to :
- Adds the proper RDP-TCP listener permissions for the RD Virtualization Host server
- Restarts the Remote Desktop Services service
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”,1Note: 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.
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
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…
Suggesting VDI Group Policy Settings
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.Disabling Services for VDI
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:
- defragsvc – Defragmentation Service Account of course would generate a LOT of disk IO activity on the server and as you are probably running this on a fairly high end SAN or perhaps even on SSD’s then this is not required.
- WSearch – Windows Search Service is another disk IO intensive service that likes to index all the files on a computer. Having this service enable also put a fairly high load on the system and therefore it is much better to turn this service off.
- wuauserv – Windows Update Service is used to update the software on the computer. However this patch updates on a VDI computer are normally added via a master image or via an new image with the latest updates installed. Therefore this is another service that you will probably want to turn off.
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.
Turn Off System Restore
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.
Disable Offline Files
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.
Disable Exchange Cached Mode
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.
Enable Verbose Status Messages
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
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.
User State Virtualisation for VDI
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.So why use User State Virtualisation with VDI?
Below are some points are to why you would want to enabled USV with VDI:- Reduces disk IO as data files are read and written to file server over the LAN and not the local HDD.
- Reduces storage as the users files and setting are offloaded to another server.
- Enabling Roaming between physical and VDI computers
- Protect users files by storing store on File Server not VDI Server
Personal VDI
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.Pooled VDI
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 how do I apply the USV GPO settings?
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.
- Users that roam between VDI and real computers will not have their documents move with them.
- If folder redirection is not implement but the roaming profiles are configured then the profiles will become very big and slow down the log on / log off process. This would also increase the disk footprint on the real and VDI computers.
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
Group Policy setting for RemoteFX on VDI
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.
Image from http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR312
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..
Group Policy Setting that you should NOT apply to VDI
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.
Posted in: 
0 nhận xét:
Post a Comment