As we all know, keeping your servers updated can be a tedious job. As Exchange and OCS deployments grow in size and complexity, the judicious administrator will deploy more automation tools to minimize those tasks that can be managed automatically. One of the tasks is the onerous job of keeping servers and systems updated to ensure security and functionality.
In part one of this series, I showed how to do the simple method - subscribing the OCS host server to Microsoft Update so that the server could get the OCS updates that are published from time to time as well as the operating system updates that come out monthly. This same process is used to subscribe the various Exchange server roles. In this post, I will show you how to configure WSUS (Windows Server Update Services) to accomplish the same tasks. In fact, it also works for SQL, SharePoint, Project Server, and any other Windows operating system I can think of (well, not PXE or Mobile, but you get the idea). If you already have WSUS deployed, excellent, then you only need part of this post to accomplish your goals. However, believe it or not, there are folks out there (maybe they are new to all of this) that don’t have this valuable tool deployed in their organization - these folks will want to read all of this post. One of the benefits of WSUS for the smaller organizations is that all that update traffic only has to cross your WAN link one time - thereby creating a situation where you have helped optimize your network without incurring any fees.
First off, you need to have WSUS installed. Once you have that done, you need to configure a Group Policy to apply to servers, and maybe your workstations, so that you can control the update distribution and application process. After the GPO is created and applied, then you need to jigger a few settings inside of WSUS and exercise a bit of patience, and you will have an operational patch deployment system for your OCS deployment. Keep in mind that this same WSUS deployment can be used across your organization to deploy patches to operating systems, servers (like Exchange, SQL, OCS, etc), and workstations (keep that Office install updated!). I will cover only the OCS aspects, but I will also demonstrate Exchange 2007. So, the overall process is as follows:
- Install WSUS
- GPO work
- Configure WSUS
- Relax while everything catches up.
To get started, get a copy of WSUS. Install it on a server that is a member of your domain. You can have non-domain members point to a domain WSUS server, but i will not cover that here. For my lab, I installed WSUS on an x86 WS03 R2 SP2 server. WSUS needs IIS, so make sure you plan for that. WSUS works just fine from virtual - make sure that you give the VM a good 30GB to allow for the downloads of patches and updates. Sometimes the service packs that get downloaded get a tad sizeable - you will want some breathing room.
Did I mention breathing room? this is what my WSUS server is downloading…and I have an abbreviated update scenario…
My VM is running on 512MB of RAM, and I have tested operations as low as 192MB - response gets a tad slow, but the overall function of the WSUS is not materially affected. Out of scope for this blog is how to actually install WSUS; even I have space limitations!
Once you get WSUS installed, you need to configure the following items. Fear not, most of these are pretty straightforward, and not all of them need any changing for a basic installation. The install itself will invoke the wizard that is the bottom option, and just working through that will connect you, enable downloading of updates, patches, and service packs. I have mine running out through my standard ISA 2006 firewall. Because my firewall allows all internal traffic outbound, I had no connection issues.
The important part to us in this blog is the “Products and Classifications” selection.
Here you can see where I have chosen to keep my Exchange 2007 organization updated.
Here are the OCS specific selections. Note that the Office Communicator 2007 is also listed. Choosing this option will allow you to keep those client workstations updated without having to figure out how to push MSP files out to workstations.
Now that we have WSUS installed, and configured at the basic level, let’s turn to the GPO aspects of this project. I will discuss this work as based on a WS08 domain controller. If you have WS03 domain controllers, the details of “how to” will be a bit different, but nothing serious.
First, access the Group Policy Management applet.
In my case, I only have one policy. I do everything out of the default domain policy as I have a fairly simple setup. Open that policy for editing.
The GPO has two sections, computer and user. We want to configure settings in the Computer Configuration section. Expand Policies | Administrative Templates | Windows Components and then look all the way down at the bottom. Most likely, you will have to scroll down to find “Windows Update.”
There are quite a few options. You will need to configure them for your specific environment. We are most concerned with the following:
- Configure Automatic Updates (I set mine to three - you will most likely want setting four)
- Specify intranet Microsoft update service location Properties (mine is set to http://WSUS
- Automatic Updates detection frequency
- Allow non-administrators to receive update notification
- No auto-restart with logged on users for schedule automatic updates installations
- Enable client-side targeting (bingo!)
This last one is where you get to play a bit - I segregate by servers and workstations. I want workstations to install and don’t ask questions. I want servers to download and then prompt me for what I want to install. While this works for the lab environment, it may not work for you. However, if you want something like this, you will need to enter some group names here, and the names need to match what we’ll put into WSUS in the next step.
Here are my entries for the last property.
When you get done, just close up the editor. GPO settings are saved behind your back, and on the next update cycle, the entire domain will get the change to Windows Update. If you don’t want this behavior, you will need to go through the process of creating a separate GPO, linking it to containers, domains, etc, until you get the configuration that suits your purposes. By default, in a WS08 domain, the workstations will update themselves every 90 minutes with a random offset of 30 minutes. Or, you can go to each server and workstation and do a “gpudate /force” - me? I did this work and then went to lunch. When I came back, all machines in my domain were updated and ready to move onto the next step.
OK, back to the WSUS server, and let’s assign computers to groups, and configure the groups and approvals.
Configuring groups is easy…click on the indicated spot, and create some groups that represent your organization and how you intend to administer updates. Again, in my case, “servers” and “workstations” are the only two I need.
To assign the computers to groups, refresh your view or exhibit the aforementioned patience.
Here you can see my domain member servers as unassigned. Select one or more, then right-click to bring up the following dialogue.
In this case, I selected “servers” and clicked on OK.
Now all my servers that have reported in are in the Servers group.
What do these group do for me? Well, they control how you apply your updates! Seems pretty simple after you get done, but it is a perfectly logical question. Good for you for asking it! Over in the Options node, there is this Automatic Approvals wizard…I have two rules, one for the Workstation group, and one for the Servers group. I always remove the default rule, and create my own. If you have used rules in Outlook, you will have no issues creating and applying the rules here.
Let’s approve some updates, shall we?
The approval process is a matter of you reviewing what is there, approving or disapproving or declining, etc. For instance, I don’t ever let the automatic update routines download drivers - I have seen too many issues with drivers and automatic updates. But to the point, look what is in my synchronized, local update store!
The first time you go through the approval process will be a tad tedious, but after that, a short weekly session should be all it takes to keep your servers and workstations updated. When the computers check into the WSUS, the computer reports in and catalogs itself just like it was communicating with the Microsoft Update site and pulls down only what it needs provided you have approved the update. Should the update need a reboot, your GPO will control that - which is why I have my GPO set to “3” so servers do not boot themselves at the end of an update cycle. Your domain needs, of course, will differ from my simple lab.
Now that you have your Exchange and OCS patching automated to a large degree, enjoy some time off for research tasks, keeping your service customers happy, and maybe having a weekend off!