With the new Archives feature in Exchange 2010 and its support for lower cost storage this has started to allow users to have bigger mailboxes. Office 365 even gives users a default mailbox size of 25gb (up to unlimited) depending on the plan the user it signed up for. Problem is that users could still have PST files even thought they might now have plenty of space in their mailbox…

Well Microsoft has just announced they have released a tool that allow admins to automatically crawl users computers and import PST files into Exchange Online or Exchange 2010.

Download http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28767

So you might be wondering what this has to do with Group Policy… well… once you have completed the migration of the PST files you can then implement the Prevent users from adding new content to existing pst files policy setting to stop users ever, ever, ever, ever using PST file again….

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

As I only have limited time and material to make out some letters I decided that I would spell out the initial of my favourite tech topic… Group Policy.

Hint: Look for the letters “GP”

That’s my house… Can you tell I like “GP”.

In case you were wondering where i live… all i will say is that it is somewhere here http://www.nearmap.com/?ll=-27.596543,153.106413&z=14&t=k&nmd=20110919

Group Policy Infrastructure Status

If you click on the domain name in GPMC you will notice there is a new tab called “Infra Status”. As the page says “The page shows the status of Active Directory and Sysvol (DFSR) replication for this domain as it relates to Group Policy”. This will obviously be a great troubleshooting tool for Group Policy settings that are not applying to the computers in your organisation due to AD replication issues.

Group Policy Update

If you right click on any OU in you AD you will see a new menu option called “Group Policy Update…”.

Clicking on this option with an OU with no computers in it gives you an interesting explanation of the feature.

You have chose to force a Group Policy update on all computers within Workstations and all sub containers.

What is particularly interesting is the text “FORCE A GROUP POLICY UPDATE" meaning that you can now force the group policy update to all computers in a Organisations Unit. This would effectively mean that administrators can now make changes to their computers without having to wait the default 90 minutes to wait for group policy to refresh on a computer. 

After trying to make the option work by populating the OU with a few computer accounts I simply got the same message again and again. I can only assume that this is a feature that has yet to be implement in this build…

I have been able to get the wizard to working by building a real Windows 8 computer and added to the “Workstations” OU.

After click yes it has found the “real” computers in the OU and forces a Group Policy update to run within two minutes on these computer.

Seeing the task was scheduled I then took a look at the scheduled tasks on the computer being targeted and found that it had created two scheduled tasks to perform a gpupdate in the user and computer context.

Note: You will need to configure the client firewall on the workstations being targeted to allow these command to be created… More info coming on that…

So I have also found that the UI for the Internet Explorer Group Policy Preference has been updated to include IE8 and IE9 (see image below). This support would have been nice update to the hotfix that was just released for windows 7 to support Internet Explorer 9 (see Hotfix: Internet Explorer Group Policy Preferences do not apply to Internet Explorer 9)

I have not found anything else in this build that is Group Policy related but I will keep digging… But it is great to see that Redmond is still adding improvements to Group Policy with the latest version of Windows.

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

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

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

Is WSUS the right tool for your organisation?

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

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

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

WSUS Tip’s and Tricks

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

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

WSUS Computer Group Assignment

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

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

DNS Alias for WSUS Server

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

Default Top Level GPO

Another great thing about WSUS is that the Automatic Update agent, which is the software the client uses to connect to the server, is included out of the box in every single copy of Windows Since XP. This means that there is no additional software agents that need to be deployed to the computers to get starting using WSUS. This being the case… You can set a policy at the very top level of your domain using the “Specify intranet Microsoft update service location” setting to configure every computer on your domain to point to the WSUS servers.  I find that once an organisation does this they are amazed how this discovers a number of “hiding” computers on their network that have never been patched.

In conjunction with this setting I would also recommend that you set the “Configure Automatic Updates” to option 2 so that by default you are NOT inadvertently pushing out any patches to any computers.

Doing this this is more a discovery process so that you can at least be aware of any un-patched computers on then network that you can then appropriately remediate… An added side benefit doing this is you also get an accurate picture as to home real computer’s are actually on your network.

Hierarchical Naming of Target Groups

Back in the day of WSUS v2 you could allocate computers to target groups however these target groups could not be nested and it meant that every target group had to be unique. Even though WSUS v3 now has the ability to have nested target groups it still has the same restriction that all target groups must be made unique. I suspect that it is due to the ability for a WSUS v3 server to act as a parent to a WSUS v2 server during a migration of WSUS. That being the case, you need to deploy you target group naming strategy in a way to avoid need two target groups with the same name…

Here I will tell you to go visit my Best Practice: Active Directory Structure Guidelines – Part 1 post where I talk about the number of ways you can build your OS structure.

Now we will use the example “Two Level Hybrid (Resource / Location)” (see image below) from the AD Structure Guideline for out WSUS target groups.

You would use the following Target Group Structure…

You might also notice in the above image I also have “Terminal Servers” and “Servers” at the top level of the WSUS Structure. Generally I recommend in most environments these are the only top three WSUS groups you will need. I will go into more detail on this further on in the “Top level Patch Approval Groups” section but for now just ignore the server and terminal server target groups…

What you will find is that the OU design of your organisation will largely mirror your OU Structure. You might also notice that the names of the target groups are “Workstations SITENAME” and not just “SITENAME”. The Workstation prefix is required as you might also want to patch Servers in the same site and therefore due to the unique target group requirement you will need to have a “Workstations Sydney” and “Servers Sydney” group.

Now also take a look at the “Keep the GPO’s name consistent with the OU names” section in my Best Practice: Group Policy Design Guidelines – Part 2 post you can see how the WSUS Target Groups are also very consistent (but not the same) as the OU’s that the computer are located. The advantage of doing this is that it makes it a lot easier to determine what OU a computer is a member of just by looking at the target group it has in the WSUS console.

Here you can see an example of how the Group Policy Object would also be applied to support the OU Structure and WSUS Target Group Structure above….

So now if you have actually read my other two AD and GP Best Practices blog posts you might actually be seeing the sheer genius of how these designs are related (Yes I know I am modest). I know that this might not be practically to implement this utopia design for most environments but if you strive to have at least a consistent naming and structure to you organisation I find that it makes finding, troubleshooting and configuring your environment a whole lot easier…

Configure Update Setting and Target Groups Separately

If you have chosen to use a “Resource\Location” OU Structure in your organisation (as seen above) then you should also apply a default “Configure Automatic Updates” on the GPO linked to the Workstations OU. This allows you to apply the default action for patches and if and when they are applied to all workstations consistently from one policy meaning if you ever need to change these setting you only have to do it once.

The other configuration you need to apply is the “Enable client-side targeting” which assigns the WSUS Target Group to your clients. This policy should be applied at in the GPO linked to the lowest level of your OU structure. The example below applies the target group “Workstations Sydney” in the GPO called “Workstations Sydney” (notice the same name) which would be applied on the OU “Workstations\Sydney” (Assuming you are using my genius Group Policy Object naming convention).

Essentially what this means is that the minimum settings are being applied to all clients by using the sum total of setting applied using multiple GPO’s at different levels.

Just to recap we are applying three essential Group Policy setting at three different levels which get combined together when the policy is applied to the client:

• “Specify intranet Microsoft update service location” is applied at the top level domain so it is configured once for all clients.
• “Configure Automatic Updates” is applied via the relevant GPO that applies to all computer of a particular type. (e.g. “Workstations” GPO allied to all Workstations).
• “Enable client-side targeting” is applied at the lowest level to allow granular reporting of the status of computer groups by Site or Role.

Once you have applied the above three settings to your computers then your clients should have the minimum setting to report into your WSUS server.

Implement a WSUS Update Test Group of Computers

One of the reasons you have a WSUS server hosted internally (besides saving a whole heap of bandwidth) is to allow you to manage the approval of patches to deploy to your computers. The main reason you want to do this is of course it allows you to test these patches to make sure they don’t break anything…

To establish a test group for patches you will need to create a number of security groups. These groups will have the computer accounts in them that you want to use for testing patches. At minimum you probably need to create two security groups, one for workstations and one for servers. However you might find that you need to have to additional groups if you want to have additional independent test groups.

In this example I am establishing a Workstations Test groups using the security group called “WSUS Workstations Test”. Note, I have prefixed the group name with WSUS so it is easy to find all the WSUS related security groups in my organisation.

Next you need to create a Group Policy object at the highest level possible that will apply to all your workstations in your organisation. In this example I have linked the policy at the Workstations OU as this will contain all the workstations in my test environment. However if I have workstations under various top level OU’s then you will need to link the policy at the top of the domain.

The next thing to do is to configure the advanced security of the policy to remove “Apply group policy” from Authentications Users and Add the group “WSUS Workstations Test” (see images below). This will make sure that this policy ONLY applied to the workstations that are member of the “WSUS Workstations Test” security group.

Now you have configured the security delegation you can configure the “Enabled client-side targeting” setting to “Workstations Test” and then enabled the “Enforced” option of the policy (see images below).

Your test policy should now look something like the image below.

As the GPO is configured with the “Enforced” option it will override any lower level target group configuration. This has the slight disadvantage of not having the granularity of the lower level targeting (e.g. Workstations Sydney) as all the computers in the test group will be targeted using “Workstations Test”. But this is normally an acceptable trade-off as these computer are going to be patched at a different schedule anyway…

TIP: Make sure that the computers you have selected to perform patch testing are a good cross section of your environment. You may also want to make sure that the people that use these computers are technically proficient and are likely to report an issues if something goes wrong.

Next you need to make the “Workstations Test” group in WSUS under the “Workstations” Group. The main reason why this is a sub group of the “Workstations” group is that you want to ensure that your test workstations have at least all the same patches approved to them as the other non-test workstations.

If you then create the “Workstations Test” group at the top level you would need to 1. approve all patches twice to both top level groups and 2. risk approving a patch to the one group and not the other and thus making your test computer not an accurate representation of your non-test computers.

Now that you have selected your test workstation, added them to the test security group and have them in the “Workstations Test” WSUS group you are right to start testing update to this group of computers.

Once you have finished testing of the patch and you are going to approve it for the rest of the computers ensure that you reset the approval for that patch on the “Workstations Test” group by using the “Same as Parent” option.

Doing this will ensure that the patch approval to the “Workstation Test” are a complete superset of the patches approved on the “Workstations” WSUS group.

Applying patches to sub roles of computer

If you have some need to separately approve patches to a group of computers that is not just a workstation, terminal server or server (e.g. Exchange Servers) then simple go through the same process in the about “Implement a WSUS Update Test Group of Computers” section giving it what ever name is appropriate (see images below).

Configure All Workstation to “4 – Auto download and schedule the install”

Generally speaking the vast majority of clients for your WSUS server will be workstations and as such you probably DON’T want to manually installed patches on these computers simply because you have much better stuff to do with your time. Therefore in the “Workstations” GPO that I talked about earlier you should configure the “Configure Automatic Updates” option to “4 – Auto download and schedule the install” and the schedule to “0 – Every day”. The affect of this is of course any workstation on you network will have the patches scheduled install within 24 hours of you approve a patch.

The exact scheduled time is up to you, however the default time of 3:00am has served me well over the years and I have never come across any reason to change this time for the bulk of the workstations being patched. I am not sure of the exact reason why 3am has been selected by Microsoft but I am sure they have there reasons…

Reference TechNet: Best Practices with Windows Server Update Services

one of your main goals is to have any planned downtime occur when there is little chance for lost productivity

Obvious question however is What happens if the computer is off at 3am? Good question… and i will talk about that more later.

How to configured a No-Reboot Policy for Workstations

One of the problems scheduling all your workstations to automatically install patches at 3am is that sometimes computers are deliberately left on overnight to perform some automated task like batch processing. If this applies to you then you need to create a separate GPO that you can apply to the non-reboot workstations. This of course means you have to manually kick off the patch process for these computers but this number should be at least manageable.

This no-reboot Group Policy will be targeted the same way the test group (see above) using a security group to control what computers get this setting. Same as the “Workstation WSUS Test” this policy will have authenticated users removed and only be security filtered using a group called “WSUS Workstations No Reboot”. The “Configure Automatic Updates” will then be configured to “3 – Auto download and notify for install” to ensure that the computer will not automatically reboot at 3am.

As I mention earlier these computer will not auto reboot however they will download and cache all the patches they require which makes it very easy for any admin to visit the computer and manually install the required updates using “Automatic Updates” in the control panel.

Configure All Servers to “3 – Auto download and notify for install”

Reference: TechNet Best Practices with Windows Server Update Services

For maximum control over when your servers are restarted as necessitated by an update installation, set Group Policy to Download the updates automatically and notify when they are ready to be installed, and then create a script that enables to you accept and install the updates and then restart the computer on demand

Unlike your workstations you usually want to carefully plan and schedule the install of patches for servers in your environment. Therefore by default you DON’T want your servers to be automatically installing patches and rebooting at 3am every day. So to ensure that your servers don’t auto install patches configured the “Configure Automatic Updates” setting to the option “3 – Auto download and notify for install” in the global “Servers” GPO you have applied to all your servers (see image below). Doing this will ensure that by default none of your server will automatically install patches and reboot allow the server admins to install the patches at a time of their choosing.

Note: See I also have the “Servers WSUS Test” group created for testing patches to the servers in my environment.

How to automatically patch servers

So you have been patching you servers manually for a while and now you wish there was some way to schedule the patching of them out of hours at a time of your choosing… the good new is that this is possible.

To do this will will stager the patching of these server with Round 1 to Round N computer groups. Servers in the same round will be patches at the same time and therefore will generally not be dependant on other servers in the same round. It would also be wise to never put all your servers in one basket, so don’t schedule a patch and reboot all the servers in the same cluster at the same time (that would be bad). Breaking up the number of server into different rounds also means that if there was an issue with a patch then you will have not applied them to all your servers in your environment.

Before we begin…. A Warning…  You may remember that Group Policy refresh can take up to 2 hours approx. this means if you are going to use Group Policy to automatically patch your servers you have a go/no go point some time up to about 3 hours before your plan to reboot. After this point if you decide to abort the scheduled update you might not have enough time to allow for AD propagation and Group Policy refresh for all your servers to stand down from the auto reboot that was scheduled.

The opposite is also true which means if you have not enabled these policies before 3 hours you want them to patch then they might not get scheduled in time…

In the example below the servers will be split into three rounds that will all patch at different times (see table below).

The table above shows that each round will have its own Group Policy Object that will be security filtered using a security groups. They are also scheduled far enough apart that if something goes wrong with one round then you have enough time to un-schedule the next round of patch deployments (see warning above).

The image below is what the GPO’s would look like if the same round in the above table were implemented:

Also note that these GPO’s are normally not “Link Enabled” (see image below). The reason you do this is that you only want to have these policies enabled when you want to schedule the update to your servers (perhaps once a month). Having these policies disabled means that even if you do approve a patch to the server group it still won’t automatically install until you also enable the link on the GPO.

Generally speaking automatic server patch can be scary, however if you know your environment well and you have successfully refined the manual patch process for your servers then stepping it up to automatic deployment. That being said I would still start small with only a few servers and work your way up before you start to push out patches to all your servers and you should always monitor the progress of the reboot of these servers to confirm there was no issues in applying the patches…

Note: If you think that the patch rollout will take multiple reboots note that you will need to manually initiate the second patch update and reboot to install any remaining patches… Generally you should know if this is required after you have deployed you test patches.

Top level Patch Approval Groups

Of course not all your computers in your environment are the same and as such you probably have different patching requirements for your computers based on their role. While you might just take the approach to approve all patches to the built-in “All Computers” group the problem with this is that you might want to spend a differently amount of time testing patches on servers as opposed to workstations.

Therefore I have generally found that all computers fall under 3 main categories, Workstations, Terminal Servers and Servers.

Workstations are the most vulnerable computers in your organisation because of the inbuilt security risk called “users”. Until Microsoft figures outs a way to mitigate this security risk you are just going to have to ensure that as many security holes on the software on the computers as possible (Not to mention apply the recommend security template from Security Compliance Manager). Therefore I recommend that you approve any required update to this group of computers on an aggressive timeline…

Terminal Servers (a.k.a. Citrix Servers… a.k.a. Remote Desktop Servers… a.k.a. what ever other name there is) are kind of strange is that they run the Windows Server OS but they are used by that security vulnerability the “user”. Therefore you need to treat the Terminal Servers in your environment very similar to how you patch your other workstations and deploy any detected security updates.

The time you take to approve test patches to your workstations and terminal servers is also is a major difference to your servers as often you need to get these patches out due a zero day vulnerability. In this case I recommend that you have a standing change control approval or understanding that all new patches will be automatically to the test computers as soon as they come in to start the testing process as quickly as possible. This means when you get to the point to make a decision about when you are going to deploy an update you already have a really good idea what impact this is going to make on your environment when you deploy it to the rest of your computers.

Servers obviously are a little different as they don’t have that nasty “user” vulnerability. Therefore you normally can take more time to test the patches to these servers. Having a separate top level WSUS target groups allows you to independently approve any patches that you might want to deploy to your servers.

Review your “needed” patches

So after read the above section about patch approval groups you might not consider that you have to approve Microsoft Office patches to your servers and vice versa approve Exchange or SQL patches to your workstations…  But you would be wrong. The problem is that many times you will find that certain components of products may indeed be installed where you never expected them. A good example is the Exchange Management tools are sometimes installed on Workstations to allow IT Admins manage the exchange server. Another example would be having the a word or excel document viewer installed on a server as it was installed as part of another program installed on the server to view documentation.

Therefore you should regularly review what updates are being detected as needed and plan to also approve these patches during your next patch cycle…

Configuring Background Intelligent Transfer Service for WSUS

Updated for WSUS are pushed out to the clients using the Background Intelligent Transfer Services (a.k.a. BITS). This has a number of bandwidth savings on your network as it server to deliver patches to the clients over even the slowest of network links… But of course some updated (like service packs) can be quite large and therefore you may want to consider configuring the “Set up a work schedule to limit the maximum network bandwidth used for BITS background transfers” setting.

Note: This setting is a configuration per client so if you configure 100 workstations with 1mbit network speed they will try to all download at 1mbit at the same time.

Another really great feature to enable if you are running Windows Vista or 7 is “Allow BITS Peercaching”. This allows the clients on the same network segment to share the parts of files they have already downloaded locally with other peers. This effectively means you only need to transfer the file once to a site but have it used many time thus saving a whole heap of WAN bandwidth.

Use WSUS for your DMZ Servers

One of the interesting things about WSUS is that it requires no authentication for the client. Therefore pretty much any server domain or non-domain joined can successfully register it self against any WSUS server. One advantage of this method of allowing any client to connect is that clients in a DMZ can be configured to report into a DMZ server that is hosted on the internal network. To enable this to happen however you do a few things:

• You need to allow TCP Port 80 (or 443) from your clients in the DMZ to your WSUS Server.
• As the clients in your DMZ are probably not domain joined you will need to manually apply the registry keys to configured the automatic update service. To make this an easy process just export all the registry keys from “HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\WindowsUpdate” (Yes I know this is not strictly a Group Policy) of a domain configured client with the settings you want to use. This way you can just apply this registry file to the computer you want to configure in the DMZ.

TIP: Change “HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\WindowsUpdate\TargetGroup” value in the registry key to “Servers DMZ”

• Update the HOST’s file of the DMZ server so that the name of the WSUS server (e.g. “wsus.domainname.local” will resolve to the correct IP address. This assumes you cannot resolve internal host names from the DMZ.
• Optional: As an added level of protection, you can use HTTPS encryption of all traffic to the WSUS server. If you do opt to do this you will need to allow port 443 open on the firewall and you will need to install the root certificate for you internal certificate server on your DMZ host. Also see http://technet.microsoft.com/en-us/library/cc708550(WS.10).aspx for instructions installing HTTPS on your WSUS Server.

Other WSUS Group Policy settings

Below is a collection of random other Group Policy Setting you should consider in your environment:

Enabling Windows Update Power Management to automatically wake up the system to install scheduled update – This setting only applied to Windows Vista or above and I can’t say I have ever had any experience with implementing this setting. However if it work as advertised then this will go a long way to ensure that computers that are patched even when turned off, largely negating the need to send a Wake On LAN to patch clients afterhours.

Automatic Updates detection frequency – In this Tech Net Article Best Practices with Windows Server Update Services they say….

“if you are aware of and want to protect computers against immediate security threats, you might want to set up more a more frequent schedule for computers to contact the WSUS server, download, and install updates. “

It might tempt you to change the this setting to 1 hour. You will quickly find out that this may have the affect of bring the WSUS server to a grinding halt, as you would be loading the server with 22 time more the number of request. If 10,000 clients report into the server every 22 hours and you set this policy to 1 hour that will increasing the load to be equivalent of 220,000 clients.  SO… DONT change this setting unless you do have a case to change. But if you do make this update happen faster ensure you only apply it to a select number of clients.

Allow Automatic Updates immediate installation – What you might not realise is that some patches that are released from Microsoft do not require the computer to be rebooted. Typically Microsoft Office patches fall under this category. Therefore the Automatic Update agent has the option to install these non-reboot patches straight away without interrupting the user if they are not actually using the relevant program at the time. Obviously this speeds up greatly the deployment of these non-reboot patches and it also means that you will have fewer patches to install on reboot and thus make the whole patch process go all the more quicker…

No auto-restart for scheduled Automatic Updates installations – Loss of productivity is a bad thing, and while enabling this may lengthen the time it take for a patch to be deployed it is most often preferable to just let the install of the patch being delayed then to reboot the computer with the user logged in resulting it lost work.

Be carful of Time Zones

A word of warning… Time in the “Configure Automatic Updates” setting applies the reboot sechduled to the client based on the time and time zone of the client. Therefore if you apply a 3am reboot to all your clients in the world it will take 24 hours before all the clients have installed the update.

HOWEVER!!!!!

If you approve a patch with a deadline from the WSUS console (see image below)… BE WARNED!!! This will reboot the clients at the time relevant to the WSUS Server. This means it would reboot every computer in the world at exactly the same time at 3am local time to the server… Clearly this could be bad as someone on the other side of the world could be force rebooted in the middle of the day.

Domain Controllers

Finally Domain Controllers are somewhat different as they are of course located in their own special “Domain Controllers” OU. But, if you have configured a Default Domain WSUS setting at the top level of the domain (see  “Default Top Level GPO” section at the beginning of this document) then the Domain Controllers will already be reporting into WSUS server as an “Unassigned Computers”.  The only other GPO setting you might want to apply to the domain controllers is the “Enable client-side targeting” setting configured to a value such as “Servers Domain Controllers”.

TIP: I would recommend that you create a separate GPO as i normally don’t like to modify the “Default” group Policy Objects.

If you do decide to do this don’t forget to also create a WSUS target group called “Servers Domain Controllers” under “Servers” in your WSUS Target Group Hierarchy.

Summary

In summary the process of using Group Policy to support your WSUS patching infrastructure can be quite powerful and save you a lot of time… However always make sure that you proceed incrementally as you implement changes making sure you understand how each change works before moving on…

I also hope that you can see that when you use Group Policy + WSUS are used together it can be a VERY powerful patching infrastructure…

This has of course prompted Microsoft to starting pushing IE to the corporate customers say “’We’ve got a great solution for corporate customers with both IE8 and IE9”

So to illustrate this I have graphed the number of days that Microsoft supports Internet Explorer compared to Mozilla’s Firefox 4.

Note: I assume that IE9 will not have extended support lifecycle as it was NOT released as part of Windows 7.

Certainly having to support IE6 for over 9 years is a major commitment for Microsoft especially when there are so many security issues… But even while Microsoft encourages users to stop using IE6 http://www.theie6countdown.com/ they continue to support IE6 as promised for the long haul and are certainly not going to be “forcing” anyone to upgrade any time soon. For this reason, plus Internet Explorers excellent out of the box group policy support (for third party see Policy Pak), is why I think IE is  hands down best browser for any corporate environment….

GetGPOList function does not return all GPOs in Windows 7 or in Windows Server 2008 R2

Consider the following scenario:

• You have a computer that is running Windows 7 or Windows Server 2008 R2.
• You use the LocalSystem account to run a service on the computer.
• The service calls the GetGPOList function to query all Group Policy objects (GPO) that are applied on a computer.
• The Authenticated Users group is removed from the access control list (ACL) in an applied GPO.

In this scenario, the GetGPOList function does not return all applied GPOs. The function returns only GPOs that have the Authenticated Usersgroup in the ACL of the GPO.

When you use a GPO for application deployment in Windows 7 or in Windows Server 2008 R2, the deployment fails

In an Active Directory Domain Services (AD DS) environment, you cannot use a Group Policy Object (GPO) to deploy applications for installation on client computers that are running Windows 7 or Windows Server 2008 R2. When you try to apply the GPO, you receive an error message that resembles the following:

• Windows failed to apply the Software Installation settings

Group Policy logon scripts do not run in Windows 7 or in Windows Server 2008 R2

Consider the following scenario in an Active Directory domain environment:

• You deploy logon scripts by using Group Policy.
• You set logon scripts to run synchronously.
• You try to log on to a client computer that is running Windows 7 or Windows Server 2008 R2.

In this scenario, the logon scripts do not run before the logon process.

A user who has administrator permission can delete printers on a computer that is running Windows 7 or Windows Server 2008 R2 after you deploy the "Prevent deletion of printers" Group Policy

Consider the following scenario:

• You deploy the Prevent deletion of printers Group Policy in your environment.
• You have a client computer that is running Windows 7 or Windows Server 2008 R2.
• A user who has administrator permission logs on to the client computer.

In this scenario, the user can still delete printers in Devices and Printers unexpectedly.

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

Source: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL309

Best of all this app is FREE!!!

In case you were wondering who those guys are in the background of the app check out the Meet the Group Policy People article.

Now I have to admit that I am not a developer but this is my first attempt at making a Windows Phone application and it has been pretty easy. But if there are any issues with the application please use the Feedback button (under About) to email me directly or if you have any feature suggestions.  I also have to give a lot of credit has to go to David Glover who wrote the Social Viewer application template which this app is based on that can be found at http://socialviewer.codeplex.com .

Note: There is an update coming some time next week that will enable Facebook support and enable add support (got to pay the bills).

Download link zune://navigate/?phoneappid=5c39e194-1280-e011-986b-78e7d1fa76f8 (if the link doesn’t work you can just search for “Group Policy” on the marketplace.)

Introduces Group Policy, provides an overview of what you can do with Group Policy, describes essential concepts that you must know, and provides step-by-step instructions for the most common Group Policy tasks.

HTML Version: http://technet.microsoft.com/en-us/library/hh147307(WS.10).aspx

Docx Version: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=470526da-8350-4314-a48d-ca97721855e1

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

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.