Group Policy Central

Thanks to a tip off from fellow MVP Darren Mar-Elia about fairly common issues with Folder Redirection in Windows 7. In short there is a pretty significant issue in Folder Redirection if configured incorrectly that could result in a loss of data for users. There is a mitigation of this issues however this is broken in Windows 7 Service Pack 1. This form post on the SDM Software web site goes into some very specific details about the problem but  below I am going to attempt to summaries the problem and fix for the issue so you can get Folder Redirection working more reliably in your organisation…

Folder Redirection Problem

You have Windows 7 with folder redirection enabled with the “Move contents to new location” option enabled and you then configure a new UNC path for redirection. This NEW path is simply a variation of the path the server that actually points to the exact same location. e.g. \\servername\share to \\DFSNAME\Share . Then when the computer tries to moves the contents of folder to the new (same) location it deletes what it thinks is the old (same) location and thus the users files are deleted. This is BAD! (I hope you have a recent backup)

How to prevent the Folder Redirection from deleting files on move

So to prevent this from happening in Windows there is a Group Policy setting called Verify old and new Folder Redirection targets point to the same share before redirecting that checks if the new and old locations are the same before moving the files. In theory if it detects the source and destination are the same it only move the registry pointer to the new location on the server and leaves all the files in place… However… In Windows 7 Service Pack 1 this option is broken…. BOTHER!!!

Side Note: As pointed out in the forum post it is CRAZY that this is NOT the default behaviour as if you do not configure this option you could inadvertently delete user data. So… Even if this problem does not affect you I would still be seriously be considering enabling this option for your environment.

How to fix the Verify Old and New Folder redirection option

Thankfully earlier this month Microsoft released a KB that fixes this issue https://support.microsoft.com/kb/2799904 . So you can now implement Folder Redirection in your environment configured in a way that will not result in a loss of data…. Phew…

So what does all this mean… ?

1. If you have folder redirection enable, it is (in my opinion) MANDATORY to enable the Verify old and new Folder Redirection targets point to the same share before redirecting option to prevent the possibility of losing user data.

Thanks again to Darren for the tip… and I hope this helps in your environment in avoiding the issues with using  folder redirection.

2. But you also need to apply KB2799904 to fix the Verify Old and New Folder Redirection Target option if you are running Windows 7 Service Pack 1

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)

It should then look something like the image below:

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”,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…

 

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:

1. 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.
2. 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.
3. 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

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.

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.

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

 

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.

Update: How to configure a home drive for VDI

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/

Summary

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…

Acknowledgements

I would like to give a big thanks to fellow MVP Darren Mar-Elia (a.k.a. @grouppolicyguy ) for helping me with this post… You can check out his web site at http://www.sdmsoftware.com and his “Optimizing Group Policy in Virtual Desktop (VDI) Environments” TechEd session at http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL309

This article is a continuation of the other blog post I have previously published at Best Practice: How to deploy software using Group Policy. I highly recommend that you take to the time to review the other blog posting before continuing on reading this post. Most particularly if you are looking at using Group Policy to deploy software please review Tip #1 of the before mentioned article to make sure this method of software deployment is right for you.

One of the pitfalls with deploying software using Group Policy is that you can only specify a UNC path for the workstation for the installation files. The problem with this is if you are in a multi site environment you may end up trying to deploy a fair large software package over a slow WAN link (see image below).

This is creates the obvious problem that it makes the computer un-usable for a long time while the software attempts to download and install. This problem can also be exacerbated if there are multiple clients from the same site trying to install the software at the same time.

So to get around this problem there are a number of different options I will show you that can help mitigate the performance issues with installing software via GPO in a multi-site environment.

Software Library Naming Conventions

First of all I recommend that you implement a good naming convention for the software library in your environment. All installation files for all programs you deploy should be located in the software library so that they are easy to find and maintain.

The image blow shows a tried and true structure for a software library that I have seen work many time for multiple organisations.

This structure makes it very easy to find the programs that you are looking for from an administrative point of view and it allows for easy tracking for what versions of programs you have in your environment.

An example of this structure would look like this:

Sharing and Securing the Software Library

As your computer may need to install software before user logs on so the computers domain account will need to have permissions to read the files from the software library. To do this, at the top level of the folder structure called “Software” you will need to make sure you granted the group called “Domain Computers” read access to all files and sub-folders.

Now that you have secured your top level “software” folder you now need to share it out so that computers can access via the network (see image below). I would also recommend that you make it a hidden share to help hide if from any users that want to snoop around your network.

While you need to apply read permission on the software library for all domain computers you should tightly control modify access to this folder as it is possible that someone or something could plant something nefarious there and have it deployed to all your computers. Normally I don’t recommend that you control access to file using share level permissions however in this case you may want to consider leave the share as “read” only permission for everyone as an extra level of protection. By doing this you prevent anyone (even an IT administrator) from also accidently changing the files or folders which could potentially cause a LOT of issues.

Now that we have the Software Library created we will move on to see what various methods can be used to more efficiently distribute these files for your computers to use as a installation point.

Replicated Software Library (Only)

One way to get around the issue with distributing software is to make sure that you have a copy of the Software Library located at each site that you have workstations located. Simple setup a DFSR Replication Group for the top level “Software” folder and make another copy of the files at the Site B. To make sure workstations in Site B will install from the server in Site B you will need to create another software deployment GPO identical to the GPO in site A with the exception of the UNC path that points to the server in Site B. This way workstation in Site A will install from FileServerA and workstations in Site B will install from FileServerB thus avoiding the clients from pulling the install files via the WAN.

TIP: Remember there might be some replication latency when copying new files to the Software Library so make sure that all your files are fully replicated before you change your Group Policy Objects.

If you do use this method you should target the GPO for site A and Site B to an OU specific to that site. Doing this way would also means that any computer that is configured in the Site A OU but was located in the Site B site (e.g. laptop) would try to install programs via the WAN.

You therefore may be tempted to target your GPO’s to the Active Directory Site but this is something I would definitely NOT recommend. The problem with targeting a GPO to Active Directory Site would mean you would also be targeting all your servers in that site as well. For more on this see the “Linking GPO’s” section in my Best Practice- Group Policy Design Guidelines – Part 2 blog post.

This method does have one advantage and that is workstations that are not located in Site A or Site B will not attempt to install software via the WAN either.

Pros

• Clients install software via LAN
• Suitable for Windows Server 2003 R2 or later
• Suitable for Windows XP clients or later
• Only applies to selected sites
• Low LAN Bandwidth

Cons

• Difficult to manage due to Multiple GPO’s required to be created for each site.
• Large infrastructure requirement for hosting multiple copies of Software Library

I don’t recommended just using this method by itself as you can see when the other methods below can be much easier to administer.

Replicated Software Library using a DFS Namespace

The obvious issues with the “Replicated Software Library (Only)” method is that you needed to create, maintain and target multiple GPO’s to your environment to ensure that software is distributed. To get around this issues you can deploy a domain based DFS Namespace in conjunctions with your DFSR Replication Group which will allow you to manage a single set of GPO’s for all your software deployment needs.

This method allows you to have one UNC path that can be used to distribute software to all your workstation no matter which site they are connected. Having only one UNC path also means that you don’t need to create multiple GPO’s for software deployment in each site.

Tip: As you are relying on a DFS Namespace this also means you have a reliance of you Active Directory Sites as this is how a workstation figures out what is the closest file server. Therefore it would be highly recommended that your AD Sites are configured correctly otherwise you might find that you workstation still installing from file servers in the wrong site.

A downside to this method is that if a computer was to connect to Site X and there was no file server in this site then the workstation would then try to find the next closest file server in another site (this would be bad). To mitigate this issue you really need to be sure that you have a software distribution point located in each of our sites so your workstations always have a local file server to pull the install files from.

Pros

• Clients install software via LAN
• Suitable for Windows Server 2003 R2 or later
• Suitable for Windows XP clients or later
• Low management due to single GPO for all workstations
• Low LAN Bandwidth

Cons

• Software is slow to install if site does not have a copy of the software library.
• Large infrastructure requirement for hosting multiple copies of Software Library

This is probably the most commonly used configuration in most environments today. If you are in doubt as to what then this is probably the solution best balanced configuration of management overhead with

Replicated Software Library using a DNS Alias

This method of software deployment is very similar to the “Replicated Software Library using a DFS Namespace” options mentioned above but it instead relies up DNS Netmask Ordering for the client to find the local file server.

This option is configured on your DNS Servers  (see image below) so it tries to return the closest IP address to the workstation based on the IP of the Workstations and the IP of the multiple A record for the Software Library servers.

For this option to work you also need to have multiple DNS A Records configured to point to all the servers that have a replica of the Software library (see below).

It also requires that your workstation IP address ranges are close or the same as the file servers. This would mean this option would not work if your workstations with in 10.1.0.0/24 subnets and your servers were in 10.0.0.0/24 subnet as they are not logically close to each other.

If you do use this option then you will also need to set Disable Strict Name Checking on the file servers hosting the software library so they will respond to the DNS Alias address.

Pros

• Clients install software via LAN
• Suitable for Windows Server 2003 R2 or later
• Suitable for Windows XP clients or later
• Lower management due to single GPO for all workstations
• Low WAN Bandwidth

Cons

• Software is slow to install if site does not have a copy of the software library.
• Large infrastructure requirement for hosting multiple copies of Software Library.
• Difficult to setup and requires the specific IP Address scheme

This option is definitely not recommend however it is an option that you can use if you are not able to configured a DFS Namespace but don’t want the overhead of maintain lots of Group Policy Objects.

Central Software Library using Branch Cache

BranchCache is an awesome new feature of Window Server 2008 R2 and Windows 7 that allows clients and servers to cache any SMB or HTTP/S traffic. As Group Policy performs software deployment via a UNC path from a SMB file server then it allows for client to cache any files it pulls down via the WAN. This means after an initial workstation in a site has pulled down the install files then workstation can then act as a temporary cache for other computers on the network thus making subsequent installs much quicker. The big advantage of this method is that you don’t need to have any server infrastructure at remotes sites, yet you still get the benefits of reduced WAN traffic and quicker install speeds.

 

In addition if you have a Public Key infrastructure in your organisation then it would be very easy to enabled BranchCache on a server. All the BranchCache clients would then send a copy of the files they download to the BranchCache server in the site so it can also act as a “Hosted Cache”. This would reduce the amount of WAN traffic even further as of course a workstation that is configured with BranchCache would need to be always turned of for act as a cache for the other workstations.

Tip: By default BranchCache is disabled even if it install on a computer. Therefore you need to enable the “Turn on Cache Mode” group policy setting.

Pros

• Clients install software via LAN after second install
• Lower management due to single GPO for all workstations
• Low Infrastructure Requirements

Cons

• Only suitable for Windows Server 2008 R2 and / or Windows 7
• First client to install will be slower

If you are running Windows 7 and / or Windows Server 2008 R2 in your organisation then you should really consider implement branch cache. This really delivers the best of both worlds as you can implement this with a low amount of infrastructure are your remote sites yet still reduce WAN bandwidth all using a single GPO/UNC path to deploy the software.

Summary

As  you can see there are many different option available to you for distributing your software in your environment via Group Policy. In selecting a method of deployment that is right for you environment I would pick firstly the solution that gives the best end user experience and then the one that has the lowest administrative overhead.

Windows Server Update Service (a.k.a. WSUS) is Microsoft free tool they provide for deploying patches and updates. In my experience this tool is pretty much used by every organisation in the world that has more than a hand full of computers. WSUS is also a requirement for the Software Update option in SCCM 2007.

What I hope this post will teach you is how to use Group Policy in your environment to milk the absolute most out of your existing WSUS infrastructure. I am also going to assume that you are familiar with WSUS and already have it deployed in your organisation…

Is WSUS the right tool for your organisation?

Having implement WSUS for an environment of over a combination of 10,000 servers and workstations I can truly say that this tool scales really well. I also believe that even if you have bought and implemented System Center Configuration Manager in your environment then you are probably still better off using WSUS for manage you updates for your Microsoft software. The reason why I still normally recommend that people using WSUS over SCCM is that the product overall is much easier to use and its just human nature for people to want to do the easier tool where possible…

However there are a couple of reason why I think SCCM should still be used over WSUS and they are:

1. You require to wake computers using WOL for them to be patched out of hours. (However there is a way to do something similar using Group Policy).
2. You want to ensure that computers are only patched during a “Maintenance Window” (however even this can be done using Group Policy) and that these patches do not install if it will take longer than that window.
3. The SCCM Software Update supports third party updates when used in conjunction with System Center Updates Publisher 2011. This is very handy if you want to deploy third-party updates from HP, Dell or Adobe (yes! Flash and Reader). But unfortunately even though SCCM SU feature is built on WSUS there is no way to import these third-party updates directly into a standalone WSUS server.

WSUS Tip’s and Tricks

Below are a collecting of configuration recommendations and tips that help you get the most our of your WSUS infrastructure in your environment. These are in no particular order of importance and you might chose to implement only some of these setting depending on your environment.

Terminology: In this post i will use the term “client” many times. When I make this reference note that I am talking about any client of the WSUS Server, which could mean a “client” is either a server or workstation.

WSUS Computer Group Assignment

One of the first things you should do once you have installed WSUS and performed the first sync is enabled the Group Policy computer group assignment. This allows the clients that connect to your WSUS server to be automatically configured in the correct targeting group when they connect to the WSUS server. The target group on the client is controlled using the “Enable client-side target” group policy setting (more on this later).

If you don’t enable this option you will quickly find that you need to manually categorise even new computer that reports into the WSUS server. This is fine if you only have few computers but once you star managing many hundreds or thousands of computers this quickly becomes impractical.

DNS Alias for WSUS Server

One of the options you can set using Group Policy is called “Specify intranet Microsoft update service location” which allows you to specify the WSUS Server name. Even thought this setting can be controlled via Group Policy and thus can be changed in about 2 hours, I still strongly recommend that you create a DNS Alias. Creating a DNS alias for your WSUS Server will give you another way to easily migrate your clients to a new WSUS server without the need to keep a legacy alias of your old server name after you move to a new WSUS server.

Continue reading ‘Best Practice: Group Policy for WSUS’ »

Originally this was just going to be a post showing you how to deploy the Windows InTune client to a computer using Group Policy however it turned out I think this article would be best suited to show you how to use some advanced techniques to deploy software via Group Policy. So even if you don’t want to specifically  deploy the InTune software client to your computers this article will still serve you as a good reference for Group Policy software deployment in general….

Tip #1: DONT! If at all possible do not deploy software this way… Group Policy software deployment has a number of restrictions that makes this one of the less desirable methods of software deployment. Some of the reasons why I would not recommend this deployment method are:

1. Lack or scheduling. When you deploy software to a computer using Group Policy it will only ever install/un-install on the next reboot of the computer. This makes it very difficult to schedule rollouts especially when deploying large software updates that would put immense load on the LAN when deploying to all the computers first thing in the morning when they are all turned on at the same time. Using something like SCCM is much better with it options for maintenance windows and Wake On LAN options…
2. MSI and ZAP Installer Only. The only supported applications formats are the more popular MSI installer and the lesser known ZAP package format. This is somewhat restrictive and again software deployment tools like SCCM are vasty superior as they support any sort of installation method.
3. Fixed Application Install Order. When you add application to the Group Policy Object they install onto the computer in the same order with no way of changing this order.
4. Nill Visibility. When you go to deploy software using Group Policy the configuration it pushed to the computers but there is never any feedback on weather the software has successfully installed. This lack of visibility could mean you think you have deployed something to all your computers successfully but in reality it has failed to install on many of the computers.
5. Poor Scoping. When you deploy software using Group Policy you can only specify a UNC path as the location to install the software from. If you have specified a single server in head office this would mean that all the workstation at remote sites will try and download and install over the WAN… Not good. I will make a few recommendation further on as to how to mitigate this however other deployment software tools (again like SCCM) handle this much more automatically which can reduce you admin overhead.

Now that I have sufficiently warned you about Group Policy Software Deployment I would also say there is one exception to this rule where and that is Agent software Deployment. Weather it is SCCM Agent or InTune or even a Anit-Virus software package GP Software deployment is good at deploying the same software package to a large number of computers.

And speaking of services that require agents…

Windows InTune is a new services that is offered by Microsoft that allows IT administrators to manage and monitor computers via a web based console. This service has been often referred to as SCCM in the cloud as it allows you to manage many workstations without the need for any server infrastructure.

For more information on Windows InTune visit http://www.windowsintune.com/

While there is no software to install on servers for the InTune to work it does require you deploy a management client to your workstations. This client software can be either installed manually but when you have 10+ computer in your organisation this can quickly become a management nightmare so Microsoft also provides a way to deploy the InTune client via Group Policy.

Configuring the application install files for Group Policy Deployment

Step 1: Go to Windows Intune website and download the InTune Client software.

Step 2: Right click on “Windows_Intune_Setup.zip” and select the “Extract All” option

Step 3: Extract the contents of the “Windows_Intune_Setup.exe” to the current folder by opening up a command prompt and  running “Windows_Intune_Setup.exe /extract .”.

Step 4: Copy the all the files (see below) to the software distribution file share in your organisation .

• Windows_Intune_Setup.exe
• Windows_Intune_X64.msi
• Windows_Intune_X86.msi
• WindowsIntune.accountcert

You have now setup the installation files for the InTune client (or other software) ready to be deployed in your organisation.

Tip #2: This location needs to have read permission for the “Domain Computers” group applied so that the computer can download and install the files.

Configuring the Group Policy Object for Software Deployment

Step 5: Edit a Group Policy Object that is applied to all the workstation that you want to deploy the InTune client.

Step 6: Navigate to “Computer Configuration > Policies > Software Settings > Software installation” then right click on “Software installation” then click on “New” then “Packages”

Step 7: Navigate to the path that you placed the installation files and select “Windows_Intune_X64.msi” then click “Open”

Tip #3: If you have x86 client repeat from step 7 with the additional steps in my other article How to prevent x86 (32bit) applications installing via Group Policy on Windows x64 to prevent the x86 version from being deployed to the x64 platforms.

Step 8: Click on “Advanced” and then click “OK”

Tip #4: Wait a few seconds while it reads the MSI…

Step 9: As this is a x64 version of the application I recommend that you Add “ x64” to the name of the program to distinguish what version you have deployed.

Step 10 (Optional): If you want to selectively deploy the client to the workstations click on the “Security” tab and click the “Advanced”.

Step 11 (Optional): Un-tick “Include inheritable permission from this object’s parent.

Step 12 (Optional): Click “Add”

Step 13 (Optional): Click “OK”

Step 14 (Optional): Click on “Authenticated Users” and click on “Remove”

Step 15 (Optional): Click “Add” and select the security group name (e.g. “InTune Computers”) that will be used to assign this application to specific computers.

Step 16 (Optional): Click on “OK”

Step 15: Accept all other default setting and click “OK”

You should now see something like the image below… The software will now install on the selected computer’s at the next reboot….

InTune Note: The client software that you downloaded from the InTune web site is customised for your computers so they will automatically appear in your InTune web console.

Tip #5: If you also have Verbose vs normal status messages enabled you will see the software being installed during computer start-up.

 

How to configure your Distribution Share for Group Policy Software Deployment

See Part 2 Best Practice: Configuring a Software Library for Group Policy Software Deployment