For a long time now Windows Server Update Services from Microsoft represents the best possibility to handle, distribute and install updates in your Windows platform. Over the years WSUS scalable and stable architecture find its way to be one of the most mature Windows Server roles.

But still any platform always can be improved a little bit more: adding some missing functionalities, more automation process, scaling up the possibilities by expanding the scope. WSUS it’s not an exception, that’s when I met EminentWare WSUS Extension Pack.

Here are some of the features included:

• Deploy and manage 3rd party applications and updates. You can integrate in your WSUS console all the necessary 3rd party applications (like Mozilla Firefox, Adobe Reader or any installer/update as EXE, MST or MSP) and their updates.
• Improvements in WSUS reporting.
• Inventory features. You can handle system details for over 200 systems and easily identify rogue machines.
• Keep scaling up! Flexible machine selections, granular approvals, immediate updates, precise scheduling, and even more.
• Update! EminentWare Extension Pack now available in 64bit systems. EminentWare’s console and server now run on x64 systems extending the power of WSUS and SCCM with enhanced patch scheduling & control, reporting, and 3rd party patch management. More info here: https://www.eminentware.com/cs2008/media/p/736.aspx 

If you are familiar with the WSUS administration then I’m pretty sure you’ve asked yourself about the features mentioned above.

Ok then, let’s take a look into the product.

EminentWare Components

Before starting to review the product, here’s a little explanation about the components included in the extension pack.

• Data Grid Server: This is the main component, responsible of scheduling and executing tasks in the EminentWare system. This service contacts directly with WSUS to retrieve all the necessary information; also talking to the WMI providers
• Administration Console: MMC 3.0 integrated directly with WSUS.
• WMI Providers: These are the components, installed on each client, in charge of automating the process and collecting the information from managed computers.

EminentWare Extension can be installed on the same server where WSUS resides, but it is recommended to use a dedicated server.

This recommendation applies for most production environments, since EminentWare process and WMI queries could be a significant load if we are talking over 500 clients. Also the use of the EminentWare database, different from SUSDB, could cause a bottle-neck in your server.

For more information check the EminentWare WSUS Extension Pack Deployment Guide.

EminentWare Requirements

Hardware

• Memory: 2GB as separate server. 3GB (recommended) WSUS with EminentWare.
• Disk Space – System Partition: 1GB.

• Disk Space – EminentWare Database: 2GB.

Operating System & Software

One of the interesting options from this extension pack is that can be installed on a desktop or server operating system. The following are supported:

• Windows XP Professional SP2 or superior.
• Windows Vista Business, Enterprise or Ultimate.
• Windows Server 2003 SP1 or superior.
• Windows Server 2008.

Regarding software

• WSUS MMC 3.0 installed. If you are not deploying EminentWare on the WSUS server, the machine must have the WSUS console.
• .Net Framework 3.5 and Visual C++ Runtime library. If it’s not present, the EminentWare will automatically install them.
• Local SQL Server 2005 instances. If it’s not present, a SQL Server 2005 SP2 Express (free product) will be installed. 

Note: 64bits operating systems are not supported (even though the product can be installed).

EminentWare Installation

The installation process it is quite straight forward and you should not have any problem. Here are some of the important steps:

1. SQL Server Instance: The product does not support installing the EminentWare database on a remote SQL Server, that’s why will try to find a SQL Server 2005 instance locally or you can install directly a SQL Server 2005 Express to store the database.

2. EminentWare Server Configuration: If this is your first server, the “Primary Application Server” must be the option for selection.

The other options available, when there’s an existing Primary Application Server, are “Application Server” (for load balancing), “Management Server” (different Management Group) and “Automation Server” (in charge of executing only tasks for a dedicated Management Group).

For more information check the EminentWare WSUS Extension Pack Deployment Guide.

EminentWare Initial Configurations

After completing the installation and registering your trial version, once your run the EminentWare WSUS extension, the first thing to do is to select the domains and/or workgroups to manage.

1. Environment: In my case I’m only adding AALVAREZ domain and after that selecting my WSUS existing server.

2. Credential Ring: Here’s where you select the users that will be in charge of connecting to the machines and servers to retrieve information, execute tasks, etc.

An important note is that you can select multiple type of users and define which one applies for what: Different domain users and even local users for special cases, like a workgroup (for local users use the format “.\Administrator”).

EminentWare Publishing 3rd Party Applications

Possibly the hottest feature in the product is the possibility to distribute and update third party applications, which WSUS treats them as any other update. Let’s take a closer look.

You can find and interact with the third party packages (as for any package you want to create) in “Administration and Reporting” > “Software Publishing” > “Packages”.

You can directly download from EminentWare a sample catalog for 3rd party software and updates that you can easily import and have a bunch of the most commonly used software ready to go. Some of the included are: Adobe Reader, Mozilla Firefox, QuickTime, Adobe Flash Player and Java Runtime.

Let’s take a quick look about the process of creating your own customized application to be distributed:

1. I’m going to create a package for WinRAR application, selecting “New Package”, the wizard will appear requesting information about the application.

2. You can add some Pre-Requisites rules before applying the application. You can create or use some the existing rules like “Windows Version”, “Windows Language” that the target machine must fulfill before receiving the package.

3. Select Package. Here you’ll complete the information about the package type and location. In my case I’m using an .EXE file and I have the content locally and on a share folder. Also you can set the EXE file parameters, like “/quiet” for a silent installation.

4. Applicability Rules. Are similar than the pre-requisites, you can add some more granular options for targeted machines, like applying the package just if a registry key exists. In my case, none in particular.

5. Installed Rules. This will be the “exceptions” values. Whenever the following rules apply, the package will not be installed.

For WinRAR, I’m using if the registry value “HKEY_LOCAL_MACHINE\SOFTWARE\WinRAR” does exist, do not install the package.

6. All done; now you can select the package from the list and publish it.

EminentWare Inventory and Reporting

Reporting capabilities represent a big feature in most products. Having a strong and scalable solution to sort and describe the information within a platform makes products far more close to the persons that are managing it.

WSUS reporting capabilities are significantly high, but EminentWare takes that and goes a little further integrating with great inventory features.

For example, taking a look to the Updates section you can retrieve some nice granular information about the updates. Selecting an update, you can quickly verify which computers have it installed or on which the update failed.

Take a look to the drag-n-drop section, where you can add the filters you want to sort all the information in the way you need it.

Combining the reporting options with the inventory information you can get some amazing results, and using just some out of the box reports. Here are few samples:

Retrieving machines Firewall status

Hardware: Memory information

This is a nice troubleshooting tool: Available computers that were not successfully connecting to using WMI.

And if you want to see some really detailed inventory information, you get the chance from each computer to receive the information about:

• Installed software: Where you can also uninstall programs.
• Windows updates log: Remotely check the updates logging and looking for errors directly on the machines.
• Services console and processes running. And of course disabling or stopping any of them.

Services available

Processes running

And even more, some interesting endpoint tasks:

• Shutdown or reboot the remote computer.
• Remote Desktop.
• Wake on Lan.
• Windows Update Agent Maintenance and Repair. One of my favorites, you can run some of the most used tasks regarding WSUS with just one click: Reset authorization (regenerating the WSUS cookie), flush BITS cache, reset SUS Client ID (for duplicate clients, which BTW can easily find using a report), delete software update folders, and more. 

Conclusions

As you can see, this extension pack it is a big one. We just had the chance to name some of the most important features and options available, but there are many more to observe. Let’s wrap it up with some of what we’ve discovered:

• The 3rd party updates and distribution has been some of the most wanted WSUS features, that’s a fact.
• Talking about easy-to-work-with products, the 3rd party updates catalog which you can import simplifies a lot of work.
• The inventory features could provide you some information and control over your environment that you possibly are not handling right now.
• Incredible scalability with the tasks features. Direct actions can take place with remote computers. Or you can schedule any task to run on daily, weekly or monthly basis; including some an important one like the “WSUS Clean Up Wizard”. Also you can easily monitor the tasks status and behavior.
• The out-of-the-box reporting: Nice embedded reports ready to use and export them or send it over e-mail directly.
• Big and robust product. Even though this is what we look for in scalable platforms, one thing that would increase the usability of this product is to have the possibility to only use some of the features available. Small or mid-sized companies with no big requirements, would not take advantage of some of the important features presented here because it could be too expensive to maintain it.

Hope that you found this information useful, that’s pretty much for now.

Cheers!

Windows Server Update Services 3.0 SP2 Beta.

You will find all of these resources to download:

• WSUS 3 SP2 Beta x86 and x64 compilations
• Beta Scenario Instructions
• WSUS 3 SP2 Beta Deployment and Operations Guide.
• WSUS 3 SP2 Beta Step-by-Step Guide

WSUS 3.0 SP2 Beta Overview

New Windows Server and Client Version Support

• Integration with Windows Server® 2008 R2
• Support for Windows 7® client
• Support for the BranchCache feature on Windows Server® 2008 R2
  BranchCache is a new feature in the R2 version improves significantly end user experience at branch locations, by locally caching frequently used content on the branch office network. More info here on this document.

Auto-Approval Rules

• New functionality lets you specify the approval deadline date and time.
• You can now apply a rule to all computers or to specific computer groups.

Update Files and Languages

• This release provides improved handling of language selection on downstream servers. 

Cross-Version Compatibility

• The user interface is compatible between Service Pack 1 and Service Pack 2 for WSUS 3.0 on both the client and the server.

Software Updates

• Stability and reliability fixes for the WSUS server, such as support for IPV6 addresses greater than 40 characters.
• The approval dialog now sorts computer groups alphabetically by group name.
• Computer status report sorting icons are now functional in x64 environments.
• Fixed setup issues with database servers running Microsoft® SQL Server® 2008.

Even though it’s only a Service Pack, includes several improvements and new compatibilities. We’ll check them out.

You can always check any updates about WSUS on the WSUS Product Team Blog.

Cheers!

Sometimes, for example if you are just spiking about WSUS and you don’t want to install any version of SQL Server, you best choice would be the Internal Database option. But what happens if you change your mind later and you want to change the location of that internal database to a different drive? Or simply executing other tasks on the database, like generating a backup or shrinking?

Fortunately there’s a way to connect to that DB without having to re install WSUS:

Using SQL Server Management Studio

Note: If you don’t have it, you can download the stand alone tool for SQL 2005 version: Microsoft SQL Server Management Studio Express; or you can download SQL Server 2008 Express Edition (the latest of the free SQL Server versions, includes among the tools the SQL Server 2008 Management Studio Express).

1. Open SQL Server Management Studio. In my case, I’m using SQL Server 2008 Express Edition.
 

2. Using the connection window, connect to this instance:
\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
 

3. You should see now in Object Explorer the database instance connection. Right-click on SUSDB –> Tasks –> Detach
 

4. Check the options for “Drop Connections” to remove all active connections to that DB. Click OK.
 

5. A message saying that the DB is not accessible should appear. Click OK.
 

6. Move the database files to the new drive or location where you are planning to keep it.
 

7. Back to the instance connection. Right-click Databases –> Attach.
 

8. Click on “Add” and select the .mdf folder where you relocated the database.
 

9. Click OK to attach it again.
 

10. Your database should be working now on the new location.

Using SQL functions / SQLCMD

Note: If you want to use SQLCMD command line utility you can download it from the Microsoft SQL Server 2008 Feature Pack, where you’ll find plenty of SQL utilities.

1. Run “cmd” and locate it where the sqlcmd executable is. Usually: %Program Files%\Microsoft SQL Server\90\Tools\binn.

2. Type in “sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query –E” press Enter.

3. You are now connected to Internal Database instance. Type “EXEC sp_detach_db @dbname = ‘SUSDB’”.

4. On the next query line, type “GO” and press Enter.

5. Exit the SQLCMD utility. Type “EXIT” and then type “GO”.

6. Move the database files to the new file location.

7. Reconnect to the Internal Database instance: “sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query –E”.

8. Attach it again: “EXEC sp_attach_db @dbname = ‘SUSDB’, @filename1 = ‘<path>SUSDB.mdf’, @filename2 = ‘<path>SUSDB_log.ldf’”.

9. Exit the SQLCMD utility. Type “EXIT” and then type “GO”.

Even though you now know how to access the internal WSUS database, I would recommend to migrate this internal database to a SQL Server database if you have the chance, and remember that you can use the light and free version of Microsoft database engine: SQL Server Express Edition (2005 or 2008 version).

To execute the migration check this link:

Migrating from Windows Internal Database to SQL Server

Hope you find it useful!

Cheers!

Why is this happening? Because by default WSUS only receives and distributes drivers that are digitally signed by Microsoft (meaning that the driver was fully and properly tested by Microsoft).

I’ve recently had several problems with machines that are part of my domain, like the newer IBM ThinkPad T60 and T61 models with Vista installations. Some of their drivers were missing and I had to use IBM official site to download them because WSUS did not recognize any updates on that machines.

But you actually don’t have to worry, within a few steps you can configure your WSUS to import all the drivers that you are requiring by your clients. The only thing that must be clear to you first is the model of each device you need to update the driver (you can easily find out all the details by accessing the manufacturer’s official site, like IBM Lenovo downloads and support site).

Here are the steps:

1 – Open your WSUS console and access “Action” and select “Import Updates”.

The Microsoft Update Catalog site will appear

2 – Insert the model of the device that you need to update the driver. For example: “Mobile Intel 965 Express”. A list with all the drivers for that device will appear and ordered by release date.

3 – See for the latest drivers according to your product and select “Add”.

4 – Do that for all the drivers you need and when you finish go to the basket option.

You will see a summary of all the updates you’ve selected

5 – Leave checked the option “Import directly to Windows Server Update Services” and select “Import”.

Now all the drivers’ updates that you selected will be importing to your WSUS.

6 – When this procedure finishes, the clients’ machines will need to inform about their updates status again. So, from a client machine that needs any driver that you’ve just imported, access the cmd and enter “wuauclt /reportnow /detectnow”.

It may take several minutes to the clients’ machines to inform about the status of the updates that are required.

7 – From your WSUS console check on the client’s updates status and you will find all the new updates that can apply to this machine.

You can now approve them and distribute to your test or users machines.

Hope you find it useful!

Cheers!

Once you get to know the WSUS interface, you’ll see that everything it’s pretty much intuitive. You have to know that when there are tools like WSUS involved, the process of patching that you defined (testing the updates, defining how and when you’ll apply those updates, period of time involved, etc.) is the crucial matter to get WSUS work as you planned. In this case, the process it’s even more important than the technology.

Let’s take a final look to the group policies. We already talk about that it’s a common best practice to implement different layers of GPOs, but which are the ones that you actually have to enable for each OU? This is an example of a GPO applied on an OU with all the testing computers.

We decide that in those testing computers the updates will download and install automatically at a certain hour of the day. But what happens if that computer is not available at that time? Then you must use the option “Reschedule Automatic Updates schedule installations”, when you enable it, you can set that the updates will install on those computers at the moment that they become available again (you actually have to set only the minutes that Automatic Updates will wait after the startup).

If we applied a common GPO over the domain, and we set the WSUS server on that policy, then there’s no need to configure the intranet location of Microsoft Update on this GPO.

The “Enable client-side targeting” GPO it can be really helpful to you, meaning that all computers that you move to this specific OU will automatically join the WSUS group that you define in this GPO. But the policy can’t do the job on its own; you must also change the “Computers” entry on the “Options” item of the WSUS console. It must be set to “Use Group Policy or registry settings on computers”

It’s always recommendable that you take a look to all the GPOs explanations to see that if they apply for your environment.

If you set different GPOs for Servers, Domain Controllers, Mobiles, Workstations, etc; they shouldn’t be much different.

Before setting any other GPO on others OUs, it’s good to remember some of the points that we discussed in the previous WSUS posts: about when to apply the option of “Schedule Install” of the Updates without any intervention of the user.

You must be careful on setting that option to your organization users, if there’s an open session at the moment of installation, depending on the updates, the process can take a lot of the resources of memory, disk and processor.

You must also be careful on the moment you choose to install on your servers. For example, you plan that in your working hours you will install the updates (that you already tested) on your servers, and restart them later at night. But you have to know that some of the critical updates of SQL Server, for example, can actually stop the services when you install them, and to take back online the database server you must restart the computer first.

Let’s take a quick look to some of the WSUS options:

Automatic Approval

This is probably a great option to use when you are working with a test phase before approving any updates to production. This is an example of a rule created to approve for my own group of testing computers “Staging” almost all the available updates.

Express Installation Files

Basically an update is a new version of a file that you already have on your computer, so when a user wants to install an available update, downloads the complete file and installs it on his computer. An express installation file represents the “delta” between the version of the file that you already have and the updated file.

You can use express installation files to limit the bandwidth consumed on your local network, at the cost of bandwidth consumption on your Internet connection and disk space.

Why the Internet bandwidth increase if I only want the deltas? Because the files that need to be downloaded from the web, must contain all the possible deltas of that file. You may triple the size of a regular updates download if you implement the express installation files, but you gain on the cost of bandwidth when you install those updates.

Maintaining your WSUS Server

There are several options and tools that are included with WSUS console, which can really help you maintaining the health of your server.

Server Clean Up Wizard

This option you can run it periodically to delete, for example, old updates (replaced for new versions), updates that are not needed, etc.

E-Mail Notifications

This can help you check the status of WSUS updates in a brief summary and without accessing the console. Here’s an example of the report that is send, in my case, daily

To Do List

The “To Do List” you can find it on the root of the WSUS console, where an overview of all the status is available.

The To Do List shows some of the things that you should take notice. In this example, there are computers that, by group policy, have requested join to WSUS groups that doesn’t exist.

Command Lines to remember

Whenever you apply different options, policies or both with WSUS you always want to know if the changes are made as you plan. The GPOs usually takes to 90mins on client computers to be applied, so if you want to see the reaction on a client with a group policy remember to use on the client this command-line:

gpupdate /force

And when you try to see what happens with the updates, there’s a command line that you can use to automatically ask the WSUS server for new updates:

wuauclt /detectnow

Remember, if you have set to download the updates automatically on the clients, to see if there are new updates available, you must wait until the client downloads all the updates and then the notification will appear.

If you just moved a client from different WSUS groups or you are suspecting that something is wrong on the client side and detection of the updates, run this:

wuauclt /resetauthorization /detectnow

WSUS uses a a cookie on client computers where it stores some of the clients configuration, like group membership (this cookie expires an hour later from its creation). Using the /resetauthorization will automatically expire the cookie and look again for the client configuration.

Troubleshooting Clients

Some of the things that I recently ran into when I tried to install some critical updates is that several of computers appeared on my WSUS console with errors installing those updates. The problem seemed very strange because every time I tried to install the update, manually or automatically, it failed.

Taking a look to the problem I also found out that in all of the clients that a message of “Low Virtual Memory” also appeared.

If you are thinking that the problem is that the clients do not have enough RAM, you are wrong.

Don’t worry, there’s a solution to that problem, install this hotfix (for Windows 2003) on those client computers and the problem should be solved. You can find more information here:

http://support.microsoft.com/kb/925336/en-us

I guess this is pretty much it about Windows Server Update Services 3.0.

Any comments or questions are welcome.

WSUS 3.0: Deployment and First Configurations (Part I)
WSUS 3.0: Deployment and First Configurations (Part II)

Cheers!!

· 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.

WSUS 3.0: Deployment and First Configurations (Part I)
WSUS 3.0: Deployment and First Configurations (Part III)

Cheers!

WSUS 3.0 Overview

Step-by-Step: Getting Started with WSUS 3.0

Deploying WSUS 3.0

This post it’s intended to help about the WSUS first configurations and recommendations about how to use it.

When you install WSUS, the configuration wizard it’s pretty much self explained and with the Step-by-Step guide you shouldn’t have any problem.

The first warning that we can make at this point it’s about the “Specify Proxy Server” step. If you have one on your network, like an ISA Server 2006, remember that this server use the 8080 port when it works as a proxy. Configure this port on the WSUS, otherwise your connection will fail.

Always remember when you are selecting the languages of the updates and the products that you want to receive these updates, you should only select the ones that you actually need. Otherwise the duration of all synchronizations with Windows Update and the WSUS server will increase significantly.

Note:
The first synchronization of the WSUS server always takes a lot of time.

When you have your WSUS server online it’s time to configure your environment. Here are some of the best practices:

Best Practices

· Test phase first

Before applying any patch on your users’ computers or servers, you must always have a stage environment. Replicating all base computers or servers from which you will apply these updates. For example, using some Virtual Machines.

· Different users and different computers means different policies

If you are working with different type of clients on your organization (like with different OS, different schedules, etc) you should consider to set these clients with different policies to apply those updates.

You can accomplish this assigning, first, different Organization Units for workstations, mobiles, servers, etc. And then applying the correct Group Policies to each organization unit. You will add more layers to these configurations by creating different computers groups for approving updates.

· No computer, by any circumstance, must use Windows Update over the Internet

Apply different GPO levels that can assure you that any user or computer that it was just added to your domain use your WSUS server as the update point.

For example, in this case we apply a GPO for the domain that only specifies that the Windows Update process should be done only with our WSUS server; and on the different OUs of contoso.com we apply more restrictive policies for each case.

· Keep track of the updating process

Installing and configuring WSUS on your network won’t magically solve or improve all of the updates implementation. Be careful on the policies that you apply on which users and follow periodically the patching process. WSUS 3.0 improves significantly the reports view, making it easier to find out how many computers needs important updates.

Like this example: Shows all Vista Security Updates that are not installed yet on your computers groups.

I’ll be revisiting some of these best practices in other posts.

WSUS 3.0 Deployment and First Configurations (Part II)
WSUS 3.0 Deployment and First Configurations (Part III)

Cheers!

Sign up for testking 642-504 online training and learn everything about Microsoft wsus using testking 640-721 tutorials and testking 642-373 study guides.