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

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

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

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

Step 4. Click on “Next”

Step 5. Type the name of the PSO in the “Value” field and then click “Next”

Note: With the exception of the password length the following values are all the same as the default values in the “Default Domain Policy”.

Step 6. Type in a number that will be the Precedence for this Password Policy then click “Next”.

Note: This is used if a users has multiple Password Settings Object (PSO) applied to them.

Step  7. Type “FALSE” in the value field and click “Next”

Note: You should almost never use “TRUE” for this setting.

Step 8. Type “24” in the “Value” field and click “Next”

Step 9. Type “TRUE” in the “Value” field and click “Next”

Step 10. Type “5” in the “Value” field and click “Next”

Step 11. Type “1:00:00:00” in the “Value” field and click “Next”

Step 12. Type “42:00:00:00” in the “Value” field and click “Next”

Step 13. Type “10” in the “Value” field and click “Next”

Step 14. Type “0:00:30:00” field and click “Next”

Step 15. Type “0:00:33:00” in the “Value” field and click “Next”

Step 16. Click “Finish”

You have now created the Password Settings Object (PSO) and you can close the ADSIEdit tool.

Now to apply the PSO to a users or group…

Step 17.  Open Active Directory Users and Computers and navigate to “System  > Password Settings Container”

Note: Advanced Mode needs to be enabled.

Step 18. Double click on the PSO you created then click on the “Attribute Editor” tab and then select the “msDS-PSOAppliedTo” attribute and click “Edit”

Step 19. Click “Add Windows Accounts….” button.

Step 20. Select the user or group you want to apply this PSO and click “OK”

Step 21. Click “OK”

Step 22. Click “OK”

And your are done…  (told you it was hard).

Other Useful Links

AD DS: Fine-Grained Password Policies

AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

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.

Tip: Make sure that the issue is related to the users roaming profile by testing another account with the same or similar privileges on the same computer. If the other computer account also has the same issues or if the issues seems to does not follow them to other computers then it is highly unlikely it is a roaming profile issue.

So lets assume you have troubleshoot this issue for many hours and you are at your wits end about to rip out your hair (if you have any) and have decided to reset the users profile… how do you do it?

In Windows XP days you could just delete the users local and roaming profile files and the next time the user logged on they would generate a new profile. However if you do this in Windows 7 you will find that this no longer works…

So what is the correct way to reset a roaming profile in Windows 7?

Step 1. Open Active Directory Users and Computers and to the profile tab of the user account you want to reset. Now take note of the roaming profile path….

Step 2. Reboot the users computer that is having issues and logon with an account that has local admin and is NOT the account you are tyring to fix.

Step 3. Open control panel and type “Advanced” in the search field then click on “View advanced system settings”

Step 4. Click on the “Advanced” tab and under User Profiles click the “Settings” button

Step 5. Now select the user you want to reset the profile and press the “Delete” button.

Step 6. Press “Yes”

And now the local copy of the roaming profile is deleted you also need to remove the network copy…

Note: If you have implemented folder redirection as per my Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization) then the vast majority of the users information will not be part of the users roaming profile. This means other than a few program setting the users is unlikely to lose any work. The exception to this is the AppData folder however if you are trying to preserve this folder as well note you may be copying over the issues that are trying to fix.

WARNING: Always be careful you have everything backed up before deleting any users profile.

Step 7. Before you log off that computer go to the path you noted in step 1 and delete (or rename) the roaming profile for that users on the network.

Note: You many need to take ownership of the folder before it can be deleted.

Tip: To avoid having to take owner ship of the roaming profile be sure you have enabled the  Add the Administrator security group to roaming users profiles setting.

How to fix the “You have been logged on with a temporary profile” issue in Windows 7

So… that was the easy way… But what do you do if just deleted the users profile files and now the users is “logged on with temporary profile” like you did back in the Windows XP days….

Step 1. Reboot the computer again and logon as the local admin.

Step 2. Open Regedit and go following registry key path:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Step 3. Find the Profile that has the ProfileImagePath of the users you are fixing and delete that entire key.

Step 4. Log off and logon as the user you are trying to fix.

TIP: If this is successful make sure you get the use to log off straight away so the new profile is save to the network which will then propagate to any other computer when then log on.

Hopefully this will have fixed your roaming profile issues and the users is now back up and running with a minimum of fuss… Of course some of the users personal settings may have been lost but hopefully a well managed SOE should allow them to run all the essential programs with little to no additional set up.

Source: I found the registry key trick from this TechNet Forum article http://social.technet.microsoft.com/Forums/en-US/w7itprogeneral/thread/5ec0b949-effa-4e30-ba09-dc948a4c7a8b

This problem is due to a bug in  IE6 that it ignores the <!DOCTYPE> if it is not on the first row and then default back to rendering the page in Quirks mode. The problem is that newer browsers do read this <!DOCTYPE> tag if it is not on the first line and it then starts to renders the page in standards mode as requested. So to address this issue Microsoft have released a hotfix for IE8 and include in IE9 a feature that lets you force pages to render in Quicks Mode thus ignoring the <!DOCTYPE> line.

A webpage is not displayed correctly in Internet Explorer when any of the following is true:

• You use Windows Internet Explorer 8 Standards mode to browse the webpage.
• You enable Compatibility View in Internet Explorer 7 to browse the webpage.

Additionally, if you do not have the permissions to implement the Meta tag or the HTTP header for browser emulation, you cannot force the browser to work in QUIRKS mode from the client-side.

Microsoft KB A webpage is not displayed correctly when you browse the webpage by using Internet Explorer 8 Standards mode or Compatibility View in Internet Explorer 7

Once you have the hotfix deployed or you have installed IE9 on your computers you can then use the policy  “Use Policy List of Quirks Mode sites” under Software\Policies\Microsoft\Internet Explorer\BrowserEmulation\QuirksPolicyList to add specific sites to render as quirks mode.

This will now force your browser to render the page using IE5.5 (a.k.a. Quirks) mode so that the page now renders correctly.

TIP: If you are still having issues with your Intranet pages not working correctly one of the other big compatibility fixes you can try is to make sure that the page is properly placed in the “Intranet Zone”. For instructions on how to do this see my other post How to use Group Policy to configure Internet Explorer security zone sites .

Thanks to Chris Jackson “The App Compat Guy” for his TechEd 2011 video that had the details for me to write this article at  http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL315

For more on trusted in browser applications see http://timheuer.com/blog/archive/2011/04/13/whats-new-in-silverlight-5-a-guide.aspx#trustinbrowser

A new feature we are bringing is the ability to do some of the “trusted” features in Silverlight in the browser. This brings the current functionality of trusted applications in current form to be used in the browser context without having to be installed. This still requires the XAP to have the ElevatedPermissions security setting in the manifest as it would exist with out-of-browser applications as well as the XAP being signed (and the certificate in the user’s trusted publisher store).

 

Additionally the requirement would be that a registry key be set on the machine to enable this. This could be deployed via Group Policy or other desktop-management techniques.

Below I have listed this registry key and how you can use a Group Policy Preferences Registry Item to configure this setting in your organisation.

Allow Elevated Trust Apps In Browser

Key (Machine): HKLM\SOFTWARE\Microsoft\Silverlight\
Value: AllowElevatedTrustAppsInBrowser (REG_DWORD32)
Data: 0 (Disabled)
Data: 1 (Enabled)

Step 1. Edit a group policy object that targets all the computers in your organisation that you want to apply this setting.

Step 2. Navigate to “Computer Configuration > Preferences > Windows Settings” then right click on “Registry” and click on “New > Registry Item”

Step 3. Change the Action to “Replace” add the key path “SOFTWARE\Microsoft\Silverlight” type “AllowElevatedTrustAppsInBrowser” select the Value type to “REG_DWORD” and the value to “1”.

Step 4. Click on the common tab and tick “Remove this item when it is no longer applied” and add a description.

Done… the registry key should be now deployed to all your computers and they will be able to run Trusted (Signed) application in the web browser.

To see what other features are coming in Silverlight v5 go to http://www.microsoft.com/silverlight/future/

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

Unlike the normal Background option the Logon UI Background is only show when the computer is not logged on or when it is locked. While I know some of you might loath having to set a wallpaper for your users computers as like myself you like to have the freedom to change this setting. This may be a much nicer balance for your user and management as you can still have your corporate branding applied to your computers but still allow the users to have their own custom background image when they are logged on.

Tip #1: Before you you start I would check out the WithinWindows article that goes into more details on how this option is configured at WithInWindows: Windows 7 to officially support logon ui background customization .

Essential we have to do three things; 1. create a local the folder for the background image; 2. copy the background image to the local folder and; 3. enable the registry key to show the background image.

Step 1. Edit a Group Policy Object that is applied to the machines that you want to make this change on. Then use the Folders Extension to create the path “%WindowsDir%\System32\oobe\info\backgrounds”.

Explanation: This is done to create the folders that we will place the Login background image as this is normally not created OOB.

Note: That even thought the “Info” folder is not explicitly created the fact that it is part of the path it will also implicitly be created.

Step 2. In the same Group Policy Object use the File Extension to copy a background image (e.g. backgroundDefault.jpg) to the path that was created above.

Note: In this example the source was “\\demodc01\Wallpaper\backgroundDefault.jpg” and the destination was “%WindowsDir%\System32\oobe\info\backgrounds\backgroundDefault.jpg”

Tip #2: As this policy is being run under the contest of the local System account you will need to make sure the location on the network where the file is being copied from has read access for the Domain Computers group.

Now we need to enable the “OEMBackground” registry key so that windows will use the wallpaper file we just copied over the to the computer (see details below).

OEMBackground

Key: HKLM\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background
Value: OEMBackground (REG_DWORD32)
Data: 0 (Standard Wallpaper only, Default)
Data: 1 (Custom Logon UI wallpaper enabled if possible)

Step 3: Again, in the same GPO we need to enable the Logon UI Wallpaper and create a new Registry Extension item.

Step 4 (Optional): Configured the Description.

Tip #3: This is not required but is always a good idea so that someone else looking at this policy can figured out what the policy does.

Tip #4: As this registry key already exists then I would NOT recommend using the

Done. Now when the user logs off or shutdown the computer they will have the new background image (see below).

What I really like about this method as opposed to doing it via a logon script is that the affect is immediate and if the user finds and changes the background image it will be reset back at the next policy refresh. This also means you can push out a new background image on a regular basis as all you have to do it update the source background image on the network and it will automatically propagate from there…

Tip #5: If the background image is not working then make sure the file is less that 250kb in size as this is a built in restriction presumably to prevent slow down in loading very large image files. To resize the image I use Paint .Net which is a free image editing app that allows you to configure the compression ratio on JPG files.

Tip #6: Remember that if you use only the “backgroundDefault.jpg” file then it will stretch and skew the photo to fit the resolution of the screen. See the WithInWindows article for the other files names that are used for specific screen resolutions/ratios.

Below is an example of the options you have to show the drive letters:

After (Default)	None
Mixed (Local After, Network Before)	Before

The registry key that you use to configure this option is called “ShowDriveLettersFirst” and it can be applied in either the user or the machine.

Note: According to this Microsoft KB Article KB330193 it will only work as a Machine setting in Windows Vista.

ShowDriveLettersFirst

Key (User): HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
Key (Machine): HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
Value: ShowDriveLettersFirst (REG_DWORD32)
Data: 0 (After)
Data: 1 (Mixed)
Data: 2 (None)
Data: 4 (Before)

Step 1. Edit a Group Policy Object that is targeted either to a user or a computer that you want to apply this setting.

Step 2. Create a New Registry Item using the above Registry details

Step 3. Click on the “Common” tab and tick “Remove” this item when it is no longer applied”. I would also put in a comment in the description field explaining the valid numbers and what they do for the setting so someone else looking at this policy know how to re-configure this option if needed.

Explanation: This will ensure the setting reverts to defaults if the computer no longer has this setting applied.

For more information on this registry key check out Microsoft KB330193 

Source GHacks: Windows Explorer: Display Drive Letters Before Drive Names (via LifeHacker: Show Drive Letters Before The Drive Name In Windows Explorer )

Mark Heitbrink (fellow Group Policy MVP) has published an article which explains why it does not work and explains briefly how to modify the XML file for Group Policy Preferences so it will apply setting to IE9.

Therefore taking Mark excellent information I have gone thought the process step by step below showing what I think is the easiest way to find and edit the XML file to enable GPP for IE9.

Step by Step enabling GPP for IE9

Step 1. Setup a IE8 Internet Explorer Extension setting that has the setting you want to apply to IE9. (e.g. Home Page)

Step 2. In the same Group Policy Object navigate to User Configuration > Policies > Windows Settings > Scripts (Logon/Logoff) and double click on the Logon (or logoff) option. Then click on the “Show Files” button.

Step 3. Click on “Users” in the Address bar.

Step 4. Then click on the “Preferences” and then “InternetSettings” folder and then right click on the “InternetSettings” file and click on “Edit”.

Now we are looking at the XML that is used to apply the Group Policy Preferences settings. This is where we need to change the version number to support IE9.

Tip: Enable “Word Wrap” in notepad to see the text on multiple lines.

Step 5. Change “max=9.0.0.0” to “9.1.0.0” (see below)
Before:

After:

Step 6. Save the file and you are done.

Now you can have the goodness of Group Policy Preferences with IE9, however as the article also said this is NOT supported so please test carefully.

What is also nice about this change is that it will be persistence, so if you make subsequent changes to the same setting you do not need to edit the XML again however you will need to make this change each time you make a new GPP IE Policy setting.

Source: Internet Explorer 9(IE9) Group Policy Preferences (GPP) (Via GPOGuy )

Method #1: Administrative Template “Desktop Wallpaper” Setting

The “Desktop Wallpaper” method is of course the most commonly used way for configuring the Wallpaper on a computer however as it seems with all things Group Policy using this setting comes with its own pro’s and con’s.

Pro’s

• Change is Restricted for the users
• Works on all versions of Windows

Con’s

• Limited targeting only based on standard Group Policy Object’s (OU,Security Filter,Site,WMI & Domain)

This setting can be found under User Configuration > Administrative Templates > Desktop > Desktop and is straight forward to configure as all you have to do is specify the explicit local path or a UNC to the image you want displayed as the desktop wallpaper (see below).

Behind the scenes all this setting is doing is configuring the REG_SZ “Wallpaper” and the REG_SZ “WallpaperStyle”  registry keys under the HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System  path.

TIP #1: If you are running Windows 7/Server 2008 R2 pre-Service Pack 1 you will need to install hotfix http://support.microsoft.com/kb/977944 for this setting to work.

TIP #2: If you are configuring this setting I recommend that you use the “Fill” Wallpaper Style as this will work best with most screen resolutions (especially on Windows 7).

TIP #3: If you configure this setting you will need to wait for the user to logoff the computer before the background is updated.

Method #2: Group Policy Preferences Registry Key Wallpaper Configuration

As I mention in Method #1 all the Administrative Template “Desktop Wallpaper” does is configure the HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System REG_SZ “Wallpaper” key. Therefore you can also use the Group Policy Preference Registry Extension option to also set the same key to give you some added benefits.

Pro’s

• Support advanced targeting option due to Group Policy Preferences Item-Level Targeting
• Change is Restricted or Unrestricted for the user

Con’s

• Must run Windows XP (or greater)
• Must have the Group Policy Client Side Extensions installed.

To configured the Desktop Wallpaper the same as the “Desktop Wallpaper” administrative template simply create two registry keys User Configuration > Preferences > Windows Settings > Registry (see below). Now depending on the registry key that you configure for this setting you can either have this as a restricted (a.k.a. locked) setting or an unrestricted setting that allows the users to make their own changes.

Restricted: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\Wallpaper

Unrestricted: HKCU\Control Panel\Desktop\Wallpaper

Restricted: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\WallpaperStyle

Unrestricted: HKCU\Control Panel\Desktop\WallpaperStyle

Tip #4: If you don’t configured the “WallpaperStyle” registry key then users will still be able to choose their own Wallpaper Style.

If you chose the restricted registry keys to configured the wallpaper then ensure you also select the “Replace” action and “Remove this item when it is no longer applied” common option is selected (see below). If you don’t do this you will find that your users will not be able to change their wallpaper even after the policy is removed as the policy registry key will not be removed.

If you chose to use the unrestricted registry key values then also make sure you chose the “Apply once and do not reapply” option. If you don’t do this the users wallpaper will be reset ever time they log off their computer as the key will be set back to the original value during each policy refresh.

Configuring the Desktop Wallpaper Storage Location

Now that you know the many options for configuring the Desktop Wallpaper via Group Policy the next thing you should consider is where is the wallpaper being stored. As you can seen in the screen shots of the administrative template Desktop Wallpaper that they use the example of a UNC path. But…

TIP #5: DONT EVER USE A UNC PATH FOR A DESKTOP WALLPAPER… EVER!!

Simple put using a UNC path puts a lot of stress on network as it has to download file every time the wallpaper is loaded. It also means that if the network path cannot be contacted when the user logs on all they will get is a black background wallpaper. This is particularly obvious when someone logs on with a laptop not connected LAN.

So the obviously question is how do you make sure that file that the desktop wallpaper uses is always available and easily accessible? Use a script and copy the file to the local hard drive. Sure… but http://ihatelogonscripts.com and the issue with using a script is that it will only run when the computer starts up or when the user logs on. Generally this would not be a problem and if you are smart enough to use a copy program like robocopy or other such program it wont stress your LAN as it will only copy the file once. But on the day that you change the desktop wallpaper ever computer and/or user will try to download the new wallpaper all at once.

The Answer? Use Group Policy Preferences File Extension and copy the file down to the local computer.

Using the Group Policy Preferences File Extension

Using the File Extension to copy the file to the local hard drive means the file will be copied to the local hard drive making obviously available at all times. However the File Extensions options also has the advantage of being able to updated the file during each group policy refresh. This way the computer gets the updated wallpaper without having to logoff or reboot the computer and you avoid slamming the network in the morning when all the computers turn on.

TIP #6: Setup the file copy as a computer setting so that it will update the files even when there is no user logged on.

TIP #7: If you follow Tip #6 then you need to make sure that the desktop wallpaper file has got “Domain Computers” Read permissions so the local system account has access to copy the file from the network.

So by now, hopefully you know how to set the desktop wallpaper and so you can ensure that the images you use for the wallpaper are always available that way you  can ensure that your users are always subjected to your corporate desktop wallpaper.

• Windows Firewall integration – During setup, Microsoft Security Essentials will now ask if you would like to turn the Windows Firewall on or off.
• Enhanced protection for web-based threats – Microsoft Security Essentials now integrates with Internet Explorer to provide protection against web-based threats.
• New protection engine – The updated anti-malware engine offers enhanced detection and cleanup capabilities with better performance.
• Network inspection system* – Protection against network-based exploits is now built in to Microsoft Security Essentials.

Therefore I have updated my previous post based Group Policy for Microsoft Security Essentials to support configuring the newly added features.

If you want more general info about MSE v2 see: Security Garden: Microsoft Security Essentials 2.0 Released

If you want to download it visit  http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e1605e70-9649-4a87-8532-33d813687a7f

Before I begin I should remind you that Microsoft only allows MSE to be used for free in small businesses with less that 10 seats (see here). But MSE does not natively support Group Policy and having to configured even 10 copies of Microsoft Security Essentials (MSE)  manually can be a pain. So the instructions below is simply a way to configure the registry keys of the application using the Group Policy Preferences Registry key setting.

Tip: If the below instructions to create the registry keys seems like to much work you will be glad to know that I have put a link at the bottom to an XML Group Policy Preferences Registry file. You can use this file to import the all the Policy Registry setting I talk about below automatically.

How to use Group Policy Preferences Registry key setting.

Before we begin we first need to know how to create a Group Policy Preferences Registry Key setting that we will use to control each of the registry keys we need to configured MSE. The following steps will need to be repeated for each registry key below.

Step 1. Edit a Group Policy Object that is applied to the computers you want this setting applied.

Step 2. Navigate to Computer Configuration > Preferences > Windows Settings > Registry

Step 3. In the Menu click on Action > New > Registry Item

Now you know how to configure a registry key setting using Group Policy Preferences you can create a new Registry Item for each registry key listed below.

Note: The Data values below that are highlighted in BOLD are the values you need to use to replication the examples shown.

How to configured Scheduled Scan using Group Policy for Microsoft Security Essentials

Now you need to create a registry few specific registry keys. In this example we are going to configured a Full Scheduled scan to run each day at 8am. We are also going to enable the option to check for an update before scanning and we are going to configure the scan to

Scheduled Day

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScheduleDay (REG_DWORD)
Data: 0 (Every Day)
Data: 1 (Sunday)
Data: 2 (Monday)
Data: 3 (Tuesday)
Data: 4 (Wednesday)
Data: 5 (Thursday)
Data: 6 (Friday)
Data: 7 (Saturday)

Scheduled Time

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScheduleTime (REG_DWORD)
Data: 0 (12am)
Data: 000001e0 (8am)

The data of this value represents the number of minutes from 12am in hex… therefore if you want 8am configured the data to “000001e0”

Full or Quick Scan

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScanParameters (REG_DWORD)
Data: 1 (Quick Scan)
Data: 2 (Full Scan)

Check for Update before scanning

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: CheckForSignaturesBeforeRunningScan (REG_DWORD)
Data: 0 (Disabled)
Data: 1 (Enabled)

Scan only when idle

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScanOnlyIfIdle (REG_DWORD)
Data: 0 (Scan when idle)
Data: 1 (Scan when active)

Limit CPU Usage

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: AvgCPULoadFactor (REG_DWORD)
Data (Decimal): 10 (10%)
Data (Decimal): 50 (20%)
Data (Decimal): 90 (90%)

Now all your computers will have the scheduled scan option configured as the following image below.

How to configure Real-Time Protection options using Group Policy for Microsoft Security Essentials

Below are the registry keys for configuring the “Rea-Time Scanning” settings for Microsoft Security Essentials.

Monitor file and program activity

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableIOAVProtection (REG_DWORD)
Data: 0 (Real-Time scan Enabled)
Data: 1 (Real-Time scan Disabled)

Scan all downloaded files and attachments

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableOnAccessProtection (REG_DWORD)
Data: 0 (Scan Enabled)
Data: 1 (Scan Disabled)

Scan all downloaded files and attachments

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableOnAccessProtection (REG_DWORD)
Data: 0 (Scan Enabled)
Data: 1 (Scan Disabled)

Disabled Real Time Monitoring

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableRealtimeMonitoring(REG_DWORD)
Data: 0 (Scan Enabled)
Data: 1 (Scan Disabled – but why would you want to disable it…?)

Disabled Intrusion Prevention System

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableIntrusionPreventionSystem(REG_DWORD)
Data: 0 (IPS Enabled)
Data: 1 (IPS Disabled)

Real Time File Scanning Direction

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableIntrusionPreventionSystem(REG_DWORD)
Data: 0 (Both)
Data: 1 (Incoming)
Data: 2 (Outgoing)

You real time protection should now be configured as shown below.

How to configure Advanced Real-Time Protection options using Group Policy for Microsoft Security Essentials

Below are the registry keys for configuring the “Advanced” settings for Microsoft Security Essentials.

Scan archive files

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: DisableArchiveScanning (REG_DWORD)
Data: 0 (Enable Archive Scanning)
Data: 1 (Disable Archive Scanning)

Scan Removable Drives

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: DisableRemovableDriveScanning (REG_DWORD)
Data: 0 (Scan Enabled)
Data: 1 (Scan Disabled)

Create a system restore point

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: DisableRestorePoint (REG_DWORD)
Data: 0 (Create Restore Point)
Data: 1 (Do not create Restore Point)

Remove Quarantine file after (x days):

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Quarantine
Value: PurgeItemsAfterDelay (REG_DWORD)
Data (Decimal): 30 (30 Days)

Importing Group Policy Preferences

For your convenience I have provided you a link to a XML Group Policy Preferences Registry file for all the above settings.

Or here http://www.grouppolicy.biz/wp-content/uploads/2010/MSE_Settings_2.xml if the link on the image above does not work.

Simply save the file to your desktop and then drag it into the empty pane on the right hand side, click “Yes” to confirm the import and you will have all the registry keys automatically created.

Previous to Windows 7 you had to specify the .cpl (e.g. timedate.cpl) file name of the control panel item you wanted to show or hide however this has changed in Windows 7 and you now need to use the Canonical Name when hiding or showing specific items.

Below I will explain the new way of configuring control panel items for Windows 7 and show you the affect that this has on the control panel.

Before you begin I recommend that you take a look at http://msdn.microsoft.com/en-us/library/ee330741(VS.85).aspx which lists all the Canonical names for the control panel items for Windows 7. You will need to know what CN of the item you want to restrict or allow.

Note: In this example we are only going to show the control panel items we want to see (white list) however if you use the Hide specified Control Panel items policy setting you can black list only the items you don’t want listed.

Step 1. Edit the Group Policy object that is applied to the users that you want to apply the Control Panel configuration.

Step 2. Navigate to User Configuration > Policies > Administrative Templates > Control Panel

Step 3. Double click on the Show only specified Control Panel items setting then check Enabled and then click then Show button.

Step 4. Now you have the Show Contents dialog box open  you need to visit the web site that list the names at Canonical Names of Control Panel Items and copy the Canonical name for the control panel item you want to display.

Paste the name into the value field enter the canonical name of the control panel item you want to show in the Value field and click OK.

You will now see that the only available control panel item is the Region and Language options (see below).

However this view is somewhat confusing for users as they can still click on the category but there are not items to display (see below).

To get around this problem also enable the Always open All Control Panel Items (a.k.a Force classic Control Panel) when opening Control Panel setting in the same GPO.

Note: This option is probably not needed if you used the Show only specified Control Panel setting instead.

Now when the users open control panel they will only see the specific control panel items you have allowed without the empty categories.

To log on to Windows by using the disabled local Administrator account, start Windows in Safe mode.

However this behaviour has change since Windows Vista (and 7) and now you are no longer able to logon to a computers local administrator account if it is disabled (see Built-in Administrator Account Disabled ).

On domain joined computers, the disabled built-in administrator account cannot logon in safe mode

This presents some challenges as IT administrator as sometime you still need to ability to logon to a computer using the local administrator. The most common scenario you need to do this is when you need to troubleshoot domain account issues (e.g. re-join the computer to the domain) when the AD computer account has been reset or deleted or the password has become out of sync and you get a workstation trust relationship issue (see below).

The problem is that the local administrator account is now disabled and due to the new behaviour of the account you can no longer log with it using safe mode.

The built-in administrator account is disabled by default in Windows Vista on new installations.

This of course makes it almost impossible to configure the computer into a workgroup so that it can then be re-added to the domain to fix the problem. Its even more difficult if you have BitLocker encryption enabled on your local hard drive.

It is possible that you could logon with a user with local administrator access using cached credentials however this is limited to the last 10 people that logged on (increasable to 50 if you change the CachedLogonsCount below registry key).

But even so, this would also mean you have to know the username and password of the account at the time they last logged onto the computer. This may be a bit hard to do as they may have changed their password a number of times since they logged on to that computer.

Unfortunately, it is also much more unlikely now that the normal local user of the computer has not been given local admin due to all the improvement with Windows 7 (e.g. UAC) that allows users to work with standard user permissions.

Now you might think the really obvious solution is to just enable the local administrator account and set a password in advanced using Group Policy Preferences (see below) so that you can use it when you need to however doing this has a few security issues.

However enabling the local administrator account means it can be used by anyone who knows the credentials and they could then use the account to remotely access any workstation on the network (not good). It also mean a normal user that knows the local admin credentials ( we would like to think they don’t but somehow they find out) could us them whenever they are presented with a specify credentials UAC prompt. So it’s pretty much a back door that anyone can use to get around the fact you spent all this time setting up their computers for them to not require local administrator access…

So to get around this issues you could just set the password on a regular basis using Group Policy Preference (see above image) however this also has a few problems as well… While setting the local administrator password is easy to do however it is stored in the SYSVOL as an encrypted string that is fairly easy to crack (see Passwords in Group Policy Preferences ).

A password in a preference item is stored in SYSVOL ….. it is not stored as clear text in the XML source code of the preference item. However, the password is not secured.

To help mitigate this I have also written an article that explain a way to more securely apply the new password to all the computers (see How to use Group Policy Preferences to change account Passwords ) but even if you did this on a regular basis you would still need to tell all the IT support staff what the new password is when you change the password and thus people quickly learn the local admin account credentials all over again…

Note: That all being said it is still a really good idea to set a password for the local administrator account as the default password is configured as blank.

The other solution you might think of is to boot the computer using a third-party tool that can reset and enable the local admin account (see http://www.bing.com/search?q=sethc.exe+%22windows+7%22+administrator+password&form=QBRE&qs=n&sk= ) however these tools don’t work if your local drive is encrypted with BitLocker nor are they supported from Microsoft (see Microsoft policy about lost or forgotten passwords ).

If you want help to break or to reset a password, you can locate and contact a third-party company for this help. You use such third-party products and services at your own risk.

So lets assume you have a computer that is no longer properly connected to the domain with a disabled local administrator account. The computers local system drive is BitLocker encrypted and and you don’t know the credentials of any other accounts that have previously logged on with local administrator permissions… What do you do?

So below I will show you how to enable the local administrator account so that you can at least still logon with the local administrator even if the account has been disabled…

How to enable a disabled local administrator account on a Windows 7 computer with BitLocker enabled

Before you begin you are going to at a minimum know the following information:

• The account name and password of the local administrator account.
• The BitLocker recovery key for the local system drive. (see instruction on how to get the key from here How to use Group Policy to save “BitLocker to Go” recovery keys in Active Directory – Part 1 )

Step 1. Boot the computer using the Windows 7 Installation media

Step 2. When prompted to “Install now” click the “Repair your computer” option at the bottom left.

Step 3 (optional). If your local computer hard drive is BitLocker is encrypted you will now be prompted to type in the recovery key (see below) and just follow the next couple of step that is appropriate for your situation.

Note: You may need to use the Recovery Key Identifier (e.g. A5103515) to find the correct encryption recovery key from Active Directory.

Note2: This step is only required if your local hard drive is encrypted using BitLocker drive encryption.

Step 4. After you have entered the correct recovery and unlocked the drive select the appropriate installation of Windows 7 that you wish to gain access to (You will probably only have one option to select).

Note: Remember the drive letter in the location column as you will need to use this later (Almost definitely going to be “(D:) Local Disk” ).

Step 5. From the System Recovery Options click on “Command Prompt”

Step 6. Now run “regedit” from the command prompt.

Step 7. Click on HKEY_USERS and then click on File > Load Hive

Step 8. Navigate to D:\Windows\System32\Config folder and select the SAM file then click Open

Note: The drive letter you use in the path above is the same as the the drive letter in the Location column in Step 4.

Step 9. Now type “SAM_TEMP” (or any value) in the Key Name text field and click OK

Step 10. Expand SAM_TEMP\SAM\Domains\Account\Users\000001F4 and double click on the “F” key.

Step 11. Change the value “11” in the first column, row 0038 to “10” and click OK

Before	After

Step 12. Click back on “SAM_TEMP” and then from the File > Unload Hive and Yes to confirm.

Step 13. Exit Regedit and close the Command Prompt and click Restart from the System Recovery Option menu

Done…

Summary

You will now be able to logon as the local administrator account by using the account name “.\administrator” and the password of the account (which you should already know). This will enable you to configure the computer into a workgroup and then re-join the computer account back into the domain but without having to resort to enabling a back door administrator account on the all the computers in your environment…

Now you might now be wondering what is the point of security is on Windows 7 (i.e. BitLocker and disabled local admin) if it is so easy to circumvent however you need to remember that for this process to work you still need to know the local administrator password and more importantly you will need to know the unique BitLocker recovery key… Obviously this makes it very important to have BitLocker drive encryption deployed otherwise it will make it very easy to break into pretty much any computer if you have physical access.

the best network software security measures can be rendered useless if you fail to physically protect your systems

I know this is not strictly a Group Policy topic however it is very closely related topic and one I feel that this is still well worth knowing for any IT administrator so you can configured a more secure environment…

Other References

How to configure Group Policy to use Data Recovery Agents with “Bitlocker to Go” drives – Part 2
How to use Group Policy to save “BitLocker to Go” recovery keys in Active Directory – Part 1

Windows Seven Forums: How to Enable the Built-in Administrator Account from WinRE

How to set a registry key using Group Policy Preferences

Before we begin I will show you how create the required registry keys using group policy preference. After this I will list the registry keys you need to use with the instruction below to configure automatic logon.

Step 1. Edit a Group Policy Object that is applied to the computers you want this setting applied.

WARNING: Make sure you have not applied this policy to any computers before you begin as this will obviously logon any computer that this policy is applied to automatically.

Step 2. Navigate to Computer Configuration > Preferences > Windows Settings > Registry

Step 3. In the Menu click on Action > New > Registry Item

Now you know how to configure a registry key setting using Group Policy Preferences you can create a new Registry Item for each registry key listed below.

How to configure Windows to automatically logon

Now we need to create the below registry keys to enable the automatic logon process.

Note: You will need to substitute you own specific values for all the text in italic below.

Enable AutoLogon

Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value: AutoAdminLogon (REG_SZ)
Data: 1 (Enabled)

Default Domain Name

Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value: DefaultDomainName (REG_SZ)
Data: DOMAINNAME

Default User Name

Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value: DefaultUserName (REG_SZ)
Data: USERNAME

Default Password

Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Value: DefaultPassword (REG_SZ)
Data: PASSWORD

You should now have 4 registry keys configured as the image below.

Warning: Be sure to also block the regedit tool on the user that logos onto this computer as anyone logged on the computer will be able to see the account password stored in the registry as clear text (see below).

Now when ever this computer is turned on it will start up and logon automatically with the credentials that you specified in the policy (see below).

Related Links

Creating a Steady State by Using Microsoft Technologies

Update: Microsoft have now updated their Microsoft Security Essentials web site to say small business can now “officially” use MSE.

Before we begin I want to be clear that MSE does NOT natively support group policy this is simply a way to configure the registry keys of the application using the Group Policy Preferences Registry key setting.

Note: If the below instructions to create the registry keys seems like to much work you will be glad to know that I have put a link at the bottom to an XML Group Policy Preferences Registry file. You can use this file to import the all the Policy Registry setting I talk about below automatically.

How to use Group Policy Preferences Registry key setting.

Before we begin we first need to know how to create a Group Policy Preferences Registry Key setting that we will use to control each of the registry keys we need to configured MSE. The following steps will need to be repeated for each registry key below.

Step 1. Edit a Group Policy Object that is applied to the computers you want this setting applied.

Step 2. Navigate to Computer Configuration > Preferences > Windows Settings > Registry

Step 3. In the Menu click on Action > New > Registry Item

Now you know how to configure a registry key setting using Group Policy Preferences you can create a new Registry Item for each registry key listed below.

Note: The Data values below that are highlighted in BOLD are the values you need to use to replication the examples shown.

How to configured Scheduled Scan using Group Policy for Microsoft Security Essentials

Now you need to create a registry few specific registry keys. In this example we are going to configured a Full Scheduled scan to run each day at 8am. We are also going to enable the option to check for an update before scanning and we are going to configure the scan to

Scheduled Day

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScheduleDay (REG_DWORD)
Data: 0 (Every Day)
Data: 1 (Sunday)
Data: 2 (Monday)
Data: 3 (Tuesday)
Data: 4 (Wednesday)
Data: 5 (Thursday)
Data: 6 (Friday)
Data: 7 (Saturday)

Scheduled Time

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScheduleTime (REG_DWORD)
Data: 0 (12am)
Data: 000001e0 (8am)

The data of this value represents the number of minutes from 12am in hex… therefore if you want 8am configured the data to “000001e0”

Full or Quick Scan

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScanParameters (REG_DWORD)
Data: 1 (Quick Scan)
Data: 2 (Full Scan)

Check for Update before scanning

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: CheckForSignaturesBeforeRunningScan (REG_DWORD)
Data: 0 (Disabled)
Data: 1 (Enabled)

Scan only when idle

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: ScanOnlyIfIdle (REG_DWORD)
Data: 0 (Scan when idle)
Data: 1 (Scan when active)

Now all your computers will have the scheduled scan option configured as the following image below.

How to configure Real-Time Protection options using Group Policy for Microsoft Security Essentials

Below are the registry keys for configuring the “Rea-Time Scanning” settings for Microsoft Security Essentials.

Monitor file and program activity

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableIOAVProtection (REG_DWORD)
Data: 0 (Real-Time scan Enabled)
Data: 1 (Real-Time scan Disabled)

Scan all downloaded files and attachments

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Real-Time Protection
Value: DisableOnAccessProtection (REG_DWORD)
Data: 0 (Scan Enabled)
Data: 1 (Scan Disabled)

You real time protection should now be configured as shown below.

How to configure Advanced Real-Time Protection options using Group Policy for Microsoft Security Essentials

Below are the registry keys for configuring the “Advanced” settings for Microsoft Security Essentials.

Scan archive files

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: DisableArchiveScanning (REG_DWORD)
Data: 0 (Enable Archive Scanning)
Data: 1 (Disable Archive Scanning)

Scan Removable Drives

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: DisableRemovableDriveScanning (REG_DWORD)
Data: 0 (Scan Enabled)
Data: 1 (Scan Disabled)

Create a system restore point

Key: HKLM\Software\Microsoft\Microsoft Antimalware\Scan
Value: DisableRestorePoint (REG_DWORD)
Data: 0 (Create Restore Point)
Data: 1 (Do not create Restore Point)

Importing Group Policy Preferences

For your convenience I have provided you a link to a XML Group Policy Preferences Registry file for all the above settings.

Simply save the file to your desktop and then drag it into the empty pane on the right hand side, click “Yes” to confirm the import and you will have all the registry keys automatically created.

The Add-QADPermission command can be used to add an DACL security descriptor permission to any AD object with a distinguished name such as users, computer or OU’s. Therefore you can use this to delegate permission to OU similarly to running a “Delegation of Control Wizard” in Active Directory Users and Computers console (see image below).

This wizard allows you to delegate some common tasks (see below) to your OU’s in you Active Directory however the permissions they apply are not straight forward simple permissions.

What I will show you how to do is how to perform some of the common delegation tasks that the “Delegation of Control Wizard” using a PowerShell command so you can automate the process for creating new OU’s in your environment. I know this is not strictly an Group Policy topic but it is one closely related and one I think many Group Policy admins will find useful.

The Command tasks I will show you are the one’s that I almost exclusively use when delegating permissions to Active Directory, they are:

• Create, delete and manage user accounts
  • and Groups
  • and Computers
• Reset user passwords and force password change at next logon
• Modify the membership of a group

Getting started – Installing the ActiveRoles Management Shell for Active Directory

The Add-QADPermission command is a third party PowerShell command so you will need to first download and install the new commands from the Quest site on the computer that you will be running the PowerShell commands. You can download the Quest ActiveRoles Management Shell for Active Directory from here http://www.quest.com/PowerShell/activeroles-server.aspx and then install the MSI file.

Installing ActiveRoles Management Shell for Active Directory

Step 1. After launching the MSI click “Next”

Step 2. Tick “I accept the terms in the Licence Agreement” and click “Next”

Step 2. 3lick “Next”

Step 4. Click “Next”

Note: By ticking the “Change PowerShell execution policy from ‘Restricted’ to ‘AllSigned’  you are relaxing the execution policy of PowerShell. However you will still need to turn this off entirely for the testing of your script.

Step 5. Click “Install”

Step 6. Click “Finish”

You have now successfully install the Quest ActiveRoles Management Shell for Active Directory. Now it is time to use the new PowerShell Command.

Running the add-QADPermission PowerShell command

Step 1. To run the add-QADPermissions PowerShell command click on the PowerShell shortcut (that blue one in the taskbar if you are running 2008/R2).

Step 2. Run the command the following command to load the Quest PowerShell commands.

Add-PSSnapin Quest.ActiveRoles.ADManagement

Step 3. To test that the new PSSnapin is loaded type “add-qadper” and then press the “Tab” key to complete the command.

This should auto-complete the command to “Add-QADPermission”

REMEMBER: Every time you launch a new PowerShell window you are going to need to run “Add-PSSnapin Quest.ActiveRoles.ADManagement” to load to load the Quest PowerShell Snapin’s otherwise you will see a message like the image below.

Now that we have verified that the new Quest AD PowerShell commands lets take a look at the command that will replicate some of the common tasks in the “Delegation of Control Wizard”. In our example environment that we have an AD with three top level OU’s called “People” “Groups” and “Workstations” (see below). These OU only contain the same type of objects that match the name of the OU (e.g. “People” contains User AD Objects) but it is possible to delegate all the permissions to the same single OU if it contains objects of multiple types (e.g. user,computers and groups).

Delegating Create, delete and manage user accounts permissions using add-QADPermission

To delegate the same permission as the “Create, delete, and mange user accounts” (effectively Full Control) option in the “Delegation of Control Wizard” (see below) you need to delegate two permissions to the OU.

1. Allow access to all the properties of the user objects
2. Create / Delete permission of the user object

The first command will delegate Allow access to all the properties to the group called “User Admins” to all User objects in the OU with the distinguished name of “OU=People,DC=Contoso,DC=Local”.

Add-QADPermission “OU=People,DC=Contoso,DC=Local” –Account “CONTOSO\User Admins” -Rights GenericAll -ApplyTo ChildObjects -ApplyToType User

The second command will delegate Create / Delete permission for the User objects to the same OU for the same group.

Add-QADPermission “OU=People,DC=Contoso,DC=Local” -Account “CONTOSO\User Admins” -Rights CreateChild,DeleteChild -ApplyTo All -ChildType User

Now we can check the security on the People OU in Active Directory Users and Computer to verify the permission has been added correctly.

Note: See how we have used the “-ApplyTo ChildObjects” parameter and the “ApplyTo All” to ensure that these permission will inherit to all objects in this OU and sub-OU’s.

If the OU that you want to give the same Full Control permission to a Computers or Groups AD Object type all you need to do is change the -ApplyToType and -ChildType parameter to “computer” or “group” (See examples below)

Example delegation Create, delete and manage (a.k.a. Full Control) Groups permissions using add-QADPermission

Add-QADPermission “OU=Workstations,DC=Contoso,DC=Local” –Account “CONTOSO\Workstations Admins” -Rights GenericAll -ApplyTo ChildObjects -ApplyToType Computer

Add-QADPermission “OU=Workstations,DC=Contoso,DC=Local” -Account “CONTOSO\Workstations Admins” -Rights CreateChild,DeleteChild -ApplyTo All -ChildType Computer

Example delegation Create, delete and manage (a.k.a. Full Control)  Computers permissions using add-QADPermission

Add-QADPermission “OU=Groups,DC=Contoso,DC=Local” –Account “CONTOSO\Groups Admins” -Rights GenericAll -ApplyTo ChildObjects -ApplyToType Group

Add-QADPermission “OU=Groups,DC=Contoso,DC=Local” -Account “CONTOSO\Groups Admins” -Rights CreateChild,DeleteChild -ApplyTo All -ChildType Group

Delegating Reset user passwords and force password change at next logon using add-QADPermission

To delegate the same permission as the “Reset user passwords and force password change at next logon” option in the “Delegation of Control Wizard” (see below) you again need to delegate two permissions to the OU.

1. Allow Read/Write to the Password Last Set Attribute
2. Allow access to the "User-Change-Password” Extended Right

In this example we are going to delegate Allow Read and Write permission to the Pwd-Last-Set Attribute to all User objects to the OU with the distinguished name of “OU=People,DC=Contoso,DC=Local” to the group called “User Operators”.

Add-QADPermission “OU=People,DC=Contoso,DC=Local” -Account “CONTOSO\User Operators” -Rights ReadProperty,WriteProperty -Property (‘PwdLastSet’) -ApplyTo ChildObjects -ApplyToType User

Now we are going to delegate permissions to the Extended Right User-Change-Password for the User objects to the same OU for the same group.

Add-QADPermission “OU=People,DC=Contoso,DC=Local” -Account “CONTOSO\User Operators” -ExtendedRight User-Change-Password -ApplyTo ChildObjects -ApplyToType User

Again check the security on the People OU in Active Directory Users and Computer to verify the permission has been added correctly.

Delegating Modify the membership of a group using add-QADPermission

To delegate the same permission as the “Modify the membership of a group” option in the “Delegation of Control Wizard” (see below) you only need to apply one command to delegate the appropriate permissions.

1. Allow access to the Read/Write Members property on the Group

In this example we are going to delegate Change group membership permissions on all the Group objects to the OU with the distinguished name of “OU=Groups,DC=Contoso,DC=Local” to the group called “Group Operators”

Add-QADPermission “OU=Groups,DC=Contoso,DC=Local” -Account “CONTOSO\Group Operators” -Rights ReadProperty,WriteProperty -Property (‘member’) -ApplyTo ChildObjects -ApplyToType Group

As always check the security on the People OU in Active Directory Users and Computer to verify the permission has been added correctly.

Summary

When used with the other out of the box AD PowerShell commands you should now be able to fully automate the creation AND delegation of permissions to a new OU structure for your environment.

References Sites

Below are some useful links to pages that show you how to use PowerShell when working with Active Directory.

• Automating Group Policy Management with Windows PowerShell
• PowerShell Get-ADUserGroupMembership
• Group Policy Team Blog: Group Policy & Scripting
• Group Policy Team Blog: PowerShell Script with GP cmdlets: Registry setting, Link
• TechNet: Active Directory Administration with Windows PowerShell
• MSDN Blog: Extending Active Directory Powershell
• The Experts Community: Delegating the PowerShell Way

Other AD Security Related Pages

• TechNet: Access control in Active Directory
• TechNet: Delegating administration
• TechNet: Delegate Control of an Organizational Unit

Microsoft has now released to the public (download it here) the newest version of Internet Explorer 9 Beta to the public. If you want to know more about the new features in IE9 then i recommend that you check out http://www.beautyoftheweb.com/ to see some of the fantastic stuff that this browser enables. If the new functionality alone is not enough to get you to use it is just remember that it is now a Fully Hardware accelerated which makes it much faster than any other browser on the market!!!

With any new version IE there comes new features and with new features comes new group policy settings so below I go through the new policy settings and how you can get started right now with managing IE9 using Group Policy.

To get started you will need to download and install IE9 on whatever computer you are using Group Policy Management Console (a.k.a. GPMC) to edit your Group Policy settings as with anything to do with Group Policy it is normally best to make changes from a systems that has the newest software on it in your organisation.

WARNING: This software is still Beta so you are strongly recommended to isolate any testing you do with IE9 and Group Policy from your production environment.

Internet Explorer 9 Administrative Template Group Policy Settings

There are only 8 new Admin Template group policy setting but remember that just like previous version most of the  other older IE policy settings will still apply to this newer of IE. Theses settings are of course not final and Microsoft could change or added/remove more setting before the product goes RTW.

As IE 9 only supports Windows Vista and Windows 7 you now only get ADMX files for the new policy settings which will automatically get placed into the C:\Windows\PolicyDefenitions folder on the computer you install IE9. Note: You will need to upload “inetres” the ADMX and ADML file to the if you are using a admin template central store. So once the new ADMX files are loaded you will be able to configured the new IE setting under Administrative Templates in the Group Policy Editor. Sweet!

To save you the time of trying to find where the new policy settings are yourself I have listed the 8 new Administrative Template settings with the location that they can be found so you can check them out yourself.

Disable add-on performance notification

Administrative Templates > Windows Components > Internet Explorer

Turn off Managing SmartScreen Filter

Administrative Templates > Windows Components > Internet Explorer

Allow Internet Explorer 8 Shutdown Behaviour

Administrative Templates > Windows Components > Internet Explorer

Automatically enable newly installed add-ons

Administrative Templates > Windows Components > Internet Explorer

Prevent Deleting Download History

Administrative Templates > Windows Components > Internet Explorer > Delete Browsing History

Enable WebM software (when available)

Administrative Templates > Windows Components > Internet Explorer > Advanced Settings > Multimedia

Prevent configuration of search from the Address bar

Administrative Templates > Windows Components > Internet Explorer > Advanced Settings > Searching

Install binaries signed by MD2 and MD4 signing technologies

Administrative Templates > Windows Components > Internet Explorer > Security Features > Binary Behaviour Security Restrictions

Internet Explorer 9 Internet Explorer Maintenance Group Policy

The other way you can configured IE9 with Group policy is by going to Windows Settings > Internet Explorer Maintenance section and as with previous version you can configure you IE setting (e.g. Home Page) or you can Import the current Program and/or Security using the Import Program Setting option.

Internet Explorer 9 Group Policy Preferences Group Policy

Umm… err… Unfortunately at this point in time there is no support for Group Policy Preferences with Interne Explorer 9. This may or may not change in the future but at least for now you can use Admin Templates and IE Maintenance mode to keep you going.

As the beta has only just been released then it is highly likely that there will be more information coming soon… If this does happen I will be sure to post a new article to keep you up to date.

The idea is simple… a user can logon to any computer in an organisations and have all their personal files and setting apply to that computer as it was the last time they used a computer. This is really a Win/Win for Users and IT Pros as for a user this is a big time saver as they no longer need to waste time setting up their drives, printers and other personal settings when they have to use another computers. IT Pro’s also benefit when there is an un-expected failure or loss of a computer then they don’t have to go through what could be a lengthily, costly and if not impossible, process of recovering the users data.

The video below is part 1 in a 3 part series that give an overview about how Roaming Profiles and Folder Redirection give you User State Virtualisation.

Now theoretically User State Virtualization can be totally done with just a Roaming Profile, however this quickly becomes impractical as users often store a LOT of data which can make users profile impossibly large. To get around this Microsoft users folder redirection to essentially redirect parts of a users profile to a file share on a server where it is centrally access whenever they logon to a computer.

Reference: Managing Roaming User Data Deployment Guide

Folder Redirection provides a way for administrators to divide user data from profile data. This division of user data decreases user logon times, and Windows downloads less data. Windows redirects the local folder to a central location, giving the user immediate access to their data when they save it, regardless of the computer they are using. This immediate access removes the need to update the user profile.

By redirecting these folders to a server they are only access when needed and therefore very large files do not slow down the profile update process. The obvious disadvantage of doing this is that when a user cannot access the redirected folders (e.g. disconnected laptop users) they lose access to these files. However this restriction is also mitigated by ensuring that the user has a cached copy of these redirected folders.

Below I am going to go through a number of tips and tricks to make sure you get the most out of a User State Virtualization setup in your environment and to ensure that you don’t fall into some configuration traps.

Before you begin I would also recommend that you read the following articles from Microsoft about User State Virtualization.

• Choosing an Appropriate User State Virtualization Solution
• Understanding User State Virtualization Improvements In Windows 7

Note: I am going to mainly focus on Windows Vista/7 setups however most of the setting/principals I do mention below will still apply to Windows XP.

Update: Here is a really good video from Darren Mar-Elia (Fellow Group Policy MVP) from TechEd North America 2011. This session is entitled Optimizing Group Policy in Virtual Desktop (VDI) Environments however much of it covers User State Virtualization.

Setting up Folder Redirections using Group Policy

Below I will show you how to setup folder redirection for you users profiles. It is very important that you realise the impact that redirection some of these folder can have as if users have many GB’s of music of videos on their local computers you could quickly find yourself running out of disk space on the server.

Setting up file server share for User State Virtualization

When setting up the file server you need to be sure that the permission on the folder are setup so that a user can create a new folder however you also need to ensure that they can only see their own files if they start to snoop about.

Below I will go though the setup of a folder to be used for folder redirection and the roaming profiles. Combining a users redirected folders and roaming profile path to the one spot on the network is far easier to manage as it consolidates all the users information in one locations.

Note: This consolidated storage of users information can only applies to Windows Vista/7 systems. Otherwise you will need to create a separate share for roaming profiles with offline caching disabled for Windows XP systems.

Step 1. Create a folder to be used as a root folder for all the users information (e.g. Users)

Step 2. Open the properties of the folder and then go to the Security tab and then click on the Advanced button.

Step 3. Now click on the “Change Permissions” button

Step 4. Un tick “Include inheritable permission form this object’s parent.

Step 5. Click the “Add” button

Explanation: We have now setup a folder with no inheritable file permissions from the parent. We do this so we can remove the Read permission from Users for all subfolders and files in a later step.

You should now see something like this below.

Step 6. Select the Users “Special” ACL and then click the Edit Button.

Step 7. Change the Apply to: permission to “This folder only” and press “OK”

Step 8. Select the Users “Read & execute” ACL and then click the “Edit” button.

Step 9. Again select the “This folder only” option from the Apply to: section and then press “OK”

Notice how the two “This folder only” permissions for Users have now combined into one ACL.

Step 10. Then press “OK” and “OK” to get you back to the Users Properties screen.

Now we need to share the folder…

Step 11. Click on the “Sharing Tab” on the Users Properties screen and then click on the “Advanced Sharing” button.

Step 12. Tick “Share this folder” and give the type in a share name ending with a $ (e.g. Users$) then click on the “Permissions” Button.

Note: The $ symbol at the end of the share name makes it hidden to a users so they cannot browser to the folder. This is not necessary but it is good practice to help stop nosey users.

Reference: http://blogs.technet.com/b/askds/archive/2008/06/30/automatic-creation-of-user-folders-for-home-roaming-profile-and-redirected-folders.aspx

you should always hide the profile share using a dollar sign ($).

Step 13. Tick “Allow” for the Full Control permissions (change should then get automatically ticked) and then press OK then OK then Close.

(Optional) Setting up Roaming Profile Folder

If you are still using Windows XP then I would recommend configuring the roaming profile folder is the same as the Users folder for the redirected folders except that you need to disable file caching. Simple repeat the steps above for “Setting up file server share for User State Virtualization” instead use the folder name called “Profiles” and a share name called “Profiles$”.

After you configure the share permissions (see step 13 above) also click on the “Caching” button and select the “No Files or programs from the share folder are available offline” options then press OK then OK then Close.

Reference: http://blogs.technet.com/b/askds/archive/2008/06/30/automatic-creation-of-user-folders-for-home-roaming-profile-and-redirected-folders.aspx

You should disable Offline Files

Enabling Access Based Enumeration

Now we are going to enable Access Based Enumeration for the Users$ share so that any users that manually goes to \\server04.contoso.local\users$ will only see their own folder. This is optional however as it simple stops your snooping users from seeing who else is in the organisation.

Reference: http://blogs.technet.com/b/askds/archive/2008/06/30/automatic-creation-of-user-folders-for-home-roaming-profile-and-redirected-folders.aspx

This last part is for the former Novell Admins out there. Yes, you could use Access Based Enumeration (ABE) on these new shares; however if there is going to a lot of user folders on any one of these shares you could experience degradation of performance. Enabling ABE on a share does come at a price of performance.

Step 1. Open Server Manager and expand Roles > File Services > Share and Storage Management and then highlight the Users$ share

Step 2. From the menu click on Action and then Properties and then click the “Advanced” button

Step 3: Tick “Enable access-based enumeration” and then click “OK”

Step 4. Click OK

The folder on your server is now ready for your users roaming profiles (Windows Vista/7) and folder redirections.

Tip: You can also also enable a File Screen using the File Server Resource Manager to prevent your users from saving files type of a certain extension (e.g. MP3, AVI or MP4) to their redirected folders. Another option this gives you is the ability to apply an Auto Apply Quota to the users folders and have then get warning email messages whenever they consumer a lot of disk space.

How to configured Roaming Profiles for a user using Group Policy

Before we begin, take the time to watch part 2 video that shows an example of how Roaming Profiles can be used to give your users a better experience. This video also demonstrates some of the pit falls with just implementing a roaming profile for a user without Folder Redirection enabled.

Per User Roaming Profile

You have always been able to configured a users roaming profile patch by configuring the Profile Path on the users account (see image below). This method allows you to granularly configure a users roaming profile path location however it is a lot more laborious process to ensure that they are consistent with the folder redirection policy that is also applied to the users.

Below is the view of a users roaming profile configured to \\server04.contoso.local\users$\%username%\profile . If you are a Windows XP user this will translate to \\server04.contoso.local\users$\sam\profile and if you are a Windows Vista/7 users this will translate to \\server04.contoso.local\users$\sam\profile.v2 .

Explanation: I have added “\profile” onto the end of what would normally be the profile path so that when the profile is created it is placed at the same level as all the other redirected folders. You will see how this works later on in this post.

Reference: http://blogs.technet.com/b/askds/archive/2008/06/30/automatic-creation-of-user-folders-for-home-roaming-profile-and-redirected-folders.aspx

You configure the profile location on the Profile or Terminal Services Profile tab within Active Directory Users and Computers.

If you setup the optional Profiles$ share for Windows XP then you will need to make sure the share you use is profiles$ (not users$) and there is no need for the additional \Profiles folder to be specified.

Once feature that was introduced in new version of Active Directory Users and Computer in Windows Server 2003 was the ability to update user attributes with multiple users in one action (see image below). This made the whole process of configuring the users profile patch much easier especially when dealing with many users accounts.

Per Computer Roaming Profile

Before Windows Vista the only way you could configure the roaming profiles path for a users was by configuring it on the users account via Active Directory Users and Computers. While configuring the roaming profile path on the users account is now far easier with the multiple user attribute update feature this still left the setting configured for each individual users and unless you do an audit of all the user account it is possible that some path’s could be setup incorrectly.

However in ever since Windows Vista there is now a group policy setting you can apply to computers that configured the roaming profile path for anyone who logs onto that computer called “Set roaming profile path for all users logging onto this computer”.

Warning: The biggest problem with the Per Computer roaming profile configuration is that there is no way to exclude you administrator accounts from also getting this policy as it is a per computer policy. This means if any administrator logs on to a workstation with this policy applied they will be configured to use a roaming profile.

Step 1. Edit a Group Policy object that is targeted to your workstations

Step 2. Navigate to Computer Configuration > Policies > Administrative Templates > System > User Profiles and enable the “Set roaming profile path for all users logging onto this computer” and configure the path to \\PROFILESERVERNAME\Users$\%username%\profile .

Explanation: I have added “\profile” onto the end of what would normally be the profile path so that when the profile is created it is placed at the same level as all the other redirected folders. You will see how this works later on in this post.

If you are still running Windows XP this policy works very well if you have used a geographical OU structure (see Best Practice: Active Directory Structure Guidelines – Part 1 ) for your workstations as you will be able to send the users  roaming profile path for each user  to a local file server. This would allow you to point users in the local site to the closest/quickest roaming profile server to reduce the time it takes to logon and logoff. However as Windows Vista and Windows 7 now uploads the profile asynchronously loading the profile via a higher latency lower bandwidth link is not so noticeable unless the users has never logged on to that computer before.

Which do I recommend?

Amazingly I am not going to recommend the per computer Group Policy method as there is no way you can get around not having a roaming profile if you logon as an administrator. This is a real show stoper as I think it is really bad for administrator accounts should not be encumbered with “crud” in their profile when logging onto a computer.

Therefore I recommend the per user roaming profile configuration method, which is made much easier to do with the multiple user attribute update option you get with the newer version of Active Directory Users and Computers.

Other Roaming Profile Group Policy settings

In this section I will go through (in no particular order) the Group Policy settings I recommend you configure for setting up roaming profiles.

Computer Configuration > Policies > Administrative Templates > System

• Verbose vs normal status messages

Reference: Managing Roaming User Data Deployment Guide

Windows Vista provides little information about the status of loading or unloading roaming profiles during user logon and logoff. This lack of information is misleading and may give a user the impression Windows Vista is unresponsive.

Computer Configuration > Policies > Administrative Templates > Systems > User Profiles

• Add the Administrator security group to roaming users profiles (HIGHLY RECOMMEND)
• Background upload of a roaming user profile’s registry file while user is logged on
• Delete use profiles older than a specified number of days on system restart

Users Configuration > Policies > Administrative Templates > Systems > User Profiles

• Do not check for users ownership of Roaming Profile Folders

Usefully if you are doing a cross domain/forest migration of user accounts. Also reduces logon issues caused by incorrectly set permissions on the folders.

• Limit profile size (NOT RECOMMENDED)

Reference: Managing Roaming User Data Deployment Guide

Vista still respects this policy setting; however, no longer prevents the user from logging off the computer. Windows does not synchronize the user’s profile to the profile server when it exceeds the policy enabled limit.

• Exclude directories in roaming profile

Handy to exclude applications that incorrectly write very large caches from the users Application Data folder if you do not have folder redirection enabled.

Trusted Sites

• As you are redirecting the Desktop and Start Menu to a network location you will need to add the file server into the trusted sites list otherwise Windows will warn you are trying to run a program form an un-trusted location (see below).

Tip: To avoid having to enter in the name of every file server in your organisation simple added the Domain name portion of the server name so that all servers will be Intranet Zone (e.g. file://*.contoso.local ). See my other blog post How to use Group Policy to configure Internet Explorer security zone sites on how to do this…

Error Message you will get if you do not add you file servers into the Intranet Zone.

Updates: Roaming Profile Improvement in Windows 7

Background Synchronisation

The most significant improvement to Roaming Profiles with Windows 7 is the introduction of a new feature called Background upload of a roaming user profile’s registry file while user is logged on this enables the IT administrator to schedule a background upload of the users NTUSER.dat file if they don’t log off their computer. Even if your users are in the habit of logging off at the end of the day this is a setting you should consider turning on to ensure that the users settings are always being backed up as failures can happen at any time.

How to configure Folder Redirection via Group Policy

Now lets take a look at how to setup folder redirection for a user so that the files stored in their personal folders (e.g. Documents, Music & Videos) are stored on the file server an not on the local computer. By default all folders that are redirected are automatically made available offline which is done so that users can still access their personal files if they are disconnected from the file server. On a Windows XP system this can add substantial time to the logon/logoff process as the user has to wait for the files to be synced however in Windows Vista/7 this is done in the background therefore it is a much more seamless process.

Part 3 of this video series also goes though an example that explains how Folder Redirection can help your roaming user access their files from various desktops and laptops.

Step 1. Edit a Group Policy Object that is targeted to your users and navigate to User Configuration > Policies > Windows Settings > Folder Redirection > Documents

Now we are going to setup folder redirections for the Documents (a.k.a. My Documents) folder as this is the most commonly redirected folder however you will need to repeat the same instructions for each of the other folders (if required).

Step 2. From the menu click on Action and then Properties

Step 3. Select the “Basic – Redirect everyone’s folder to the same location” option

For the purpose of this demo I am only going to show you how to setup a “Basic” redirection. However if you want to spread out the users amongst multiple locations you can use the advanced options and apply a different folder redirection based on the users security group membership (see image below). This option is useful if you want to distribute the load across multiple server but it can start to get complicated as the users roaming profile may then be stored in a different locations to their redirected folders. Also be careful with the order you apply these advanced settings as if the users is a member of multiple groups it will pick up the top entry in the list and there is no way to reorder the list after the entries are created. For these reasons unless you REALLY want to you should try and avoid using the Advanced option.

Advanced redirection (just for your FYI)

Step 4. Select the “Create a folder for each user under the root path” option under the “Target folder location” and then type the full UNC path in the root path that we created before (e.g. \\server04.contoso.local\users$ ) then click on the “Settings” Tab.

Step 5. Un tick “Grant the user exclusive rights to Documents”

Explanation: If leave “Grant the user exclusive rights to Documents” ticked then when the folder is initially setup Windows will block inheritance on the folder and grant exclusive access to the users on these files. This will lockout even administrators to the files which makes administration of these folders very difficult. If an administrator did need to access these files they will need to take ownership which in turn removes access from the users to their files. The admin will then need to ensure that they need to re-setup the permission on the folder to ensure that they users can still access the files….. very messy…  The only scenario I see you wanting to keep this ticked is if you have a VERY strict privacy policy in your organisation but as I said before its not as if a determined administrator cannot get access to these files if they really wanted to.

Reference: http://blogs.technet.com/b/askds/archive/2008/06/30/automatic-creation-of-user-folders-for-home-roaming-profile-and-redirected-folders.aspx

By default, Administrators do not have permissions to users’ redirected folders. If you require the ability to go into the users folders you will want to go to the “Settings” Tab, and uncheck: “Grant the user exclusive rights to” on each folder that is redirected. This allows Administrators to enter the users redirected folder locations without taking ownership of the folder and files.

Note: If this is also one of the support folder redirection types in Windows XP you will have the option to also apply this policy to Windows XP computers. I would strongly recommend that you think hard before ticking this option however as I am a strong believer in not crossing the streams when it comes to running dual SOE’s.

“Also apply…” option greyed out as its not a down level (a.k.a. Windows XP) supported setting.

Note2: The other option you may want to consider it the “Redirect the folder back to the local userprofile location when policy is removed”. What this means is that if a users is not longer subject to that Group Policy setting the the contents of the redirected folder are moved back to the local computer. This sounds good until this actually happens to a users and then it takes them about 2 hours to copy all their file down to the local computers. I recommend that you leave this at the default setting.

Step 6. As we did not tick the “Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP and Windows Server 2003 operating systems” setting… phew… then you will need to press the “Yes” button.

Now repeat the setups above to configured all the other redirected folders (as shown below).

Note: You will see on the Pictures, Music or Video options you will have the option to select the “Follow the Documents folder” option. However I have found that selecting this option can cause the Video and Music libraries in Windows 7 to disappear so i recommend that you do n so that they will automatically inherit the Documents settings.

Warning (Pre Windows 7): When enabling folder redirection for existing users for the first time expect the logon to be very slow. Not only are you copying the contents of all the user’s personal folders across the network to the server you are doing this for multiple users at the same time when the login. This means that it is highly likely that your file server will be the bottle neck. To mitigate this you might want to security filter the policy and only enable it for a few users at a time working you way up to all your users.

Folder Redirection Improvements in Windows 7

Fast First Logon

One of the new feature with Windows 7 is called Fast First Logon which allows users to logon to their computer without having to wait for the folder to be moved first. This means if your are enabling folder redirection for users already running Windows 7 the performance impact will be greatly reduced.

Reference: What’s New in Offline Files

the user must wait only for Windows to move the files into the local Offline Files cache. After the files are moved, the user logs on and is free to perform other tasks while Windows synchronizes the locally cached data over the network as a background task

Background Synchronisation

As all redirected folder are also made available offline it allows users to work on their files when in offline mode but still have them periodically sync in the background when connected via a low link. This is very useful for roaming users connected via a VPN or even when the file server might be experiencing heavy load.

Reference: What’s New in Folder Redirection and User Profiles

When the network connection is slow or unavailable, Offline Files routes requests for the user folders that are stored on the server to the local computer cache. Users read and write from their local cache. Offline Files synchronizes new and changed files and folders from the local computer cache to the server when the network becomes available or in the background when the connection is slow.

The difference between Local, LocalLow and Roaming Applications Data

One of the most confusing aspect of folder redirection is all the type of Application Data folders there are and what they do. Below is my attempt at trying to explain the difference between the Applications Data folders and how they will affect your computers.

Reference: Managing Roaming User Data Deployment Guide

Local and LocalLow folders for application data that does not roam with the user.

Local AppData & AppData

The “LocalAppData” and “AppData” folder’s for a user that does not have folder redirection enabled is one and the same and will be located at “C:\Users\USERNAME\AppData\Local”. The most commonly saved files in this path would be very large cache files that would be impractical to constantly send and receive across the network. As the files are only cache’s then there would be no issues if they were lost as they information would simple need to be re-cached. A good example of this is the TEMP and TMP path variable that is configured where most applications are configured to save temporary files.

That being said when folder redirection is enabled the “AppData” environment variable will point to the network path that it is configured in the Group Policy (see image below). This then splits you AppData folder into two locations with any application configured to use the “AppData” variable will be pointed the path on the network and any application that is configured to use the “LocalAppData” variable will still be pointed to the local hard drive.

Enabling folder redirection for AppData is far more practical to do with Windows Vista/7 than Windows XP as the offline file cache can seamless transition form offline to online mode if the network latency goes above a threshold.

Warning: If you are running Windows XP and the users is connected via a slow link then the affect of having this folder redirected could be devastating to the users performance. In my experience even the simple act of scrolling a word document requires constant writing to this “Local” application data folder.

To identify if a user has application data folder redirection enabled by simple running “set” from the command prompt and the look at the value of the  “APPDATA” variable (see image below). The below image also illustrates that the “LOCALAPPDATA” variable will always point to the local hard drive even when folder redirection is enabled.

LocalLow AppData

The “LocalLow” folder for all users is “C:\Users\USERNAME\AppData\LocalLow”.  This BIG difference of “Local” to “LocalLow” is that it is specifically intended as a place for “Low Integrity” applications to write files such as Internet Explorer add-on like Google Gears, Google Earth, Adobe Acrobat, Apple QuickTime and Microsoft Silverlight. It also appears that this folder is neither redirected nor part of the roaming profile therefore all information stored into this folder is local to the computer and will not roaming with the user.

Reference: The difference between Local and LocalLow Folders

Updated: Should you enabled Local AppData Folder Redirection?

Should AppData Local be redirected? No… Because you Can’t… Hence the name “LOCAL”. In Windows XP days a users would either have their AppData folder online or offline and not matter how slow your connection was to the server so long as your still got a response you would stay online thus bringing your entire computer to a grinding halt. But if the Administrator did not enable folder redirection for the users this normally resulted in them having a MASSIVE roaming profile that would take forever to sync during the logon and logoff process. The work around to this was to exclude the entire AppData folder from the roaming profile but this meant you risked losing some of the users personal data.

As Aaron mentioned in the comments the decision to enable Application Data folder redirection is one that should not be taken lightly and can have real negative consequences for the performance of your users. As I mentioned above having AppData folder redirection enabled to a location that is performing slow will have very noticeable performance impact for your users especially if you are running Windows XP. However not having AppData redirection could mean that you are likely to lose some of the users settings and data if their computer’s hard drive fails. A good article to read on the the matter is Should AppData be Redirected or Left in the User Profile? which discuses the Pro’s and Con’s of enabling AppData Redirection.

However now with Windows 7 (and to a lesser extent Vista) the decision to enable folder redirection for Local AppData is tricky at best. Not made any easier by Microsoft on one hand by providing a specific Roaming\AppData folder for persistent information but on the other making improvements to the OS that makes it a far more practical option to enable.

The new Windows 7 features called Transparent Caching and Background Sync for offline files the issues with redirecting the Local AppData folder are now largely mitigated as the users will automatically work on the local copy of the file whenever network performance is poor. Thus making it far more practical to enable Local AppData folder redirection while still not something that you really should do…

Updated: Roaming AppData

The “Roaming” AppData folder is located on the user local hard drive at “C:\Users\USERNAME\AppData\Roaming” this is the folder where applications should store all the users persistent information.

AppData\Roaming is part of the users roaming profile so when a user log’s off their computer the files are location are copied up to “\\PROFILESERVER\Users$\USERNAME\Profile.v2\AppData\Roaming”. Any well written application for Windows Vista or later should be aware of the Roaming Application Data folder and should use this folder to save persistent information. A good example of something that should be saved to this location is a users custom dictionary or a browsers internet cookies.

Reference Managing Roaming User Data Deployment Guide

Roaming folder for application specific data, such as custom dictionaries, which are machine independent and should roam with the user profile.

Below is a screen shot of a users AppData\Roaming folder as stored on the local computer and the same location stored on the server.

Note: Unlike the users Registry information in the ntuser.dat file on Windows 7 the AppData\Roaming folder cannot be synchronised using the Background upload of a roaming user profile’s registry file while user is logged on setting.

AppData\Roaming on the local computer	AppData\Roaming store on the Server

So Should you enable this “AppData(Roaming)” folder redirection option? Probably not…. Why? You should ensure that your computers it is always using the local HDD which should give MAXIMUM performance (unless you driver is REALLY slow). This with all the improvements in Roaming Profiles Syncing such as Background Synchronisation (See What’s New in Folder Redirection and User Profiles) then the user AppData(Roaming) will still be saved to the network to reduce chance of any data loss for the user.

Updates: Excluding AppData Folders

Some applications may not be well written (SHOCKER) and as such save a numerous or large files to this location to the AppData\Roaming folder. This significantly adds to the logon and logoff with all the extra it takes to transfer all the excess files. Therefore you should fully understand where applications save the applications specific configuration and look at excluding these folders from the users roaming profile so they are not copied up to the network thus saving a lot of time during logoff and logon.

For a good starting point of a list of common applications that save large amount of information into the AppData\Roaming folder check out Stealthpuppy: Reduce logon times by excluding the bloat .

User State Virtualization Folder Structure Explained

Now that we have configured the user roaming profile and folder redirections the next time a users logon they will automatically create the required folders on the network for them to enable User State Virtualization.

As you can see below in the image below a user personal folders are part of their roaming profile. The files in these folders (e.g. documents and music) are saved locally and are synchronised asynchronously in the background with the server. Having no folder redirection also means that a users will take some time to logon to a computer for the first time as you will need to download a copy of the entire profile.

User State Virtualization Folder Structure before Folder Redirection is Applied

After folder redirection is applied to the user you can see that all the user folders (excluding AppData) have been moved up a folder out of the profile and into the root folder for the users data.

User State Virtualization Folder Structure after Folder Redirection is Applied

Summary

Hopefully you now have a good idea as to how to setup User State Virtualization in your environment. Just remember that this is not a product but more a combination of roaming profiles and folder redirection to enable a users to use any computer in your organisation while maintaining a consistent experience.

The other part of User State Virtualization that I did not go into on this post was the ability to have all your users applications also follow them no matter which computer they are log into however to do this you need to use Microsoft App-V and for that i would refer you to Aaron Parker’s Stealthpuppy web site.

Other Resources

This is just a list of other related articles that I have found since writing this post.

• Best Practices for User Profiles (Windows XP)

Quite often disabling services on a computer is the best way to reduce the security surface of a computer or to improve performance by turning off un-used components of the OS. Inversely it is also very important to have the ability to turn on services to enable certain functionality or to ensure that certain services are not turned off.

Below I will go through the two ways you can control services in windows by using Group Policy each ways has its own advantages and/disadvantages but together you can pretty much control any system service the way you want.

In the examples below I am going to show you how to enable the “Applications Identification” service that is required to be enabled to make AppLocker work in Windows 7. If you want to learn more about AppLocker then check out my other post

Using Group Policy to configured a Service

Even since Group Policy was introduced to Windows 2000 you have been able to configured some aspects of services using native group policy.

Now that you can control service using Group Policy Preference there are only two reason that you will still want to use this method.

1. You want to control services on Windows 2000 or a computer that does not have the client side extensions installed.
2. You want to configure the security so that non-administrators can start,stop and pause the service.

Step 1. Edit a computer Group Policy Object that is targeted at the computer that you want to configure

Step 2. Select the services that you want to configure.

Note: If the service that you want to configure is not present in the list you will need to install GPMC on a computer that has the service running. This is a painful restriction of controlling services this way and

Step 3. From the menu click on Action > Properties then tick “Define this policy setting” and then configured the service startup mode to what you want it configured.

Step 4. If you click on the “Edit Security…” button you can also configured who has control over the service. This would be useful if you want to give end users the ability to start and stop specific services. Tip: Tick “Start, stop and pause” for INTERACTIVE if you want the logged on user to control the services.

Now that you have configured the services via group policy you will need to reboot the computer for the new startup mode to take affect. This means if you are disabling a service then it will not stop until your next reboot which could be may days, weeks or even months after you made the policy change.

Using Group Policy Preferences to configure a Service

The newer and almost always better way to configure service now is to you the Group Policy Preference Services options. As opposed to the native method which only allowed you to control the startup and security of service, preference now allows you much greater control.

The only reasons you would not want to use Group Policy Preference to control services are:

1. You need to configured the startup mode of a service on a computer running Windows 2000 or one that is not running the client side extensions.
2. You want to be able to configured the security to allow non-admin to start, stop or pause the service.

Always remember that when you do configure a service startup mode using the native method that this will take precedence over Group Policy Preferences and you can use the security options in conjunction with preferences.

Step 1. Edit a computer Group Policy Object that is targeted to the computers that you want to control the service.

Step 2. Navigate to Computer Configuration > Preferences > Control Panel Settings > Services

Step 3. In the menu click on Action > New > Service and now click on the “…” button next to the Service Name field.

Note: From here you can either type in the service name in the “Service Name” field or click on the “…” button to chose the service from a predefined list of services.

Step 4. Select the service name that you want to configured and then click “Select”

Step 5. Now you can configure the Startup mode from the Startup mode drop down box and you can configure a service action.

Service Action will take place each time there is a group policy refresh so that you do not need to wait for the computer to reboot for the latest startup mode to take affect. This can also be handy to configure if you want a service to start if it crashes or if you have a pesky service that requires restarting on a regular basis to keep running properly.

Step 6. Click on the “Recovery” tab to configure the recovery options of the service as you would configure in the service control panel.

Step 7. As this is a preference you can also configure the standard “Common” options from such as item level targeting which will allow you to granularly control what computer you target this setting.

As you can see with the combination of Group Policy Preferences and the native policies there is nothing you cant configure to your system services… Enjoy

There is currently a Microsoft Security Advisory KB2286198 out that affects all copies of Windows about a security issues with displaying icons on shortcuts via non-local drives (e.g. Removable, Network and WebDav folders). The security advisory lists the workaround to the issues that effectively disables displaying all shortcuts. While this is not exactly a prettiest workaround (see image below) it does prevent you from being vulnerable to the security exploit.

There is a Microsoft Fix It for the issues if you just want to apply this workaround to a handful of computers but below I will show how you can apply the same workaround to all your domain computers using Group Policy.

KB2286198 Workaround via Group Policy Instructions

First we are going to create a policy that we can use at a later stage to restore the icon handler. The value that we are

Step 1. Edit a Group Policy Object that applies to all the computers you want to apply the workaround

Step 2. Navigate to Computer Configuration > Preferences > Windows Settings > Registry and in the menu click on Action > New > Registry Item

Step 4. Change the Hive to “HKEY_CLASSES_ROOT” then type “lnkfile\shellex\IconHandler” in the Key Path then tick Default and type “{00021401-0000-0000-C000-000000000046}” in the “Value Data” field and then click OK

We now want to disable this entry as we are going to use to to restore the Icon Handler once you the patch for this issue is out.

Step 5. Click on the IconHandler item in the right hand column and then click  “Disable this item” (Red Circle) in the toolbar.

Now we create the entry that disables the Icon Handler…

Step 6. Right click on the IconHandler registry item you just created and click “Copy”

Step 7. Right click somewhere in the blank in the right column and click “Paste”

Step 8. Click Yes

Step 9. Click on the second IconHandler registry item and click “Enable this item” (Green Circle) in the toolbar.

Step 10. Double click on the second IconHandler registry item and clear the “Value Data” field then click Ok.

Step 11. Now select and copy both IconHandler 1 & 2 and paste them again into a blank area (see step 6,7 & 8).

Step 12. Double click on IconHandler 3 & 4 and change the “lnkfile” in the Key Path to “piffile” (should now look like below image).

Now we are going to disable the WebClient Service that is the second part of this workaround…

Step 13. In the same GPO navigate to Computer Configuration > Preferences > Control Panel Settings > Services and in the menu Action > New > Service

Step 14. Change the Startup value to “Disabled” and type “WebClient” in the Service Name text field then change the Service Action to “Stop Service” and click OK.

Done…

The workaround will now push out to all you workstations and become affective on the next reboot (see image below).

Removing the KB2286198 Workaround via Group Policy

Step 1. In the GPO you set this up in navigate back to Computer Configuration > Preferences > Windows Settings > Registry and delete enabled registry entries (probably the second and fourth) and then click on the remaining two registry entries and click on Enable this item in the toolbar (see image below).

Step 2. In the same GPO navigate to Computer Configuration > Preferences > Control Panel Settings > Services and double click on the WebClient service item and change the Startup to “Manual" and the Service Action to “No change” then click OK.

Hopefully this will keep you secure until Microsoft release a patch for this security issue. As always implement these fixes at your own risk and I make no guarantees that these workaround will necessarily work in your environment.

Further References

• http://securitygarden.blogspot.com/2010/07/fix-it-released-for-security-advisory.html
• http://securitygarden.blogspot.com/2010/08/critical-out-of-band-update-released.html
• http://support.microsoft.com/kb/2286198
• http://www.microsoft.com/technet/security/advisory/2286198.mspx
• http://www.microsoft.com/technet/security/bulletin/ms10-046.mspx

Ideally you should make the the Active Directory OU and GPO design decision together to best ensure that you have the most efficient design possible. However if you have an existing OU structure designed a lot of these guidelines can still be applied to most existing environments.

As in Part 1 these are simply guidelines that I use and should not be taken as hard an fast rules. I quite often finding myself having to break these rules due to real world conflicts or just because one rule might conflict with the other rule. If you do find your self in a situation where you are not sure which path to take try to chose the option that will result in the least administrative effort in the long term.

Active Directory Group Policy Design Guidelines

Keep the GPO’s name consistent with the OU names

When naming the GPO try to keep the name of the policy the same as the concatenated name of all the OU’s to where the group policy object is applied. Having the fully concatenated name will make it intently know what that policy is applied when just looking at the GPO name. This is very handy to know when looking at a Group Policy Results report which only gives you the name of the GPO without the linked OU details.

Bad Example “Workstations”	Good Example “Sydney Workstations”

In keeping with having names consistent this also means you should adhere to the same naming conventions as mentioned in Part 1 with the OU’s (i.e. “Keep it short”, “Be Intuitive” & “Most to least signification from left to right”… So in saying that please read the next guideline…

References

TechNet: Establishing Group Policy Operational Guidelines

Define a meaningful naming convention for GPOs that clearly identifies the purpose of each GPO

Don’t use the work “POLICY”  or “GPO” in the GPO name

Nothing annoys me more to see a group policy called “Workstations Policy” or “Workstation GPO”…. I KNOW ITS A POLICY!!!! I AM LOOKING AT IT IN THE GROUP POLICY MANAGEMENT CONSOLE. Please drop the work “policy” or “GPO” from the name of the Group Policy object as you are simple adding more characters to what might already be a long name only for the sake of pointing out the obvious.

I also realise that the two GPO’s that come with AD are called “Default Domain Policy” and “Default Domain Controller Policy” which goes against this rule…

Remember at the start of part 1 how rules were meant to be broken…  So I do NOT recommend that you rename these polices there is just to much risk and confusion that doing this might cause. But this would have to be the only exception to this rule that I would be happy to let though…

Treat your terminal servers like workstations

Terminal Servers (now known as Remote Desktop Services) are essentially a multi-user workstation and as such should be treated more as a workstation than a server. Ideally you should configure you Terminal Server to be as close as possible as your workstations to provide your users with a consistent experience. The best way to make sure the configuration is consistent is to apply the same policy settings to the Terminal Serves as your workstations.

That being said don’t apply the same computer Group Policy Object to the Terminal Servers if for no other reason than it helps reduce the risk of making a change to a workstation that could affect the stability of the servers (e.g. Automatic Update reboot schedule). Therefore you will need to maintain some level of manually synchronisation between you default workstation and terminal server policy.

Unlike computer GPO’s it far more acceptable to apply the same user GPO’s to your users when logging on to the Terminal Server as the GPO are applied to the User Object rather than the computer account. Using the same policy means that any changes made to the user policies will automatically apply to terminal servers without the administrative overhead of making duplicate updates when there are policy changes. If you have any user configuration that you want to configure that is specific to the terminal servers (e.g. disable adding PST file) then you can override this policy using the Group Policy Loopback option on the computer GPO you apply to the Terminal Server. This is another  reason why you would want to have a separate computer GPO as it allow you to apply specific Terminal Server user settings via a loopback policy.

For more information on troubleshooting Loop back policies check out Loopback Policy Processing Debug Series  | CB5 Blog and Aaron Parker’s StealthPuppy blog.

Reference

TechNet: Using Loopback Processing to Configure User Settings

The User Group Policyloopback processing mode policy setting is an advanced option that is intended to keep the configuration of the computer the same regardless of who logs on. This option is appropriate in certain closely managed environments, such as servers, terminal servers, classrooms, public kiosks, and reception areas.

New GPO’s only when scope is different

I have seen some organisations apply many Group Policy Objects (GPO’s) to the same OU. There are a number of reason why you might want to do this however you should really consider why you want spawn another GPO as each one will add about 5mb to you Active Directory SYSVOL. But if you start creating lots of GPO objects then you can quickly blow out your the size and performance of your SYSVOL. This is not such a problem if you have upgraded to a DFS-R SYSVOL replication or you have configured a Group Policy Central Store for your Windows Vista and later computers but its still good practice to keep the number of GPO’s as low as possible.

Monolithic vs. Functional GPOs

Now that I have just told you that you should load up your GPO’s with lots of setting rather than having lots and lots of separate GPO’s Mike Kline has referred  me to the this great article Best Practice for Optimizing Group Policy Performance by Darren Mar-Elia that talks about Monolithic vs. Functional GPOs.

The terms “monolithic” and “functional” refer to how you design them. Monolithic GPOs contain settings from many different areas. For example, a monolithic GPO might contain settings from Administrative Templates, Internet Explorer Maintenance, and Software Installation policies—all within a single GPO. By contrast, functional GPOs typically do one thing. For example, a functional GPO may do only Software Installation or enforce Security settings.

I totally agree with this and my advice to you when trying to decide which to use that your should pick the type of policy configuration that suites your needs.

This also maps very nicely to the 80/20 examples you will see below where you take a more Monolithic approach to the 80% GPO’s and more Functional to the 20%. The 80% policies are going to have more setting in them but they will be relatively static where the 20% policies will have fewer settings but probably need to be updated more frequently. This way you should be able to balance the pro’s and con’s of each policy type in your environment.

References

TechNet: Complying with Service Level Agreements

If you have large or complex GPOs that require frequent changes, consider creating a new GPO that contains only the sections that you update regularly.

Setting (not policies) = Slower SOE

It is often a misconception that splitting up your group policy setting into a lot of Group Policy Objects (GPO’s) will slow down Group Policy on your computers. While this might be true if you have many 100’s (or thousands) of GPO’s applied to your computer this is not normally the reason why computer may slow down processing Group Policies. Normally you will find that its the number of settings you have applied that will cause performance issues and even then you will find that particular setting that will cause more of a performance hit than other. In my experience the policy setting that cause the most likely affect performance are:

1. Printer Mappings (100+)
2. Folder Redirection (Especially with Windows XP and AppData Redirection)

You should also expect that the first time a users logs on with a new account that they should expect a slow logon as the computer will need to apply all policy setting. However subsequent logon’s should be much faster as the computer is then only checking the policy is still applied. This is similar to the difference between running a “GPUPDATE” and a “GPUPDATE /FORCE” .

You should also check out the Best Practice for Optimizing Group Policy Performance post by Darren Mar-Elia as this post explains in detail how GPO are applied and what you can do to tweak performance.

While it would be fairly rare to have an environment that has more than a 999 GPO’s applied to a single computer still be aware there is a hard limit on the number of GPO’s you can apply to any user or computer. Thus trying to keep the number GPO’s to a as few as possible is a good idea especially in very large organisations that may uses separate GPO’s for installing software packages.

Reference

TechNet: Determining the Number of Group Policy Objects

Note that a maximum of 999 GPOs is supported for processing GPOs on any one user or computer. If you exceed the maximum, no GPOs will be processed.

Disable User/Computer settings if not in use

If you are creating a GPO that is only meant to be applied to computers (and vice versa for users) then you should disable the unused portion of the GPO. This not only helps guards against accidental change to the section of the GPO that should not be applied it should also give you a small performance boost processing policies on your computers as the GPO does not un-necessarily evaluate parts of the policy that are not configured with any settings.

While I have never seen a performance benefit in disabling the unused portion of a GPO or based on the number of GPO’s applied to a computers (see “Settings (not polices) = Slower SOE)” section above) I do encourage that you adhere to these principals to avoid Death of a thousand cuts when it comes to the performance of your systems.

TechNet: Complying with Service Level Agreements

If a GPO contains only computer or user settings, disable the portion of the policy that does not apply. The destination computer does not scan the portions of a GPO that you disable, which reduces processing time

Avoid using Enforced

In all my time as an Group Policy Administrator I cannot real once a scenario that I required the use of the Enforced feature of Group Policy. At all cost you should avoid this setting as doing so is like using big hammer to a problem that you can probably avoid if designed right.

(RESIST THE URGE)

References

TechNet: Designing Your Group Policy Model

Use the Enforced and Block Policy Inheritance features sparingly. Routine use of these features can make it difficult to troubleshoot policy because it is not immediately clear to administrators of other GPOs why certain settings do or do not apply

Reuse GPO’s where possible

If you are in a situation that you want have the same settings you want to apply to all the users or computers in specific OU’s your organisation then consider linking the same GPO to these OU’s. When naming the GPO chose a name that represents what is common  to what you are applying. This is shown in the image below (and in “80/16/4 Example 2”) where the policy is named “People Manufacturing” as this is the common two values to where to policy is being applied.

The means the “Sydney” and “Coolangatta” is ignored as that would result in a long policy name of “People Sydney and Coolangatta” Manufacturing”. It would be obviously longer again if you had the policy linked to many more sites.

If you have Software Assurance use the Advance Group Policy Management (AGPM) tool

Advanced Group Policy Management (a.k.a. AGPM) is a tool that is available to anyone who is licensed to have Software Assurance. This programs is a change management tool that allows you to check-in and check-out GPO as well as create a list of changes and an audit trail of change to GPO’s. You can check out my AGPM install and configuration series at AGPM Part 1: Introduction to Advanced Group Policy Management (a.k.a AGPM) v4. If you have a Group Policy infrastructure of any size or if you have more than one person who is responsible for making changes to GPO’s then this is definitely something you should consider.

AGPM is also very good at avoiding GPO editing conflicts as you will find that the “last writer will win” when making policy changes. This means that in an environment that has multiple GPO admins you might find that you could be overwriting each other changes with un-expected results. AGPM gets around this issues as it support the method of checking in and out GPO’s for editing meaning that now two GPO administrators can edit a GPO at the same time thus eliminating the possibility of overwriting each other changes.

For even more information on AGPM check out the following links:

Microsoft MDOP Blog
TechNet: Overview of Advanced Group Policy Management
TechNet: A Video tour of Advanced Group Policy Management
TechNet: Technical Overview of AGPM
TechNet: What’s New in AGPM
TechNet: Choosing Which Version of AGPM to Install
TechNet: Step-by-Step Guide for Microsoft Advanced Group Policy Management 4.0
TechNet: Operation Guide for Microsoft Advanced Group Policy Management 4.0
Group Policy Blog: Importing and Exporting with AGPM

Create a Test Group Policy Structure

Implement something like AGPM is an excellent way to make sure you have a proper rollback strategy for making changes to Group Policy but sometimes you just want somewhere to test the policy functionality before you put it into production. I would definitely recommend having an isolated replica of the AD structure in for making test however the problem with these environment is that they are normally not a 100% representation of the production environment.

Therefore as a second step in your testing of policy changes before being applied to productions systems you should create a test GP structure that will allow have a selection of users and computers that are in production but are not mission critical. Best to select users that you know are easy to get along with and wont scream to loud when you break something. You can even apply your own computer and users account to this test GP structure but make sure that this is not your only account as you want your computer to still be able to work so you can undo your changes in case you royally stuff something up.

OU Method

The image below shows how you could implement a Test OU/GP structure however by creating a separate OU structure to test your group policy. This method provides excellent isolation of your test computers and users to production which may be desired if you want to lessen the impact of any bad configuration changes. However this would mean that you would have the overhead of needing to ensure that all configuration changes to the production GPO’s are also replicated to these. Otherwise you may end up with your test environment being configured differently to your production GPO.

Security Group Filtered Method

The Security Group Filtered method applies the test GPO’s to the existing OU structure but they are security filtered so they will only apply to the users or computers you want to test. The test GPO will only have the delta configuration changes applied to it for the policy setting that you are testing therefore all other production policies will be implicitly applied to the test objects. Therefore you test computers and users are as close as possible representation of production because they are subject to the production policies. This also mean you do not need to make duplication configuration changes to the GPO’s when you do make production changes as the test computers will automatically have the production policies applied. The down side to this method is that unless you are carful in how you apply your security filtering you may inadvertently apply the test changes to your computers users and computers as they are all under the same scope of the test GPO. Another disadvantage of this method is that as you are relying upon security groups to apply the users or computer to the test policy it is possible that you could be a member of multiple test groups and thus be subject to multiple conflicting test GPO’s which may make the results somewhat unpredictable.

When not testing GPO changes the Test GPO’s should remain configured without any settings and/or the link to the OU should be disable to avoided any extra policy processing overhead to the production users and computers.

Hybrid Method

This method combines both a separate OU structure and separate GPO’s but avoids having to use security group filtering. The advantage of this method is that you test environment is still subject to the production GPO’s however the test policies are only applied to the users and computers that are located in the Test OU structure. This method totally mitigates accidently applying a test configuration to your production computers and it also eliminates the need to duplicate configuration changes to your production environment.

Reference

TechNet: Establishing Group Policy Operational Guidelines

Always stage Group Policy deployments using the following pre-deployment process

TechNet: Designing Your Group Policy Model

Prepare a staging environment to test your Group Policy-based management strategy before deploying GPOs into your production environment.

TechNet: Deploying Group Policy

Always fully test your GPOs in safe (nonproduction) environments prior to production deployment

Backup Often

Especially if you don’t have something like AGPM installed in your environment you should seriously consider making a PowerShell script that simple backs up all your new GPO’s in your Active Directory every night. Having back up copies of you GPO is very handy especially if you have miss-configured something and you quickly want to rollback to last known good policy setting. For more information on how to do this with PowerShell visit  PowerShell Script: Backup all GPOs that have been modified this month from the Group Policy Team Blog.

References

TechNet: Defining Group Policy Operational Procedures

You should also create regular backups of your GPOs

Edit Default Domain Policies Sparingly

Unless you are changing the default domain password policy then it is strongly recommended that you do not modify the Default Domain or Default Domain Controller group policy objects as making a mistake in these two policies up can really mess up your Active Directory. If you want to make a change to all your DC or your entire domain then consider making a separate new group policy at the same level as the default policies. This will at least allow you to un-do any change selectively disabling the offending policies if something does go wrong.

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. In general, do not modify this or the Default Domain Controller Policy GPO. If you do, be sure to back up these and any other GPOs in your network by using GPMC to ensure you can restore them.

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.

Update: Here is another post I have found that confirms this http://jorgequestforknowledge.wordpress.com/2011/10/23/best-practices-for-the-default-domain-policy-and-the-default-domain-controllers-policy-gpos/

Avoid using Group Policy Software Assignment

I know it sounds strange for a Group Policy expert to say avoid using Group Policy but this is definite one case where you should consider using other software deployment products due to their vastly superior features.

Group Policy Software Installations (a.k.a. GPSI) is a way you can deploy an MSI based application to your computers using Group Policy. This can be very useful way of deploying a standard set of applications to your computers however when compared to the advanced targeting features of SCCM software deployment or App-V this limitations of this method of software deployment quickly becomes evident.

One common problem I see when deploying software this way is the “Un-install when falls out of scope” options. This can be very handy when you want to move a computer to another OU and you want all the software packages that are not needed any more to un-install. This is even worse when you try to move an computer between domains as the computer will then un-install and re-install all the applications assigned to it which can take a VERY LONG time. Even when you have the “Un-install when falls out of scope” not ticked on the source domain and you move the computer to a new domain you will find that the installer service will still need to do a repair/check install of all the applications of the new domain even if the applications are already installed. However this also means that when the computer is removed from a domain then you have to wait for all the application’s to un-install during the next reboot. The un-installing of application can obviously take a long time if you have many applications install via this method. If you don’t select this options then you will find that your computer will over time build up the a number of installed applications installed on your computers that will affect performance, stability and licensing costs. The other inflexibility of doing software assignment to the computers via GPSI is that they will only install on the next reboot of the computer. Meaning that a user will need to do a full reboot of their computer before they will be able to start using the new applications.

The other restriction of GPSI is that you are limited to deploying only Microsoft Software Install (a.k.a. MSI) packages. Where tools like SCCM and App-V will allow you to deploy application via a silent command line option or via a sequenced application.

So due to all these targeting issues with GPSI software then I strongly recommend that you consider using either Microsoft SCCM package deployment or Microsoft App-V due to the superior targeting and features these products offer. For more information on the advantages of Microsoft App-V then i strongly recommend that you checkout the series of App-V FAQ at http://blog.stealthpuppy.com/tag/appvfaq .

References

Office 2007 Deployment via Group Policy

Office 2007 is no longer deployed using transform files

Below are the only scenarios that should be used when deploying Office 2007 via GPSI. While this article is specific to Office 2007 I would also say that the same limitations should be used when considering GPSI for other applications as well.

TechNet: Use Group Policy Software Installation to deploy the 2007 Office system

You can use the Software Installation extension of Group Policy to deploy the 2007 Office system to computers if the following conditions exist:

• Small organizations that have already deployed and configured Active Directory
• Organizations or departments that comprise a single geographic area
• Organizations with consistent hardware and software configurations on both clients and servers

Never edit Group Policy Objects from the Domain Controller

To often I see people editing their GPO’s directly from a Domain Controller in their organisation as they are not aware they can do this remotely. The Remote Server Admins Tools (a.k.a. RSAT) have will give you the option to install (See instructions here) the Group Policy Management Console on any workstation or server running Vista/2008 or greater. I strongly encourage you to do this as if you are performance day to day management of your active directory (e.g. Creating users, editing Group Policy and adding/removing users from groups) then sooner or later you will find that you might affect the stability of your DC (which would be BAD).

Apply policies as high as possible

When given the choice of applying the same policy at multiple lower locations or just one locations higher always try to link the policy as high up as possible in the OU tree. If there are cases where you want to apply the policy setting at all levels except for a minority of the lower sub-OU’s then simple apply a different policy on the fewer OU’s to make the exception.

Bad Example	Good Example

Linking GPO’s

Essentially there are three ways ways you can link a GPO to an AD structure firstly is to apply it to a OU secondly is to apply it to an AD Site and finally is to link it to a domain.

Linking to AD Site

I have to say that you should NEVER consider applying a Group Policy to an AD site EVER!!!. Not only does applying a GPO to an AD site make troubleshooting an absolute pain you frequently finding yourself inadvertently applying a user or workstation GPO to your servers (This can be VERY BAD). AD Sites are based on IP subnets and I agree it can be very handy to apply settings based on the IP address of the computer (see How to use Group Policy Preferences to dynamically map printers with Roaming Profiles ) and thankfully there is a way to now do this with Group Policy Preferences. Any of the new preference settings can be targeted using Preference Item-Level Targeting which gives you 27 different ways you can target your setting. The IP Address Range Targeting and Site Targeting target options will allow you to achieve the same targeting as applying the GPO to an AD Site however you are far less likely to make a mistake using this method as the GPO should be linked to resource OU that limits the scope of the policy to only a particular type of AD Objects (e.g. just workstations not servers).

Linking to OU

Linking a GPO to an OU is by far and away the most popular method of linking a GPO. This method allows for easily change the users configuration my moving them into the appropriate OU structure to have them configured. This method also fits well with the resource OU structure (see Part 1) so that you can disable parts of the GPO that don’t apply to the object that you are apply the policy.

Linking to a Domain

Technically you can apply a GPO to the Domain however this is more or less like linking it to the Root Organisational Unit. Linking it here will apply the policy to the entire domain so make sure that you are very careful when link a policy to this location. Policies should only be linked to the domain if you have a setting that you want to be applied to all users and/or computer in your entire domain. (See “Edit Default Domain Policies Sparingly” section above). The other scenario that you might want to link a policy here is if you want to make sure that you have at least your core policy setting applied to your “Users” or “Computers” container. But I would also recommend that you redirect these default locations for new objects so that you don’t have to setup GPO’s at the domain to cover these objects.

References

TechNet: Linking GPOs

If, however, the settings do not clearly correspond to computers in a single site, it is better to assign the GPO to the domain or OU structure rather than to the site.

TechNet: Linking GPOs

Most GPOs are normally linked to the OU structure because this provides the most flexibility and manageability

When to filter

There are two ways you can filter your GPO when you apply then to your AD structure. Predominantly I find that Security Filtered Group Policy Objects is the most common way you can filter. Either way you should be filtering a GPO only when you want to exclude or include exceptions to the scope of the policy.

Security Filtered

This method allow you to apply Group Policy Objects to a cross section of users or computers in your organisation. I quite often have a security filtered policy that has my pilot users computers as members so that I can selectively apply settings to their computers first for testing (see “Create a Test Group Policy Structure” section above). As computers and users can also be a member of multiple GPO this also allows you to configure a users environment without having to spawn many number of levels of OU’s that would other wise be necessary for every combination of  GPO assignment (see “80/16/4 Example 3 & 4”). You can in theory apply a single user or computer to a GPO by adding them explicitly to the GPO under Advanced security (see image below).

However this is extremely poor practice and I would strongly recommend that you should always create a security group that has the “Apply Group Policy” permission assigned to it so that at a later stage you can assign users or computer to the GPO without modify the permission on the GPO itself (see image below).

I know the name “Workstation GPO” might seem to conflicting with the “Don’t use the work “POLICY”  or “GPO” in the GPO name” rule that however in this case “GPO” is justified as this is the name of a security group and so it is not obvious that a the security group is used as part of a Group Policy Object.

Recommendation: When removing “Authenticated Users” from the security filtering of a GPO ensure that you only remove the “Apply Group Policy” permission and not the “Read” permission as this will cause “Inaccessible GPO” error when any non domain admin tries to look a the GPO’s via GPMC. See my previous post How to apply a Group Policy Object to individual users or computer for detail instructions on how to do this correctly.

Reference

TechNet: Defining the Scope of Application of Group Policy

If you have Read access to the domain, site, or OU, but not on one of the GPOs linked there, it will appear as Inaccessible GPO, and you will not be able to read the name or other information for that GPO

The exception to where you want to do this is if you have many GPO’s that are security filtered and you want to ensure as fast a possible security processing then removing the read permission will “slightly” improve performance. So unless GPO processing time is an issues this doing removing the read is still not recommended.

TechNet: Determining the Number of Group Policy Objects

If the Apply Group Policy permission is not set, but the Read permission is, the GPO is still inspected (although not applied) by any user or computer that is in the OU hierarchy where the GPO is linked. This inspection process increases logon time slightly.

Recommendation: You should only security filter GPO when the setting in the policy are mutually exclusive with all the other GPO in your organisation. If you have two GPO’s that are security filtered that configure the same setting and the user or computer are in both the group for that policy then only one policy will win out and you could end up with some fairly un-predictable results.

WMI Filters

WMI Filters have been around since Windows XP/2003 and are a great way to filter your Group Policy Objects based on the hardware of the computer that the policy is applied. However performing a WMI queries can take a substantial amount of time and if you have multiple WMI filters applying to your computers you have a significant performance decrease. Once again you can get around having to resort to using WMI Filters as Group Policy Preference Item-Level Targeting also have a number of options you can target hardware. Unlike WMI the Preference targeting engine has the performance advantage of being written in native code so it is much faster at determining what setting to apply.

They hardware targeting options are:

• Battery Present Targeting
• CPU Speed Targeting
• Disk Space Targeting
• MAC Address Range Targeting
• Operating System Targeting
• PCMCIA Present Targeting
• Portable Computer Targeting
• RAM Targeting
• As a legacy option you can even do WMI Query Targeting which allows you to easily port your pre-existing WMI queries into preferences. But be warned the WMI Query Targeting still suffers from the same performance issues.

So as you can see WMI Filters applied to the GPO object itself however just as in the “Where to Link” section above you will see Group Policy Preference will help you avoided having to rely upon WMI to often.

Reference

TechNet: Applying WMI Filters

WMI filters can take significant time to evaluate, so they can slow down logon and startup time.

Always create a deny “Apply group policy” security group

When creating a GPO always consider creating a security group and assigning it the Deny “Apply group policy” permissions (see image below) so that you have a simply way to exclude a particular user or computer from the policy in the future. Having this deny group applied to the GPO in advanced can save you a lot of time as it is often much easier and quicker to added a users to a security group than it is to modify the security on a GPO.

(Same as above) I know the name “Workstation GPO Deny” might seem to conflicting with the “Don’t use the work “POLICY”  or “GPO” in the GPO name” rule that however in this case “GPO” is justified as this is the name of a security group and so it is not obvious that a the security group is used as part of a Group Policy Object.

Apply GPO to New Users and Computers OU

In part 1 I recommended about setting up a new OU structure for any new user and computer that is created in your AD under the “Redirect New User and Computer Accounts” section. The reason why this was recommended was to enable you to easily apply a GPO to the default locations for these objects without having to resort to modifying the Default Domain Policy or by linking a new GPO to the entire domain.

It the example below I have created a simple GPO for each Users and Computers OU. Using this method your default user and computers will still receive the “Default Domain Policy” GPO and any additions settings in the two “New” GPO’s.

I don’t recommending linking the “People” or “Workstations” GPO’s (See “Example Group Policy Designs” section below) as the New\Users and New\Computers OU as they could contain objects other than People and Workstations (e.g. Service Accounts or Servers). Instead I recommend that you only configured some basic security setting for the “New Computers” such as a default WSUS and patch install schedule so that any computers that are left in these OU’s are at least kept up to date with security patches. Then for the “New Users” GPO you may want to configure a delayed logon script (see How to schedule a delayed start logon script with Group Policy) that notifies the users that they are not properly configured and they need to contact the help desk.

In any case even though you have configured these locations it is still very important that you establish some sort of regular process by which someone reviews the objects in these OU’s and ensures they are moved into the appropriate locations so the proper policies are applied.

References

Designing an OU Structure that Supports Group Policy

…change the default location where new user and computer accounts are created so you can more easily scope GPOs directly to newly created user and computer objects

Use the 80/20 rule

Ok… this is the a rule in name only as it should also be considered as a guideline. Essentially you should try to put the vast majority of setting in a policy that applied to all your computer or users. Then you should apply the exception to the default policy to the subset only to the computers you want to apply these settings (see 80/20 Conceptual Design). If two scopes/levels of applying policies is not flexible for your organisation then you can even consider the 80/16/4 to give you more flexibility (4% equals 20% of 20%). Also note the smaller 4% scope does not necessarily need to be a complete subset of the 16% as it is possible that you want to apply location specific settings that have nothing to do with the organisational structure (see 80/16/4 Conceptual Design below).

When deciding what policy settings to put in the 80% of 20% GPO’s make sure that you take another look at the “Monolithic vs. Functional GPOs” section above that talks about the different approaches you can take when configuration settings. As I said before the 80% policies are going lend them self to have more setting in them but they will probably be relatively static (i.e. Monolithic) where the 20% policies will have fewer settings but probably need to be updated more frequently (i.e. Functional).

80/20 Conceptual Design	80/16/4 Conceptual Design

The conceptual designs above shows that there is only one level 2 and level 3 scopes to apply GPO but in reality there could be many different lower level policies that can be applied to your environment as seen in “80/16/4 Example 4”.

Example Group Policy Designs

The organisation below that I use in the examples conveniently has 100 setting that they need to apply. Therefore they number of setting equals the percentage break down of the number of settings that are applied. In real world the number of setting are obviously going to vary greatly from single digits perhaps many thousands of settings.

“80/20 Example” is a simple representation of how you would actually apply this in the real world. As you can see 80 setting are applied at the top level to all “People” OU and there then there are 20 settings site specific user settings. These location setting are typically drive and printer mapping setting that are specific to the site. While the “People”  Group Policy Object will have setting that need to be applied to all users universally (e.g. screensaver time out value.)

80/20 Example 1

“80/20 Example 2” is the same as Example 1 except in this scenario the business has decided to have a top level organisational OU structure so that it will be easy in the future to separate parts of the organisation from the AD in the future. This illustrates that you do not need to have the same number of levels of OU’s in your AD as the number of level of scope that you apply GPO’s.

80/20 Example 2

“80/16/4 Example 1” shows you how you would apply this to a “Three Tier OU Structure” (see part 1). The advantage of this model is that all setting are applied base on the OU structure and which means all policies are applied simple based on the location of the AD object in the OU structure. This is useful as you don’t that you don’t need to add and users (or computers) to security group.

80/16/4 Example 1

“80/16/4 Example 2” shows you what you can do when you only want to apply the same “Manufacturing” setting to all the users across all the sites. This takes into consideration the “Reuse GPO’s where possible” rule (see above) and link a single manufacturing GPO

80/16/4 Example 2

“80/16/4 Example 3” shows you how you could apply the policy differently using a single security group filtered policy at the top level but still have the same affect as the “80/16/4 Example 1”. This is an example of applying a 3 level GPO structure to a 2 level OU structure as the “Manufacturing” simple by applying it at the top level but then applying a security group filter. The advantage of doing it this way is that you don’t need to have as many OU deep (see “Go Wide not Deep” in part 1) and it avoids having to create a new Group Policy for the manufacturing users at each site (especially when they might be the same settings).

80/16/4 Example 3

“80/16/4 Example 4” shows a combination of “80/16/4 Example 1” and “80/16/4 Example 2” where the organisation has generally the same requirements of “Example 1” however they need to apply 1 high security setting (e.g. shorter screensaver timeout) that need to be applied to the managers computer because they normally deal with sensitive corporate information. This also illustrates that you can have multiple level 2 and level 3 GPO in the same environment and that level 3 GPO policies do not necessarily need to be a subset of level 2 policies (see conceptual circles above).

80/16/4 Example 4

Apply default settings on your 80% level one policy just in case

I know I have just gone though above that you should apply 80% of your settings in the highest policy however there is one problem with this. If for some reason a computer or users is placed in a top level OU or a second level OU is created without a policy applied to it or a user or computer has not been added to the correct security group this could leave gaps with the coverage of settings. So to get around this issue be sure that your level one 80% policies are configured with a default setting to cover your more essential configurations such as  Screensaver timeout or WSUS servers.

In the example below we have 95 settings (or 95%) of the setting being applied to the users with the 20% being applied at the second level policy. Effectively only 80 settings (or 80%) will be actually be applied to the users from the top level policy as there is a 15% overlap of settings the settings. However a user in the “People” or the miss configured “Brisbane” OU will at least get 95 setting (or 95%) of the settings applied. This might not be a perfect configuration for them however it will at least mean they are compliant to the mandatory corporate configuration settings (e.g. Screensaver on and WSUS server configured).

In closing I hope this documents has helped you design your Group Policy infrastructure in your environment. If you have any other questions you want covered or you simply have a question about what I talked about above please feel free to post a comment…

Other References

Here is a list of link to other web sites that I have found useful in guiding my design decisions with group policy.

• Appendix A: GPO Scenario Policy Settings
• TechNet: Designing a Group Policy Infrastructure

Change Log

I plan for this to be a dynamic article that I will change over time and I am sure there will be a few errors along the way that will need correcting so below are the list of changes that I made to this article since it was originally published:

28/07/2010 – Add section for “Monolithic vs. Functional GPOs” from http://technet.microsoft.com/en-us/magazine/2008.01.gpperf.aspx by Darren Mar-Elia via Mike Kline

28/07/2010 – Corrected error in the WMI Filter sections that said they had been around since Windows 2000 (Should have said XP/2003). Thanks to Aaron Parker

2/08/2010 – Added mention to “How to Link” that you can link to the domain. Added more references to Microsoft TechNet articles. Added “Create a Test OU Structure”

3/08/2010 – Added “Apply GPO to New Users and Computers OU” section.

24/10/2011 – Added refrencec to Best Practices for Defautl Domain policies…