Chris Sanders

I’ve always been a huge fan of using Microsoft Windows Server Update Services (WSUS) in the enterprise. It’s free and it’s the best way to effectively ensure that your workstations are up to date and secure. With the modern prevalence of client-side attacks there aren’t many things more important than keeping client computers secure as they can provide a perfect entry point for attackers into your network.
Although WSUS is great, it lacks quite a bit of functionality that it could benefit from. I’ve written a few articles about WSUS here and there and I’ve cited some of these shortcomings that include a weak management interface, a lackluster reporting system, and an inability to easily troubleshoot misbehaving clients. That being the case I’m always looking for enhancements to WSUS, and I’ve found one I really like from the folks at EminentWare who’ve asked me to review their software. Overall, I was really happy with the product and I have no qualms about recommending it to my sysadmin friends. In the sake of full disclosure I have to add that EminentWare is a paid advertiser on my site, but that in no way has any effect on my opinion of their product in this review.

The Basics

The WSUS Extension Pack adds quite a few useful features to a WSUS deployment. EminentWare released a list of the top 10 reasons you need their product, which can be found at http://www.eminentware.com/wsus-patch-management-extension.html. Some of my personal favorites include:

• Create your own packages to deploy any MSI, MSP, or EXE through WSUS

• Configure pre and post install implementation steps such as stopping/starting services, manipulating files, and running custom scripts.

• Discover rogue, unauthorized, or improperly configured machines.

That being said, the product has quite a bit to offer. EminentWare touts the Extension Pack by stating:

EminentWare’s WSUS Extension Pack extends the capabilities of your existing WSUS infrastructure, offering a powerful solution for deploying, managing, and reporting on updates, applications, and configuration settings throughout your IT environment. EminentWare’s WSUS Extension Pack adds key IT management functionality to your existing WSUS installations, allowing you to leverage existing technology to create a more flexible, more powerful enterprise patch management and configuration management solution that is extremely cost-effective.

Let’s take a look a deeper look at the extension pack.

Installation

As you would expect, EminentWare supports all of the major Microsoft server distributions so you can install it on any OS that you would install WSUS on. The website where the software can be downloaded from provides great resources for installation including a quick start guide and a short video that highlights the important parts from the guide. I skipped through the video quickly and perused the guide a bit before performing the install which seemed like it would be pretty intuitive.
The install itself went through without a hitch. Using the Express Installation option, the installer guided me through the process of installing prerequisites, creating a SQL instance, and creating a service account. The actual installation was just a few mouse clicks and less than ten minutes of waiting time. No reboots were required, which earns bonus points for me when we are talking about installations on servers.
After installation and activating my license I was presented with a series of wizards used to configure the WSUS infrastructure. The first wizard caused me a bit of trouble as it wouldn’t automatically find my domain, but I was able to enter its information in manually and proceed forward.

Figure 1: Defining the WSUS server during the initial configuration

After adding domain credentials for the product the installation was completed.

Management and Features

The management screen is built as an MMC so Microsoft sysadmins will feel comfortable working within its borders. The overall look and feel is very similar to that of the standard WSUS administration snap-in which I consider a plus. The expansion pack has more features than I ever knew I wanted, so I want to hit on a few of the ones that really struck my fancy.

Group Policy Management

I love group policy, but it’s not the easiest to use or the most user friendly. One of the parts I disliked the most about traditional WSUS setup is having to deal with the uncertainty that is group policy. The expansion pack provides a front end to the group policy settings related to WSUS so you don’t have to waste time digging around in GPOs. You can configure the local and remote policy settings for Windows updates and even refresh group policy remotely.

Status Bars and Reporting

This one may sounds a little lame, but the biggest pet peeve I’ve ever had with WSUS is its lack of progress bars and status reporting for the tasks you perform. Whether it be installing an update, refreshing policy, or remotely rebooting a computer the expansion pack adds usable, reliable status reporting of tasks.

Figure 2: The detection task provides a robust status display

Wake on LAN

This one is pretty self explanatory. If you need to apply a critical security update to a computer that is turned off at a remote site fifty miles away then WOL is your life saver. The expansion pack provides a simple and easy to use interface for utilizing this. Anything that saves me this kind of time is alright in my book.

Credential Ring

I harp on software vendors all the time because they tend to force you to create a service account for their product, make you give it domain admin rights, and use it for everything related to that software. The EminentWare guys really got this one right with their concept of a credential ring. This allows you to create service accounts with different levels of domain access and assign them to specific devices and device groupings. This way, you can specify site, department, or OU based administrative accounts rather than having yet another service account sitting there with the keys to the castle. I wish more software companies would do something like this!

Figure 3: Using the credential manager to specify credentials for particular devices

Reporting

Creating reports isn’t fun but its often the only way an IT department can bring thing to a managerial level to justify their results and expenses. The expansion pack provides a great deal of needed flexibility in reporting that was able to handle just about everything I could ever think of having a need to report. In some cases this alone could justify the cost of the software.

Device Discovery

The discovery option lets you specify an IP range or subnet that can be scanned for hosts. The results of this scan can be used to find new computers on your network that are not receiving updates or rogue devices that shouldn’t be there. This comes in handy with large networks where it’s hard to keep a handle on new devices or ones that get formatted/imaged often.

Third Party Updates

The ability to use WSUS to deploy third party updates is perhaps the most powerful aspect of the expansion pack. The framework Microsoft has built for deploying software to devices is so robust and effective that it would only make sense that you should be able to use it for the deployment of other updates. Using this feature you can configure updates for products such as Acrobat Reader, Flash, Quicktime, Firefox, Java, and more. Once again, as a highly security conscious individual this feature is worth its weight in gold and I can’t speak highly enough about it. One of the guys at EminentWare demo’d this for me and I was blown away; even more so when I did it myself.

Conclusion

I’ve reviewed a lot of products over my years as a systems administrator and network security analyst. At this time, I’ve never reviewed a product that I’ve loved as much as the EminentWare Extension Pack. WSUS is beautiful, but this product takes it to a whole new level. If I were to give it a rating I would give it a perfect five out of five. The expansion pack is the only thing like this in the market (that I’m aware of) and it is just so wonderfully done. The developers clearly talked to system administrators and found out what they thought was missing from WSUS in order to fill the void and then some. I’d probably buy the software just based upon the third party updates feature alone, but with the added administration and management features its takes the cake. Simply put, if you manage a Windows network of any reasonable size you need WSUS and you NEED the EminentWare Extension Pack.

Derek Melber wrote a great little article about the top ten security settings to make directly after installing Active Directory. I’d recommend all of these. Our server guys here actually have a very similar procedure they follow when creating a new network.

Read the full article here.

 I write a lot about WSUS because I think it is a necessity for any network with Windows servers or clients. It is typically pretty easy to setup but occasionally you will run into some issues. Out of all of the WSUS issues I hear about and directly experience (and trust me, I manage a LOT of WSUS servers) the most common problem I hear is when the computers in a network simply don’t connect to the WSUS server.

Here are a few items which are the most typical causes to this problem:

Lack of Patience

This is the number one overall issue I see. WSUS is built upon a technology that is by no means instant. It takes some time for updates to download, it takes some time for Group Policy Objects to apply, and it takes some time for computer to report in to WSUS in general. That being the case, if you have just installed WSUS and are looking at this article two hours later because computers aren’t reporting in, then you most likely haven’t waited long enough. I generally tell people to wait as long as two days after installing WSUS to start looking into why individual clients aren’t reporting.

Group Policy Issues

One of the simpler problems is that either the Group Policy Object for configuring the automatic update service is not being applied or it is misconfigured. At a minimum, your GPO should be configured so that it points the automatic update service to download from the WSUS server. Make sure you don’t have any typos in this path.

You can make sure that your GPO is being applied to the computer in question by typing GPRESULT into a command prompt on one of the machines in question. Remember, the Group Policy setting for configuring automatic updates is to be applied to computer objects, not users.

Client Requirements

WSUS clients must be Windows 2000 SP3, Windows XP, or Windows Server 2003 in order to take advantage of WSUS. I’ve seen lots of cases where someone would tell me a bunch of their workstations weren’t reporting in and updating only to find out they were Windows 2000 SP2 or something like that.

Imaged/Cloned Computers

In some network most if not all of the workstations were deployed with system images via Acronis, Ghost, or some similar program. If that’s the case, there is a good chance that the WSUS ID, a unique identifier found in the registry of every computer on your network, was not regenerated. These WSUS IDs are generated based upon the SID of a computer. If you configured your image so that it would generate a new SID upon pasting then you likely won’t have this problem, but this step is commonly forgotten. The WSUS ID is stored in these three registry keys:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAccountDomainSid
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdatePingID
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateSusClientId

In order to generate a new WSUS ID, you will need to delete these keys on the client machine in question. After doing this, restart the Automatic Update service and run the command “wuauclt.exe /resetauthorization /detectnow. You should see the computer in the WSUS console shortly after that.

This process may seem a bit too manual when you have to perform it on multiple computers, so there is a VB script that can automate this a bit. You can download this script here: http://www.vbshf.com/vbshf/forum/forums/thread-view.asp?tid=199&start=1. You can simply download this script and perform the aforementioned steps remotely by just entering the computer name.

This covers a few of the most common reasons clients don’t report in. Obviously, there is no way to cover every possibly avenue, but hopefully this will eliminate some of the more common possibilities. As always, I respond to direct WSUS questions via e-mail. Also, the WSUS forums over at http://www.wsus.info/ are a great community driven resource for figuring out issues like this.

Dan Nerenberg over at TheLazyAdmin.com has just published a guest post from me about WSUS. If you have never heard of this site, then I’d highly recommend adding it to your daily reads. Originally started by former MVP and current Microsoft employee Rodney Buike, it contains a great deal of informative content.

The post is a detailed WSUS FAQ. If you are considering deploying WSUS but have some questions, then chances are that this FAQ will answer at least a couple of them. Check it out here.

If you have tried running the Windows Server 2003 Management Tools on Windows Vista then you have more than likely run into a problem or two. Microsoft has a KB article on how to fix a majority of these problems. See KB930056 here.

I have co-written another article with Mitch Tulloch for WindowsDevCenter on the topic of installing software with group policy. You can currently access this article on the front page of http://www.windowsdevcenter.com or directly by clicking here.

I have just co-written and article with Mitch Tulloch for O’Reillys WindowsDevCenter.com website on the implementation of mandatory roaming profiles and their best practices. You can view this article by clicking here or you can see it directly from the front page of http://www.windowsdevcenter.com.

There has been some recent discussion as to how to use Ghost to clone a machine running Windows Vista. I have tested this myself and found that doing a straight up ghost image push without any switches will not work. However, if you add the -fpsd switch to ghost.exe when pulling and pushing your image it will work like a charm. The -fpsd switch actually preserves the signature bytes on the hard disk rather than clearing them out. The clearing of these signature bytes is what causes Vista to go haywire when you try to clone it. I would imagine Symantec will clear this up in the v1.2 release of the Ghost Solution Suite. If you do have problems with this whatever you do don’t contact Symantec technical support. Windows Vista is not by any means supported by them yet.

User profile management can be a complete nightmare for a network administrator. There are literally dozens of ways to manage profiles based on the needs of your particular organization or department. One of the most complicated scenarios to properly administer is a typical lab environment in which you do not want user profiles to be modified at all. Through the use of mandatory profiles this type of profile administration becomes much easier.
For this example we will examine a typical University Campus. This small campus has one hundred computers spread across various labs. These are all Windows XP machines connected to a Windows 2003 domain. These computers are used by students to do research, type papers, and perform various other coursework. Along with these computers there are a total of 2000 students who each have their own unique user account. Our goal is to present each and every student user with the same profile settings, and disregard all profile changes when a user logs out so that they are presented with the same profile as everyone else when they log back in.

Step 1: Setting up the Base Profile
The first thing you will want to do is setup a model profile on a workstation (preferably an identical one to the workstations in the lab) that will serve as the profile that everyone sees when they log into a computer. Here you will want to make sure you have configured all desktop settings, shortcut icons, and installed printers correctly as to how they will appear on all other workstations.

Step 2: Copying the Profile to a Server
Once you have your profile setup how you want it, the next step is to copy the profile to a server. It is important that you set the permissions on the folder holding the profile so that all users accessing it will have complete read and write access to it. Once setup the workstations will pull each user profile from this location. In order to properly copy this profile to a server you will complete the following steps:

1. Login as a user other than the one you used to make your model profile
2. Right click “My Computer” and click “Properties”
3. Click the “Advanced” tab
4. Click “Profiles”
5. Select your model profile and click the “Copy to” button
6. Browse to the location you want to store the profile at
7. Click “Change” under “Permitted to Use” near the bottom of the window and add the “Authenticated Users” group
8. Click “OK”
9. Exit out of any dialog boxes that may remain open.

Step 3: Making the Profile Mandatory
The next step in creating your profile is the actual process of making it mandatory and therefore unchangeable.

1. Browse to the location of your saved profile on the server and locate the NTUSER.dat file (make sure hidden files are set to be visible)
2. Rename this file to NTUSER.man

Step 4: Configuring the User Accounts

1. Open Active Directory Users and Computers and browse to the location of the user or group of users you wish to assign a mandatory profile to
2. Right click the user or group of users and click “Properties”
3. Click on the “Profile” tab
4. In the “Profile Path” box type the UNC path to the folder where the mandatory profile is located
5. Click “OK”Exit Active Directory Users and Computers

With those steps completed you have successfully setup mandatory profiles for your student population. You may now reap the benefits of having a central location to store all of your user profiles so that they can be modified with ease. This also provides a great layer of additional security for your network. Mandatory profiles can also be extended upon greatly with the use of Group Policy, which is something that I would highly recommend looking into.

I have been focusing a lot of my efforts at the office lately to implementing our new IAS/Certificate based wireless security strategy. In doing this, one task I needed to complete was to set the Dial-In properties of the wireless client computers via the Dial-In tab in the Active Directory Users and Computers MMC snap-in. Needless to say, I was quite shocked when I went to make these changes, and I didn’t even have a Dial-In tab. After quite a bit of googling I found the problem lied in the version of the Windows Server 2003 Adminpak that I was running. There was apparently a new release of the Adminpak for Windows 2003 Server SP1 and without the new version, a few tabs will be missing. The Adminpak is MUST HAVE resource for anybody who manages a Windows Server 2003 network. You can download the Adminpak here.

Typically printer installation is done in the enterprise via login scripts that are based on usernames. This works fine in most cases, however, I recently began looking into a better way to do this.

The problem with installing printers based on usernames is that on a given day a teacher or student can log into as many as three or four different computers in various locations throughout a school. With this being the situation, we could for instance map the printer “GCHS-MATHLAB” to a student active directory account, but then when the student walks into the business lab, he will still be printing to the math lab. The obvious reaction to this would be to setup a script that installs all avaliable printers in the building for the student, however this creates an unneccesary security risk, and would allow students to print into room they are not located in which could cause trouble.

My first instinct for a solution was to install printers based on the active directory organizational unit by pushing a machine startup script. This would work perfectly as our active directory is for the most part organized by a computers physical location in a school. A machine startup script which can be found in the group policy editor under Computer ConfigurationWindows SettingsScriptsStartup is different from a login script as it is run on the target machine before a user even logs into a computer. After creating a GPO with my printer installation script set as a startup script I linked the GPO to a test OU where I began my testing. Unfortunatly, this setup didn’t seem to want to work. When the computers in the OU would boot up I would recieve a message stating the access was denied to add the printer. I knew that the problem was not with permissions accessing the script, because the error it gave me was actually on the 5th line of the script, so I know it was getting appropriate access to the file. The line it gave me the error on was the actual line that connected to and installed the printer. Sure enough, the “domain computers” group was added to the specific printers ACL, so that wasn’t the issue either. I had eventually determined that the issue with installing the printer this way was by design in windows as printers are typically managed in a user based context rather than a machine based one.

After a week or so of more research, I was about to give up when I stumbled upon some Microsoft documentation regarding something called Loopback Processing. In using loopback processing, you define settings for the User Configuration context of the group policy editor. After you finish setting these policies, browse to Computer ConfigurationAdministrative TemplatesSystemGroup Policy and select the policy called “User Group Policy Loopback Processing Mode”. Once you enable this policy you have two options to choose from. The first option is the “Merge” mode, which processes all user configuration policies as if they were machine policies AFTER whatever machine configuration policies that already exist are applied. The “Replace” mode however, does not process existing machine configuration policies, and only executes the user configuration policies. With this knowledge in hand I configured my printer installation script as a login script for group policy user configration, enabled user loopback processing merge mode, and sure enough, it worked like a charm.

A week or so removed from the discovery of loopback processing mode, I have found several other uses for it. I am actually considering changing site based drive mappings from being mapped via user defined scripts to being mapped via a group policy invoked script in order to avoid issues with teachers and faculty who roam among various schools in the district. I am also currently expiramenting with extending Mandatory user profiles via user loopback processing, so be sure to check back for my findings on that.

For more information regarding loopback processing, see the related Microsoft KB# 231287