The Windows Update Agent (WUA), in Windows operating systems since Windows 2000 Service Pack (SP) 1, provides a standard method to detect and report patch applicability for Windows and other Microsoft products—such as Office—on all Windows systems. Additionally, Microsoft updates the agent regularly to ensure it can properly detect the need for the latest available patches. You can configure the Windows Update Agent manually or through group policy to detect, download, and apply necessary patches automatically.

ConfigMgr 2007 uses the WUA to detect which patches are necessary on a system. This eliminates using separate scanning tools, which frees up the ConfigMgr administrator from maintaining these tools and Microsoft’s ConfigMgr development team from creating and testing them. Using the WUA also ensures consistent patch-scanning results between ConfigMgr, Windows Server Update Services (WSUS), and manual patching.

The ITMU is an add-on that never seemed to fit well with the rest of Microsoft’s SMS product. The ITMU incorporates a separate scanning tool to detect when patches are necessary on managed systems. On occasion, Microsoft has released separate scanning tools to detect if specific patches are applicable because the base ITMU scanning tool did not detect them. Using multiple scanning utilities causes the ITMU and Windows Update to detect patch applicability differently, occasionally causing discrepancies between the two tools when identifying necessary patches.

Both the ITMU and ConfigMgr deliver and apply patches using packages. The ConfigMgr packages (called update packages) differ from the ITMU because they have their own branch in the Configuration Manager console, displayed in Figure 15.1. Unlike ConfigMgr software packages (discussed in Chapter 13, “Creating Packages”), update packages do not have programs, although you must install the packages on distribution points (DPs) to use them.

Figure 15.1. Software Updates in the ConfigMgr console

The ITMU and Software Updates also download Microsoft’s catalog of available updates differently:

With a standalone installation of WSUS, clients are configured (either manually or with group policy) to report their status to a WSUS server and pull applicable updates from that WSUS server. Configuring when updates are installed is somewhat limited, particularly if group policy is not used. Reporting is also limited, and centrally managing and deploying patches to systems connected through a wide area network (WAN), Virtual Private Network (VPN), or the Internet is problematic.

Using Software Updates in ConfigMgr 2007 addresses the shortcomings of WSUS, eliminates the requirement for ITMU, and utilizes the now ubiquitous WUA. It also provides powerful and customizable reporting that integrates with ConfigMgr’s asset management and inventory capabilities. The next section begins discussing the steps required to start using this new tool.

WSUS is the only real prerequisite to enable Software Updates in ConfigMgr. Download WSUS and (as a minimum) install the WSUS Software Development Kit (SDK) on the primary site server; you do this by installing the WSUS administrator console. You must also install the WSUS server component on either the primary site server or another accessible server that meets the requirements for WSUS, as listed at http://technet.microsoft.com/en-us/wsus/bb466188.aspx:

WSUS also requires a SQL Server database. Generally, you use the same SQL Server installation for WSUS that you use for ConfigMgr. You can create a separate SQL Server instance for ConfigMgr to allow for granular resource control; however, this is not required as the instance of WSUS does not manage any client data and requires very little overhead on the database server, regardless of the size of the ConfigMgr installation.

WSUS 3.0 Service Pack 1 is required for ConfigMgr 2007 Service Pack 1 and Release 2 (R2) for installation on Windows Server 2008. Both 64-bit and 32-bit versions of WSUS are available.

Microsoft recommends installing WSUS on a dedicated server for larger sites. Each WSUS instance can handle up to 25,000 clients; for sites that are larger, you should deploy a Network Load Balanced (NLB) cluster to scale out the capacity of WSUS. Every ConfigMgr primary site must have a separate WSUS instance; this instance is optional for secondary sites to offload work and network traffic from the primary site WSUS server.

WSUS installation is straightforward and wizard driven, with the following guidance:

• Choose to store updates locally on the system rather than Microsoft Update, as shown in Figure 15.2. This setting allows WSUS to download and store license terms for specific software updates in the update content folder that you choose; ConfigMgr handles the actual download and deployment of updates. During the update synchronization process, ConfigMgr looks for applicable license terms in the content folder. If it cannot find the license terms, it will not synchronize the update. Additionally, clients must also have access to the applicable license terms in order to scan for update compliance.

Figure 15.2. Choosing the content folder during WSUS installation

• If using a dedicated system for WSUS, use the default website to host WSUS. If you are hosting any other ConfigMgr roles on the system, create a dedicated IIS site; although this is not necessarily a standard best practice and not a technical requirement, it is the opinion of the authors that a dedicated site keeps things nice and tidy and prevents any confusion over which site handles the WSUS responsibilities. The port numbers for a dedicated site are 8530 and 8531 for Secure Socket Layer (SSL) connections. Figure 15.3 displays these options.

Figure 15.3. Choosing ports during WSUS installation

• Click Cancel to skip the Configuration Wizard that launches at the end of installation. WSUS does not require manual configuration because ConfigMgr 2007 takes over the control and configuration of WSUS once you install a software update point (SUP).

You may use an existing WSUS server installation as an SUP for ConfigMgr; however, you should first delete the update catalog and associated metadata from WSUS to reset WSUS back to a clean state, thus allowing ConfigMgr to properly manage and control it. In addition, because ConfigMgr takes complete control over the WSUS configuration, do not configure any clients not managed by ConfigMgr to use this WSUS installation, as this is not a supported configuration.

Software update points play a key role in the process of distributing updates to clients. They do not actually deliver the update files to clients like a standalone WSUS server; rather, they download the update catalog from Microsoft (or another upstream WSUS server) and make the update catalog available to clients for compliance scanning. Therefore, adding at least one SUP is required to enable software updates. Adding an SUP as a role to a site system is similar to adding any ConfigMgr role to any other site system. To do so, perform the following steps:

Only steps 1–4 are applicable for child sites. ConfigMgr automatically configures SUPs in child sites to use the SUPs in their parent site as an upstream WSUS server. The child SUP downloads its entire configuration from the upstream/parent SUP as well as the update catalog. This is not configurable.

To review or change any of these settings after installing the SUP, navigate to Site Management -> <Site Code> <Site Name> -> Site Settings -> Component Configuration in the ConfigMgr console. Right-click Software Update Point Component in the right pane and then choose Properties to launch the Software Update Point Component Properties dialog box displayed in Figure 15.7.

Figure 15.7. The Software Update Point Component Properties dialog box

After you complete the wizard, ConfigMgr installs three primary components related to WSUS, as described in Table 15.1. These components immediately go to work; if you configured everything correctly, the synchronization process will begin.

An installed SUP can download the Windows Update catalog and associated metadata from Microsoft or an upstream server; the process is identical for either source. If a primary SUP cannot directly communicate with Microsoft to retrieve updates, you can manually import an update catalog from a server that downloaded the catalog from Microsoft. Both WSUS 2.0 and 3.0 use the same catalog format; this makes it possible to use either version to export the catalog manually using the same commands, as outlined here:

1. On the Internet-connected WSUS server, open a command prompt and run the following command:

   WSUSutil export <export filename.cab> <export log filename>
   

   WSUSUutil is typically located in the %ProgramFiles%Update ServicesTools folder. The export process takes from 10 to 20 minutes to run (potentially more), depending on your hardware. WSUSutil writes to the log file after the export completes. The file is in XML format.

2. Copy the export file to the SUP using whatever method is appropriate for your environment.
3. Open a command prompt on the destination WSUS server and run WSUSutil import:

   WSUSutil import <import filename.cab> <import log filename>
   

   The import process is more extensive than the export process and may take over an hour to complete, so be patient. As with the export process, WSUSutil does not write to the XML log file until the import completes.

To initiate synchronization manually from Microsoft or an upstream server, navigate to Computer Management in the ConfigMgr console, expand Software Updates, right-click Update Repository, and choose Run Synchronization.

Aside from the obvious manual intervention required, there are two differences between the manual synchronization and a scheduled one:

After a successful synchronization, WSUS imports the update catalog into the WSUS database. The WSUS Synchronization Manager (SMS_WSUS_SYNC_MANAGER) component of ConfigMgr initiates an import of the update catalog from the WSUS database to the ConfigMgr database. Synchronization of direct child site SUPs are then initiated and the process continues down the ConfigMgr hierarchy.

To configure specific Software Updates settings on client systems, open the ConfigMgr console and navigate to Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Client Agents. Right-click the Software Updates Client agent and choose Properties. This opens the Software Updates Client Agent Properties dialog box, where you can configure the following settings:

• Enable software updates on clients— The first setting determines whether the agent is actually enabled. If it is not, the client does not scan for updates and ConfigMgr will not deploy updates to it. As with other ConfigMgr Client agents, disabling the agent does not remove it from the client; this simply causes it to do nothing.

• Scan schedule— This setting determines how often to scan the client system for available updates. You can use the default schedule or configure a custom schedule:

• The default schedule is a simple schedule run every 7 days. The advantage of a simple schedule is it allows update scans to catch up when the system was powered off or unable to contact an SUP.

• A custom schedule gives you granular control over when to perform update scans. Scans on a custom schedule may not start for up to 2 hours after the specified time. The actual wait time for each client after the scheduled time is random and prevents client activity from overwhelming the SUP.

The scan schedule is completely independent of actual update deployment.

• Enforce mandatory deployments— If you use multiple mandatory deployments, your systems may also be subject to multiple reboots. Enabling this setting instructs the agent to install updates from all applicable mandatory updates on a system, in effect combining the deployments and reducing the number of reboots to one. The agent combines all deployments with deadlines up to 7 days in the future by default, although this is customizable, as shown in Figure 15.8.

Figure 15.8. Enforcing mandatory deployments

• Hide deployment from end users— By default, users receive a balloon notification from the agent indicating updates are available. Depending on your organization’s practices and policies, you may not want users to receive automated notifications. This setting allows you to disable the notification. You can also individually enable or disable the setting for specific update deployments.

The balloon notification allows users to initiate deploying updates at their convenience before a configured mandatory deadline. Also by default, the agent displays the notification to users at configured intervals according to Table 15.2. You can customize the intervals by navigating to the Reminders tab of the Computer Client Agent setting dialog box.

Table 15.2. Notification Intervals

• Deployment reevaluation— Update reevaluation scans ensure that old updates previously deployed to a system are still on that system. If ConfigMgr detects an update from a previous (but still applicable) deployment is no longer there, it immediately reinstalls the update. Reinstallation takes place without regard to maintenance windows and may be disruptive.

Using a group policy object (GPO) is the standard way to configure WSUS and the WUA. When you’re installing and configuring Software Updates, typical questions include the following:

You do not need to create a GPO to support ConfigMgr Software Updates. However, if you choose to create a GPO to support client installation (see Chapter 12, “Client Management,” for additional information on client installations) or use an in-place GPO, you must configure the Windows Updates server option to point to the active SUP in the site. This is because ConfigMgr creates a local policy on clients, pointing them to the SUP. A domain-based GPO overrides the local policy settings, causing software updates to fail on the client if the GPO does not specify the SUP as its update server. Additionally, an effective GPO must not disable the Windows Updates service or the WUA.

To avoid any possible conflicts, Microsoft recommends not applying GPOs that enforce Windows Updates settings to ConfigMgr-managed systems. If you use a GPO to deploy clients via WSUS, you should utilize Windows Management Instrumentation (WMI) filtering, security group filtering, or another mechanism to prevent these GPOs from being applied to managed systems.

Getting started with Software Updates can definitely be a bit confusing at first. The following example steps you through the initial configuration for a pilot group of workstations:

That’s it. The patches you selected and put into the All Windows XP and Vista updates list are now queued for delivery to your pilot systems and are automatically deployed at the time you specified for the deadline.

Going forward, every time Microsoft releases new updates, start at step 3 of this process, creating or using a new search folder to identify the new patches. You can use the search folder shown later in Figure 15.11 and described in the “Update Repository” section as a model, creating a search folder that shows only the newest updates each month or by whatever timeframe you choose. The flow chart in Figure 15.18 (later in this chapter) also reflects this monthly, cyclical process.

After importing the update catalog into the ConfigMgr database, you can browse and search the catalog using the Update Repository node under Software Updates in the ConfigMgr console, displayed in Figure 15.10. Under the Update Repository node are subfolders for each update classification you chose to include in the update catalog. These folders are divided further into subfolders, based on vendor and then product. A separate subfolder also exists under the Update Repository for updates specific to WSUS Infrastructure Updates; this node is always included and you cannot disable it.

Figure 15.10. The Update Repository node in the ConfigMgr console

Using the Search Folders subfolder, you can define custom queries based on attributes of the patches. These attributes include the following:

The search folders you create are dynamic and reevaluated each time you access them.

Search folders are the easiest way to find updates and should be your starting point for working with updates and patches. To create a new search folder, perform the following steps:

After creating a search folder and selecting it from the console tree, you can view and sort updates in the Details pane circled on the right of Figure 15.12. You can also select an update and view extended information about it in the pane appearing at the bottom. You can right-click an update and select Properties to view some of the same extended details in a dialog box, update the maximum runtime, and assign a custom severity. You can then use the custom severity assigned to updates to refine further the queries used for search folders.

Figure 15.12. The Search Folder details pane

Update lists are intermediate objects used to build static lists of updates. Using update lists is optional but recommended. Update lists are static, rather than dynamic like search folders; this capability allows you to create a list to monitor the life cycle of a set of updates, including download status, deployment status, and compliance reporting. You can also use update lists as a delegation mechanism, allowing separate lists for different administrative use. As an example, you can create one set of lists for desktops and one set for servers, delegating the proper rights on each.

You can view the details of updates in an update list the same way you view them though the update repository—by selecting the Update List in the console tree. The result is similar to Figure 15.12. Additionally, you can customize the columns displayed in a list.

As an example, you may only want to see the Bulletin ID and percent compliance details for updates. To customize the columns, right-click the list in the ConfigMgr console tree on the left and select View -> Add/Remove columns... to launch the Add/Remove Columns dialog box, where you can move columns between the Available and Displayed lists.

To add updates to a list, select any number of updates in the update repository and do one of the following:

• Right-click and choose Update List.

• Drag the updates from the update repository to an existing list.

Both methods launch the Update List Wizard (displayed in Figure 15.13) to guide you through the process. If you add updates using the right-click method, the first page of the wizard allows you to choose to add the updates to an existing list or create a new list. This is the only method available to create a new list.

Figure 15.13. The first page of the Update List Wizard

In both cases, the first page of the wizard contains a check box to initiate downloading the updates. The second page varies based on whether or not you are creating a new package:

Update lists are also particularly useful in a multisite ConfigMgr hierarchy. Lists created at parent sites replicate to child sites; these replicated lists are read-only at the child sites. Administrators of the child sites can then use these replicated lists to expedite the deployment of the updates in those lists—they no longer have to worry about actually discovering applicable updates, just deploying them using existing collections and templates. This replication process can be used to approve updates at higher levels of the organization and push them down as “approved” patches to the lower levels for use in a delegated model of software update maintenance.

You typically will create multiple deployments to manage distributing updates, with the only difference being the collection or the deadline for the updates. Deployment templates provide a group of common settings used to create update deployments (discussed in the section “Creating and Managing Deployments”); with templates, you can predefine the common settings for deployments, including the following:

• Collection— The collection for the deployment.

• User Notification— Suppress or allow user notification.

• Deployment time interpretation— Determines how a client interprets the deployment time—either as client local time or Coordinated Universal Time (UTC).

• Duration— The amount of time until a deployment becomes mandatory. This setting determines the actual deadline of a deployment when you use a template to create a deployment by adding the duration to the current date and time. Figure 15.14 shows the Deployment Template Wizard page to set this option.

Figure 15.14. Deployment Template Wizard with a configured duration of 2 weeks

If you only allow content to download from distribution points in a local or fast boundary and no DPs are available to a client, the updates cannot download and the deployment will fail. This may happen with roaming clients, because they move from location to location. If you have a population of systems that roam between sites with local distribution points, be sure to define the slow boundaries and make the deployments available to the slow boundaries.

Updates in a mandatory deployment download to a client when they become available, as configured on the Schedule tab of the deployment’s properties page. This capability allows clients to pre-stage the updates and ensures those updates are available when the deadline for the deployment hits, regardless of the availability on a local distribution point.

Pre-staging also prevents a distribution point from overloading with requests for updates once a deadline hits. Updates in nonmandatory deployments—those without a deadline—are not downloaded to the client until the client initiates installing updates in the deployment.

You can create new update deployments with an update template using the New Deployment Wizard. Utilizing a template makes creating deployments quicker, and ensures you can create multiple deployments using identical settings with a minimal effort. Deployment templates are optional but recommended.

To create a deployment template, launch the new Deployment Template wizard by right-clicking on the Deployment Templates node and selecting New Deployment Template. Alternatively, if you create a deployment using the New Deployment Wizard without a deployment template, you are prompted (as shown in Figure 15.15) to create a new template using the settings you just entered to create the deployment.

Figure 15.15. Creating a deployment template

There is no link between a template and deployments created using that template. ConfigMgr copies the settings from the template to the deployment but does not establish or maintain a relationship between the two.

Update deployments are similar to advertisements because they control the details of actually deploying and installing updates on managed systems. The next sections discuss creating update deployments, deployment deadlines, and scheduling when using maintenance windows.

Deployment Deadlines

A distinction between update deployments and advertisements is that rather than provide a mandatory time for installation, update deployments use deployment deadlines. Deployments are optionally available to users until the specified date and time, and they are enforced after this date and time. This is an oft-misunderstood concept and bears restating: Updates in a deployment are not forced to install until after the specified deadline.

Users can manually initiate the deployment until the deadline. By default, ConfigMgr prompts users to initiate deployments with a system tray balloon notification, basing the notification interval on the deadline according to Table 15.5. (You may notice these are actually the same intervals discussed in the “Agent Configuration” section of this chapter.)

Table 15.5. Default Deployment Notification Intervals

You can customize these default intervals by going to the Reminders tab of the Computer Client Agent Properties dialog box. You get to this dialog box by navigating to Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Client Agents in the ConfigMgr console, right-clicking Computer Client Agent, selecting Properties from the context menu, and then clicking the Reminders tab. Figure 15.16 shows an example of this tab. If necessary, you can completely suppress notifications for specific deployments.

Figure 15.16. The Reminders tab of the Computer Client Agent Properties dialog box

At the time of the deadline, the ConfigMgr agent reevaluates compliance status of the local managed system to determine which updates are still applicable, and then schedules installing the updates.

Analogous to software distribution packages, deployment packages (Site Database -> Computer Management -> Software Updates -> Deployment Packages) are simply the collection of files needed for a defined set of updates. You manage update packages identically to software distribution packages—they must have a source folder and be available to clients by installing them on distribution points.

There are two structural differences between software distribution packages and deployment packages:

Although the console does not include a specific selection to create a deployment package, there are two methods to create one:

• Choose to download updates on the first page of the Update List Wizard (see the “Update Lists” section of this chapter).

• Select updates in the update repository or an update list. Then right-click and choose Download Software Updates.

The second method launches the Download Updates Wizard, displayed in Figure 15.17. This wizard has three main pages:

Figure 15.17. The first page of the Download Updates Wizard

It is best to start with a recommended or generic way to set up a complex process such as Software Updates, particularly when the process offers many different paths. Figure 15.18 shows a flowchart presenting one possible path, based on best practices, for creating and managing your deployments.

Figure 15.18. Showing the software update management flow

The flowchart includes the following steps:

• Create collections—Similar to advertisements, update deployments are targeted to specific collections or subcollections. You can create a series of collections specifically for targeting your update deployments, where each collection has a separate deployment targeted to it, with any differences in the deployments defined by corresponding deployment templates.

• Create deployment templates—Create a deployment template for each combination of settings needed. You can use these templates each time you create a new deployment, greatly reducing the time it takes to create a deployment and ensuring all deployments follow your defined practices for deploying updates.

• Determine applicable updates—Based on your organization’s needs, requirements, and policies, you must determine which updates are applicable for your environment. You can also use compliance scan data returned from managed systems to aid in this decision. Creating search folders (previously discussed in the “Update Repository” section) will isolate updates and help you identify applicable updates.

• Create or modify update lists—Create update lists for each area of interest where compliance reporting and tracking are required. Consider creating update lists for each operating system type that exists. You may also want to create a new update list every time Microsoft releases a new batch of updates—typically the second Tuesday of every month. Using the Update Repository or Search Folders node in the console, copy updates into applicable lists. Note that updates can be part of multiple lists.

• Create or modify deployment packages—As you add updates to update lists, use the Update List Wizard to add updates to deployment packages, as described earlier in the “Update Lists” section of this chapter. You are free to create packages in whichever manner you choose.

Managed systems do not download an entire package; they only download those specific updates they require from each package regardless of which package the updates are in. This capability, in combination with ConfigMgr’s ability to use binary delta replication to replicate only changed bits in a package, eliminates the need for you to limit package sizes.

In general, you should create a single package containing all updates for each calendar year. This prevents numerous downloads of updates applicable to multiple systems for multiple packages. ConfigMgr uses file delta (default) or binary delta replication to install the package on distribution points, so the size of the package and its impact on network bandwidth should not be a concern.

• Create or modify deployments—Create the actual deployments used to distribute and install the updates to managed systems by right-clicking an update list and choosing Deploy Software Updates; then choose to add the updates to an existing deployment or create a new one. By creating a new deployment for each new set of updates, you can maintain the same deadline for previously created deployments. A previously created deployment template populates the actual settings for the deployment.

Perform the last four steps of the flowchart in Figure 15.18 every time Microsoft releases new updates or your organization determines there are updates requiring installation.

Best practices are always tricky business—what works for one organization is not necessarily the best fit for another organization. Nevertheless, it is always good to have a starting point, a set of guidelines or recommendations from those that have been through the trenches and survived. Actually, you can learn from those who didn’t survive; things like “Don’t step there” or “Don’t drink the water.” The following list is meant to be just that, a general set of guidelines to dispel any myths and reinforce the information presented in the rest of this chapter:

Deployments are somewhat limited in that they do not define an exact time that updates should or must be installed; they merely define a time when updates become mandatory. This limitation could easily cause disruption to your users and your servers if updates install at various times after the deadline.

Maintenance windows are the perfect solution to this dilemma. In general, maintenance windows prevent the ConfigMgr client from undertaking any action that could disrupt the end user on a system. This includes preventing Software Updates deployments, Software Distribution advertisements, and restarts initiated by ConfigMgr for software updates.

Because they are set on a per-collection basis, you can create maintenance windows for specific recurring and nonrecurring start and stop times. You edit these schedules by right-clicking any collection and choosing Modify Collection Settings. This displays the Collection Settings dialog box, where the first tab, Maintenance Windows, manipulates these windows. The interface for creating maintenance window schedules, displayed in Figure 15.19, is quite flexible and allows you to specify settings such as every third Tuesday of the month.

Figure 15.19. Creating maintenance window schedules

Maximum Runtimes

Another check performed by the Client agent is the maximum runtime for each applicable update in a deployment. If the sum of these maximum runtimes is greater than the maintenance window allows for, the Client agent will not install all applicable updates. The updates will be culled based on their maximum runtime, ensuring they complete before the window ends. To view or edit the maximum runtime for any update, find the update (in the update repository, an update list, a deployment, or even a deployment package), right-click it, and choose Properties. This opens a Properties dialog box for the update with a Maximum Run Time tab, shown in Figure 15.20; the value listed is editable. You can also multiselect updates to change their maximum runtimes in the same way. By default, all updates have a maximum runtime of 20 minutes.

Figure 15.20. Maximum runtime for an update (in this case 20 minutes)

Note that clients begin downloading updates as soon as deployments are available to them. This prevents the time required by clients to actually download updates from affecting the time available in the maintenance window.

There are two ConfigMgr-specific prerequisites and three external prerequisites to fully enable WOL capabilities in ConfigMgr.

ConfigMgr supports two types of WOL:

Several configuration options are available for WOL in ConfigMgr. You perform all customizations from the Wake On LAN and Ports tabs of the <Site> Properties dialog box (see Figure 15.21). Right-click Site Database -> Site Management -> <Site Code> <Site Name> and then choose Properties to get there.

Figure 15.21. Configuring Wake On LAN

Enable WOL on the Wake On LAN tab and configure whether you want to use unicast or subnet-directed broadcasts. New in R2 is the ability to use the power-on functionality of the Intel AMT technology. This is an alternative to the magic packets used by traditional WOL, but requires Out of Band (OOB) management support (discussed in Chapter 6) on the destination system; OOB also must be fully configured and enabled in ConfigMgr. To support the AMT power-on capability, R2 includes three new options:

You can also access advanced options from the Wake On LAN tab by clicking the Advanced button displayed in Figure 15.21. These options are mainly network and ConfigMgr throttling controls; only change them if you are experiencing issues.

To view the port used by ConfigMgr for the magic packet, switch to the Ports tab of the <Site> Properties dialog box. ConfigMgr uses UDP port 9 by default. To change the port, select the Wake On LAN entry in the list box and click the Properties button (the button looks like a hand pointing to a box). The Port Details dialog box launches, allowing you to change this port number. Only a single port number is supported.

ConfigMgr takes care of all the details for actually implementing WOL. You simply have to tell the system when to use it. ConfigMgr 2007 supports WOL for the following three activities:

A check box is present on the Schedule tab of the Properties dialog box for each of these activities. Once one is selected, ConfigMgr sends the WOL request to each applicable destination system at the scheduled mandatory time. When the destination system wakes up, it initiates the mandatory advertisement or deployment.

WOL is a great addition to the ConfigMgr toolset. Although third-party tools were previously available to fill this gap, having the capability built in is always better—and cheaper. WOL is not complicated, and Microsoft maintains this simplicity by seamlessly integrating WOL into the console and functionality of ConfigMgr.

ConfigMgr implements NAP using a new site system role—the System Health Validator (SHV) point. Install this new role on a Windows Server 2008 system that has the NPS role already installed. (Installing and configuring the NPS role is beyond the scope of this book; for detailed information see http://technet.microsoft.com/en-us/network/bb545879.aspx.) Perform the following steps on this system to install the SHV:

Additionally, you must extend Active Directory for ConfigMgr (see Chapter 3, “Looking Inside Configuration Manager,” for details). Extending AD is required because NAP uses the System container to store Health State References. The site server publishes Health State References used during client evaluation to ensure the most current policies are used. If you plan to use NAP in a multiforest environment, you must prepare each forest and the NAP site server role according to the instructions at http://technet.microsoft.com/en-us/library/bb694120.aspx.

On the client side, NAP only works with Windows Vista, Windows Server 2008, and Windows XP SP 3 (and above) clients. This is because only these operating systems include the NPS agent. Unfortunately, no download is available to make any other version of Windows work with NPS or NAP.

By default, the NPS Client agent is disabled in a ConfigMgr site and must be enabled. Perform the following steps:

Figure 15.22. Configuring NAP Client agent properties

Similar to other ConfigMgr Client agents, the NPS Client agent settings are sitewide without a direct way to override them for individual systems.

Those clients subject to the policies of the NPS will report to the NPS using their built-in NPS client. The NPS Client agent retrieves policies from the NPS and evaluates the health of a system against the checks defined in the policy encapsulating the results, known as a Statement of Health (SoH). The SoH contains results from all the checks performed on the system, and the NPS Client agent submits the SoH to the NPS. The NPS receives the SoH and compares it against the NPS policies:

NPS policies, known as health policies, are based on server-side components called System Health Validators. These SHVs plug in to the NPS server and enable performing specific checks on a client to validate its health. As an example, the built-in Windows Security SHV defines checks for the status of the Windows Firewall, existence of antivirus software, and other settings typically associated with the Windows Security Center. Each check results in one of two states: Pass or Fail. The status of a client as a whole may also be reported in one of three different states:

The health policies define which SHVs to use and what conditions must be met for a system to match a health policy. The following conditions are possible in a health policy:

The ConfigMgr SHV point implements the SHV that plugs in to an NPS. The policies produced by this SHV instruct the NPS Client agent to compare the exact patch status of a system against the applicable mandatory updates configured in the NAP policies in the ConfigMgr console (Site Database -> Computer Management -> Network Access Protection -> Policies). See the “Compliance” section of this chapter for a description of these policies.

A System Health Agent (SHA) is a component that plugs in to the NPS agent on the client; each server-side SHV has a corresponding client-side SHA. SHAs perform the actual checks on a system and produce the Pass/Fail results that go into the client’s SoH.

The ConfigMgr client implements the ConfigMgr SHA. This SHA performs the actual comparison of the current update status on the client with the mandatory deployments applicable to the system, adding the results to the SoH for that system.

The ConfigMgr SHA first performs a series of nonconfigurable checks to determine the compliance state of the client. These checks include the following:

If any of these checks succeed, the status updates in the SoH and the series of checks ceases. If the client makes it through these checks, the SHA compares the configured NAP polices against the client. Each NAP policy must define two things:

See http://technet.microsoft.com/en-us/library/bb680968.aspx for a detailed flowchart of the checks performed by the SHA.

You can configure multiple NAP policies, allowing for multiple sets of updates and effective dates. These policies are not targeted in any way and are applied to all systems equally. You can create an NAP policy in one of two ways:

• Right-click the Policies node (Site Database -> Computer Management -> Network Access Protection -> Policies) in the ConfigMgr console and select New. This action opens the New Policies Wizard displayed in Figure 15.23, with two primary pages—one to choose updates, and one to set the effective date for the policy. You can only choose updates from Deployment Packages.

Figure 15.23. Selecting software updates for NAP in the New Policies Wizard

• Right-click any single update or multiselected updates in the Update Repository, an Update List, Deployment, or Deployment Package and then select Properties from the context menu. This launches a Properties dialog box with an NAP Evaluation tab, displayed in Figure 15.24. Here, you can enable NAP evaluation and configure an effective date by the selected updates. This creates a new NAP policy under the Policies node, which you can later modify or delete.

Figure 15.24. NAP evaluation time for an update

If the ConfigMgr SHV deems a client system noncompliant, the system may be placed in a quarantine status based on the Network Policy configuration on the NPS server. In this quarantine status, the client system has limited access to network resources. This limited network connectivity, known as remediation, allows the client to correct conditions that caused it to be noncompliant.

With ConfigMgr 2007, the remediation process is automatic—the client automatically requests updates from ConfigMgr and installs them based on the NAP policies. The only required configuration is to add specific infrastructure servers to a remediation server group in the NPS. This group identifies which servers are accessible by systems placed into the quarantine status. You should add the following types of servers that host critical network services into this group:

Do not place Configuration Manager servers in the remediation server group, because access to these systems is dynamically granted.

Although it comes with some overhead in the form of the Windows Server 2008 NPS role, NAP increases the security posture of your network greatly by interrogating systems as they try to connect to the network and enforcing a minimum patch level. It can also help you deploy updates for those annoying (and upper-management attention-getting) zero-day exploits.

There are two primary ways to monitor your software update status in ConfigMgr. The first and traditional way is to use reporting. As of ConfigMgr 2007 R2, there are 34 reports out of the box specific to tracking various aspects of Software Updates, including client scan states, update applicability, deployment progress, and compliance. Like all ConfigMgr reports, you can copy and customize these to fit your exact needs.

The second way to monitor Software Updates is using the Software Updates home page, accessible by directly selecting the Software Updates node in the ConfigMgr admin console tree (Site Database -> Computer Management -> Software Updates). This page provides a dashboard for finding summary information concerning your Software Updates stance. Figure 15.25 displays an example of this home page.

Figure 15.25. Software updates home page

You can select a subset of updates from the update repository by defining filter criteria for the Vendor, Month and Year, and Classification. This populates the list box on the left with updates matching the specified filter criteria. For Microsoft Updates, the listed Article IDs are actually hyperlinks that take you directly to the TechNet knowledge base article describing the update. The % Compliant column also contains hyperlinks that launch the specific software update states report, which details the count and percentage of computers in each compliance state for the specified software update. In addition to the list of updates on the left, a pie chart summarizing the compliance state of updates selected in the list is displayed on the right. You can select multiple updates in the usual way to update the pie chart with aggregate data from all the updates selected.

Links at the bottom of the page take you to other nodes in the admin console, significant reports, and applicable help documentation.

The first component in Software Updates is WSUS. WSUS is significant because it acquires all information about available updates and distributes that catalog of updates to clients. Luckily, ConfigMgr takes over control of WSUS using an SUP and creates detailed log files of the WSUS operation. Here are the three main log files for WSUS and an SUP, located in <ConfigMgrInstallPath>Logs:

Most errors experienced with WSUS are configuration errors, including not matching the ports configured during installation of WSUS and then configured in the SUP (Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site Systems -> ConfigMgr software update point).

Also common are Internet connectivity issues due to firewalls, proxy servers, or other mitigating factors. Always confirm that the system running WSUS has Internet connectivity if you are downloading the update catalog directly from Microsoft, and ensure that you have properly configured the proxy account if one is required (Site Management -> <Site Code> <Site Name> -> Site Settings -> Component Configuration -> Software Update Point Component).

It is possible for the update downloads from Microsoft to fail. Recall that WSUS does not download the updates in ConfigMgr; you must manually initiate download of all updates. This is an interactive process; the ConfigMgr console connects to the Microsoft download servers using the credentials of the user currently logged in to the console. You can easily test connectivity for the current user by opening Internet Explorer and navigating to http://www.microsoft.com/downloads. (If a proxy server is required to connect to the Internet, configure the settings in Internet Explorer.) If the logged-in user does not have permission to perform the action, the download will not take place.

The PatchDownloader.log file logs download activity for updates. This log contains information about every patch the console attempts to download. The file is located in one of two places:

WUA on the local system handles the process of scanning a client for applicable updates. The ConfigMgr agent initiates the scanning according to the defined schedules or any on-demand requests; the WUA will in turn report back to the ConfigMgr agent. The following client-side log files, located in the %SystemRoot%System32CCMlogs folder on 32-bit clients and %SystemRoot%SysWOW64CCMlogs on 64-bit clients, can help when investigating failures:

One of the main issues that can affect the scanning process is having a domain-based GPO override the Windows Updates settings. The WUAHandler.log file will clearly indicate if this issue exists in your environment.