Group Policy Central

If you have ever read my Best Practice for Group Policy blog post then you will know that I encourage you to edit the default domain GPO’s sparingly. The only exception I would make to this rule is when you want to modify the default domain password policy but even then you can create a new password policy GPO linked at the domain level (See Tutorial: How to setup Default and Fine Grain Password Policy )

Even if you don’t want to take my word for it here is a reference on the TechNet web site say pretty much the same thing… 

TechNet: Establishing Group Policy Operational Guidelines

Do not modify the default domain policy or default domain controller policy unless necessary. Instead, create a new GPO at the domain level and set it to override the default settings in the default policies.

So… Lets assume you have done everything wrong and either the Default Domain and/or the Default Domain Controller Group Policy objects have been modified and you want to reset them back. Of course you have a backup of the GPO’s which are good and you simply restore them….

BUT… You have never backed up the default GPO’s and you need to reset the setting…. Well the tool that allows you to do this is called DCGPOFIX and it can be found on any Windows Server 2003 or later windows server.

NOTE: Even though we are restoring the default domain GPO’s back to a default setting doing so may still cause more issues. Therefore make sure you have a current back of your default domain so you can easily undo this change if needed (see below).

TIP: Even if you are not going to run this command I would still make of these Default Domain GPO’s now…  right now…. Go on… Its not going to hurt and this will at least give you something to roll back if you need to in the future.

The command to restore the GPO’s to default is as simple as running the “DCGPOFIX.exe” from a command line and press “Y” twice when prompted.

Now you are done. You will notice any changes to the GPO have now been removed or reverted back to the default settings. Monitor your systems for any adverse affect and make sure that you have another backup of the GPO’s for future reference.

Note: By default this command will not run if the version of the OS does not match that of the Schema version in AD.

References:

• The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state
• Core Group Policy Tools and Settings

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.

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

Changing file association windows by hacking the registry can be a very challenging task even if you are using Group Policy Preferences Registry option to apply the changes. However there is an option with Group Policy Preferences that allows you to change the Open With (i.e. File association) for any file type.

Below I show you how you can do this using the simple, yet powerful Folder Options by showing you how to change the default association for .TXT files from Notepad to WordPad.

Step 1. Edit a GPO that is targeted to the used that you want to apply this setting.

Step 2. Navigate User Configuration > Preferences > Control Panel Settings then right click on Folder Options and Navigate to New > Open With .

Step 3. Type in the extension in the File Extension and then put in the path to the program you want to have open the file. Then optionally tick “Set as default” and press “OK”

TIP: When specifying the file path keep in mind that it may be different for x86 and x64 platforms therefore it may be best to use the %ProgramFilesDir% variable.

Your done… Now when you click on that file type it will open it in the new default open with program you specified.

Before

After

One strange thing that still seems to catch a lot of people out is that you can only have one password policy for your user per domain. This catches a lot of people out as they apply a password policy to an OU in their AD thinking that it will apply to all the users in that OU…. but it doesn’t. Microsoft did introduce Fine Grain Password Policies with Windows Server 2008 however this can only be set based on a security group membership and you still need to use the very un-user-friendly ADSI edit tool to make the changes to the policy.

Below I will go through how you change the default domain password policy and how you then apply a fine grain password policy to your environment. The Good news is setting the default password policy for a domain is really easy. The Bad news is that setting a fine grain password policy is really hard.

Update: If you want to set a password complexity setting that is not supported out of the box of windows then it is possible to install a third-party DLL on you domain controllers to achieve this. However there are many caveats to this and it is best you check out the full explanation at http://blogs.technet.com/b/askds/archive/2011/08/05/friday-mail-sack-beard-seconds-edition.aspx#password

How to set a Default Domain Password Policy

Step 1. Create a new Group Policy Object at the top level of the domain (e.g. “Domain Password Policy”).

Note: I have elected to create a new GPO at the top of the domain in this case as I always try to avoid modifying the “Default Domain Policy”, see references below.

Reference

TechNet: Linking GPOs

If you need to modify some of the settings contained in the Default Domain Policy GPO, it is recommended that you create a new GPO for this purpose, link it to the domain, and set the Enforce option.

TechNet: Establishing Group Policy Operational Guidelines

Do not modify the default domain policy or default domain controller policy unless necessary. Instead, create a new GPO at the domain level and set it to override the default settings in the default policies.

Step 2. Edit the “Domain Password Policy” GPO and go to Computer Configurations>Policies>Windows Settings>Security Settings>Account Policy>Password Policy and configured the password policies settings to the configuration you desire.

Step 3. Once you have configured the password policy settings make the “Domain Password Policy” GPO the highest in the Linked GPO processing order.

TIP: Make sure you inform all your users when you are going to do this as it may trigger them to change their password the next time they logon.

Done… told you it was easy….

Note: Even if you apply the password policies to the “Domain Controllers” OU it will not modify the domain’s password policy. As far as I know this is the only exception to the rule as to how GPO’s apply to objects. As you can see in the image below the “Minimum password length” in the “Domain Password Policy” GPO is still applied to the domain controller even though I have another GPO linking to the “Domain Controllers” OU configuration the same setting.

For a better explanation as to why the GPO that is linked to the Domain and not the Domain Controllers is used for the password policy for all users check out Jorge’s Quest for Knowledge! – Why GPOs with Password and Account Lockout Policy Settings must be linked to the AD domain object to be affective on AD domain user accounts

 

How to set a Fine Grain Password Policy

Fine Grain Password Policies (FGPP) were introduced as a new feature of Windows Server 2008. Before this the only way to have different password polices for the users in your environment was to have separate domains… OUCH!

Pre-Requisites/Restrictions

You domain must be Windows Server 2008 Native Mode, this means ALL of your domain controllers must be running Windows Server 2008 or later. You can check this by selection the “Raise domain functional level” on the top of the domain in Active Directory Users and Computers.

Reference

AD DS: Fine-Grained Password Policies

The domain functional level must be Windows Server 2008.

The other restriction with this option is that you can only apply FGPP to users object or users in global security groups (not computers).

Reference

AD DS: Fine-Grained Password Policies

Fine-grained password policies apply only to user objects … and global security groups.

TIP: If you setup an “Automatic Shadow Group” you can apply these password policies to users automatically to any users located in an OU.

Creating a Password Setting Object (PSO)

Step 1. Under Administrator Tools Open ADSI Edit and connect it to a domain and domain controller you want to setup the new password policy.

Note: If you do not see this option go to “Turn Windows Features On or Off” and make sure the “AD DS and AD LDS Tools” are installed. (You will need RSAT also installed if you are on Windows 7).\

Step 2. Double click on the “CN=DomainName” then double click on “CN=System” and then double click on “CN=Password Settings Container”.

Step 3. Right click on “CN=Password Settings Container” and then click on “New” then “Object…”

Continue reading ‘Tutorial: How to setup Default and Fine Grain Password Policy’ »

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.