WSUS 3.0: Deployment and First Configurations (Part II)
To pull off some of the best practices that we talked about on the first part of the WSUS 3.0 posts, we’ll take a look to some technical configurations. At this point you must already have set different OUs for the type of computers you have in your environment. This OU separation will help you to improve your patching process.
· Group Policies Configuration
If you are using Windows Server 2003, first of all let me say that you must install Group Policies Management Console to apply and access all of the policies on your domain, this tool gives you a nice interface to interact with those objects. But if you are using Windows Server 2008, this console comes integrated with the operating system, so there’s no need on installing it.
Like you remember, on the first part we talk about applying different policies for different computers and also different levels of GPOs: A “common” GPO for the entire domain and over the OUs (and sub OUs if is the case) applying another GPO for more restrictive options.
Let’s start then opening the GPMC and over our domain click on “Create and Link a GPO Here”:
After we insert the proper name for our WSUS GPO, we right click on the GPO and select “Edit”. The “Group Policy Object Editor” opens.
The location of the most important group policies that we need to configure are located in “Computer Configuration” -> “Administrative Templates” -> “Windows Components” -> “Windows Update”
Like this policy will apply for all the computers in the domain, you have to find out the common GPOs on all the computers, no matter which OU they belong. In my case, I’m setting only the options “Specify Intranet Microsoft Update service location” pointing to my WSUS server and “Configure Automatic Updates” to “Notify to download and notify to install”.
If you don’t have these two policies set every time a computer joins to the domain, since they automatically they are stored on the “Computers” OU, and if they also have set the default option for Automatic Updates installation, that computer will automatically download from Internet and install those updates without using the WSUS server. Remember that you cannot apply a GPO over the Computers OU, so applying to the domain will ensure you that these computers will follow the WSUS GPO.
On the OUs that you have set for storing your computers and servers, you can link all the GPOs as you please: Frequency that the computers will ask for the WSUS server about new updates, hours that the updates will auto install, etc. Take a look to each explanation of the options to find the correct combination for you. This is an example of a GPO applied on a workstations organization unit:
Take a look also to the option available on “User Configuration” -> “Administrative Templates” -> “Start Menu and Taskbar” -> “Remove links and access to Windows Update”.
This option when it’s enabled prevents user to access Windows Update Website and removes any links available on Control Panel or Start Menu.
· When should I apply the updates on my servers?
Well you should have a good plan about how and when to deploy the updating process on your servers, after all that is the critical point on every scenario.
Microsoft has a certain “policy” about when the updates are released, which is commonly on every Tuesday of the week. Why? :
Tuesday: Update released.
Wednesday: Install on test lab.
Thursday: Test the update.
Friday: Install on production.
Weekend: Reboot the servers.
You should avoid to leave your servers without the proper reboot when a critical update is installed.
Before finishing this second part of mine WSUS 3.0 posts I have two warnings to consider when applying Group Policies:
1 – If you apply the option on “Configure Updates” enabled and selecting “Auto download and notify for install”.
Combined with enabling the option “Remove links and access to Windows Update”, and you apply this combination on a OU that contains computers with Windows Vista operating system, the users on those computers won’t be able to install the updates.
It will notify that are new updates available for installation but the Windows Update panel disables the option for installation. So, if your patching process lets the users to decide when they want to install the updates, you must not configure (or set as disable) the option “Remove links and access to Windows Update”.
2 – If your plan is set to “Auto download and schedule the install” of the updates, keep in mind that most of the updates released by Microsoft, when they are installing on the operating system, often requires several of disk and processor usage; making an uncomfortable session if there’s a user on the computer at that moment. Maybe it’s not a bad idea to let the user decide when the updates must be installed. You will still have good control over the health status of each computer using the Windows Server Updates Services console.