Tuesday, June 15, 2010

Service Packs

Microsoft releases Service Packs to consolidate critical updates, security rollups, hot-fixes, driver updates, and feature enhancements. You must stay current with Service Packs to maintain the security and integrity of your enterprise network. Software Update Services, discussed in the previous Topic, does not distribute service packs. To keep your network completely up to date with critical patches, you need to implement the skills covered in this Topic, which will allow you to deploy service packs by means of Group Policy.

Downloading and Extracting Service Packs

When a service pack is released, Microsoft makes it available for installation and download from the Microsoft Web site. A service pack can be installed directly from a Microsoft server, in which case the client launches the service pack setup from the Microsoft site and a small setup utility is downloaded to the client. That setup utility reconnects to the Microsoft server and controls the download and installation of the entire service pack. Service packs are generally sizeable, so performing this task machine-by-machine is not an efficient deployment strategy in all but the smallest environments.

Service packs can also be obtained on CD from Microsoft and through many Microsoft resources, such as TechNet and MSDN. Service Pack CDs often include extras, such as updated administrative tools, new policy templates, and other value-added software. In an enterprise environment, it is therefore recommended to obtain the service pack media.

When you do not have access to a CD containing the service pack, and you want to deploy the service pack to more than one system, you can download the entire service pack as a single file, again from the Microsoft Web site. The service pack executable, if launched (by double-clicking, for example), triggers the installation of the service pack. This single-file version of the executable can also be extracted into the full folder and file structure of the service pack, just as it would be on the service pack CD, but without the value adds.

To extract a service pack, launch the executable from a command prompt with the -x switch. For example, to extract Windows XP Service Pack 1, type xpsp1.exe -x. You will then be prompted for a folder to which the service pack is extracted. Once the pro­cess is complete, you will see the full service pack folder structure contained in the tar-get folder. You can then launch installation of the service pack, just as from the CD, by double-clicking I386\Update\Update.exe.

Deploying Service Packs with Group Policy Service Pack installation requires administrative credentials on the local computer, unless the service pack is installed via Group Policy or Systems Management Server (SMS). Because service packs apply to systems, it is necessary to assign the service pack through computer-based, rather than user-based, group policy.

To distribute a service pack, create a shared folder and either extract the service pack to that folder or copy the contents of the service pack CD to the folder. Then, using the Active Directory Users And Computers snap-in, create or select an existing GPO. Click Edit and the Group Policy Object Editor console appears, focused on the selected GPO.

Expand the Computer Configuration\Software Settings node. Right-click Software Installation and choose New, then Package. Enter the path to the service pack’s Update.msi file. Be certain to use a UNC format (for example, \\Server\Share) and not a local volume path, such as Drive:\Path. In the Deploy Software dialog box, select Assigned. Close the Group Policy Object Editor console. Computers within the scope of the GPO—in the site, domain, or OU branch to which the policy is linked—auto­matically deploy the service pack at the next startup. 

Tuesday, June 8, 2010

Software Update Services (SUS)

To maintain a secure computing environment, it is critical to keep systems up to date with security patches. Since 1998, Microsoft has provided Windows Update as a Web-based source of information and downloads. With Windows XP and Windows 2000 service pack 3, Microsoft added Automatic Updates, whereby a system automatically connects to Windows Update and downloads any new, applicable patches or “hot-fixes.” Although the Windows Update servers and Automatic Updates client achieve the goal of keeping systems current, many administrators are uncomfortable with either computers or users deciding which patches should be installed, because a patch might interfere with the normal functioning of a business-critical application.
The latest improvements to these technologies deliver Software Update Services (SUS). SUS is a client-server application that enables a server on your intranet to act as a point of administration for updates. You can approve updates for SUS clients, which then download and install the approved updates automatically without requiring local administrator account interaction.
In this lesson you will learn to install and administer SUS on a Windows Server 2003 computer. The following Topic will guide you through issues related to client configuration.
Understanding SUS
Since 1998, Microsoft Windows operating systems have supported Windows Update, a globally distributed source of updates. Windows Update servers interact with client-side software to identify critical updates, security rollups, and enhancements that are appropriate to the client platform, and then to download approved patches.
Administrators wanted a more centralized solution that would assure more direct con­trol over updates that are installed on their clients. Software Update Services is a response to that need. SUS includes several major components:
Software Update Services, running on an Internet Information Services (IIS) server  :The server-side component is responsible for synchronizing infor­mation about available updates and, typically, downloading updates from the Microsoft Internet-based Windows Update servers or from other intranet servers running SUS.
The SUS administration Web site: All SUS administration is Web-based. After installing and configuring SUS, administration typically consists of ensuring that the SUS server is synchronizing successfully, and approving updates for distribu­tion to network clients.
Automatic Updates The Automatic Updates client is responsible for download­ing updates from either Windows Update or an SUS server, and installing those updates based on a schedule or an administrator’s initiation.
Group Policy settings Automatic Updates clients can be configured to synchro­nize from an SUS server rather than the Windows Update servers by modifying the clients’ registries or, more efficiently, by configuring Windows Update policies in a Group Policy Object (GPO).
Installing SUS on a Windows Server 2003 Computer
SUS has both client and server components. The server component runs on a Windows 2000 Server (Service Pack 2 or later) or a Windows Server 2003 computer. Internet Information Services (IIS) must be installed before setting up SUS and, as you learned in Chapter 6, “Files and Folders,” IIS is not installed by default on Windows Server 2003. For information about how to install IIS, see Chapter 6.
SUS is not included with the Windows Server 2003 media, but it is a free download from the Microsoft SUS Web site at http://go.microsoft.com/fwlink/?LinkID=6930.
After downloading the latest version of SUS, double-click the file and the installation routine will start. After you agree to the license agreement, choose Custom setup and the Setup Wizard will prompt you for the following information:
   Choose File Locations Each Windows Update patch consists of two compo­nents: the patch file itself and metadata that specifies the platforms and languages to which the patch applies. SUS always downloads metadata, which you will use to approve updates and which clients on your intranet will retrieve from SUS. You can choose whether to download the files themselves and, if so, where to save the updates.
If you choose the Save the Updates to This Local Folder option, the Setup Wizard defaults to the drive with the most free space, and will create a folder called SUS on that drive. You can save the files to any NT file system (NTFS) partition; Microsoft recommends a minimum of 6 gigabytes (GB) of free space.
   Language Settings Although the SUS administrative interface is provided in English and a few additional languages, patches are released for all supported locales. This option specifies the localized versions of Windows servers or clients that you support in your environment.
   Handling New Versions Of Previously Approved Updates Occasionally, an update itself is updated. You can direct SUS to approve automatically updates that are new versions of patches that you have already approved, or you can continue to approve each update manually.
   Ready To Install Before installation begins, the Setup Wizard will remind you of the URL clients should point to, http://SUS_servername. Note this path because you will use it to configure network clients.
  Installing Microsoft Software Update Services The Setup Wizard installs SUS.
   Completing the Microsoft Software Update Services Setup Wizard The final page of the Setup Wizard indicates the URL for the SUS administration site, http://SUS_servername/SUSAdmin. Note this path as well, because you will admin­ister SUS from that Web location. When you click Finish, your Web browser will start and you will be taken automatically to the SUS administration page.

Software Update Services installs the following three components on the server:
■ The Software Update Synchronization Service, which downloads content to the SUS server
■ An IIS Web site that services update requests from Automatic Updates clients
■ An SUS administration Web page, from which you can synchronize the SUS server and approve updates

Configuring and Administering SUS
You will perform three administrative tasks related to SUS: configuring SUS settings, synchronizing content and approving content. These tasks are performed using the SUS Administration Web site, shown in below Figure, which can be accessed by navigat­ing to http://SUS_servername/SUSAdmin with Internet Explorer 5.5 or later, or by open­ing Microsoft Software Update Services from the Administrative Tools programs group. The administration of SUS is entirely Web-based.
 Configuring Software Update Services
Although some of the configuration of SUS can be specified during a custom installa­tion, all SUS settings are accessible from the SUS Administration Web page. From the Software Update Services administration page, click Set Options in the left navigation bar. The Set Options page is shown in below Figure.

The configuration settings are as follows:
Proxy server configuration If the server running SUS connects to Windows Update using a proxy server, you must configure proxy settings.
DNS name of the SUS server In the Server Name box, type the fully qualified domain name (FQDN) of the SUS server, for example, sus1.contoso.com.
Content source The first SUS servDer you install will synchronize its content from Microsoft Windows Update. Additional SUS servers can synchronize from Windows Update, from a “parent” SUS server, or from a manually created content distribution point. See the sidebar, “SUS Topology” for more information.
New versions of approved updates The Set Options page allows you to mod­ify how SUS handles new versions of previously approved updates. This option is discussed earlier in the lesson.
File storage You can modify the storage of metadata and update files. This option is also discussed earlier in the lesson.
Languages This setting determines the locale specific updates that are synchro­nized. Select only languages for locales that you support in your environment.
Synchronizing SUS
On the SUS Administration Web page, click Synchronize Server. On the Synchronize Server page, as shown in Below Figure, you can start a manual synchronization or config­ure automatic, scheduled synchronization. Click Synchronize Now and, when synchro­nization is complete, you will be informed of its success or failure, and, if the synchronization was successful, you will be taken to the Approve Updates page.
To schedule synchronization, click Synchronization Schedule. You can configure the time of day for synchronization, as shown in Below Figure, and whether synchronization occurs daily or weekly on a specified day. When a scheduled synchronization fails, SUS will try again for the Number of Synchronization Retries to Attempt setting. Retries occur at 30-minute intervals.


Approving Updates
To approve updates for distribution to client computers, click Approve Updates in the left navigation bar. The Approve Updates page, as shown in below Figure, appears. Select the updates that you wish to approve, then click Approve. If you are unsure about the applicability of a particular update, click the Details link in the update summary. The Details page that opens will include a link to the actual *.cab file that is used to install the package, and a link to the Read More page about the update, which will open the Microsoft Knowledge Base article related to the update.

The Automatic Updates Client
The client component of SUS is Windows Automatic Updates, which is supported on Windows 2000, Windows XP, and Windows Server 2003. The Automatic Updates client is included with Windows Server 2003, Windows 2000 Service Pack 3, and Windows XP Service Pack 1.
For clients running earlier releases of the supported platforms, you can download Automatic Updates as a stand-alone client from the Microsoft SUS Web site,at http://go.microsoft.com/fwlink/?LinkID=6930. The client, provided as an .msi file, can be installed on a stand-alone computer or by means of Group Policy (assign the pack-age in the Computer Configuration\Software Settings policy), SMS, or even a logon script. If a localized version of the client is not available, install the English version on any locale.
The Automatic Updates client of Windows Server 2003 is configured to connect auto­matically to the Microsoft Windows Update server and download updates, then prompt the user to install them. This behavior can be modified by accessing the Automatic Updates tab in the System Properties dialog box, accessible by clicking System in Con­trol Panel, in Windows XP and Windows Server2003. In Windows 2000 click Automatic Updates in Control Panel. The Automatic Updates tab is shown in below Figure. Auto­matic Updates can also be configured using GPOs or registry values.

Download Behavior
Automatic Updates supports two download behaviors:
  Automatic Updates are downloaded without notification to the user.
   Notification If Automatic Updates is configured to notify the user before downloading updates, it registers the notification of an available update in the system event log and to a logged-on administrator of the computer. If an administrator is not logged on, Automatic Updates waits for a user with administrator credentials before offering notification by means of a balloon in the notification area of the system tray.
Once update downloading has begun, Automatic Updates uses the Background Intel­ligent Transfer Service (BITS) to perform the file transfer using idle network band-width. BITS ensures that network performance is not hindered due to file transfer. All patches are checked by the SUS server to determine if they have been correctly signed by Microsoft. Similarly, the Automatic Updates client confirms the Microsoft signature and also examines the cyclical redundancy check (CRC) on each package before installing it.
Installation Behavior
Automatic Updates provides two options for installation:
   Notification Automatic Updates registers an event in the system log indicating that updates are ready for installation. Notification will wait until a local adminis­trator is logged on before taking further action. When an administrative user is logged on, a balloon notification appears in the system tray. The administrator clicks the balloon or the notification icon, and then may select from available updates before clicking Install. If an update requires restarting the computer, Auto­matic Updates cannot detect additional updates that might be applicable until after the restart.
   Automatic (Scheduled) When updates have been downloaded successfully, an event is logged to the system event log. If an administrator is logged on, a notifi­cation icon appears, and the administrator can manually launch installation at any time until the scheduled installation time.

At the scheduled installation time, an administrator who is logged on will be noti­fied with a countdown message prior to installation, and will have the option to cancel installation, in which case the installation is delayed until the next sched­uled time. If a non-administrator is logged on, a warning dialog appears, but the user cannot delay installation. If no user is logged on, installation occurs automat­ically. If an update requires restart, a five-minute countdown notification appears informing users of the impending restart. Only an administrative user can cancel the restart.

Configuring Automatic Updates Through Group Policy
The Automatic Updates client will, by default, connect to the Microsoft Windows Update server. Once you have installed SUS in your organization, you can direct Auto­matic Updates to connect to specific intranet servers by configuring the registry of cli­ents manually or by using Windows Update group policies.
To configure Automatic Updates using GPOs, open a GPO and navigate to the Com­puter Configuration\Administrative Templates\Windows Components\Windows Update node. The Windows Update policies are shown in below Figure.
The following policies are available, each playing an important role in configuring effective update distribution in your enterprise:
   Configure Automatic Updates The Configure Automatic Updates Behavior determines the behavior of the Automatic Updates client. There are three options: Notify For Download And Notify For Install, Auto Download And Notify For Install, and Auto Download And Schedule The Install. These options are combina­tions of the installation and download behaviors discussed earlier in the lesson.
   Reschedule Automatic Updates Scheduled Installations If installations are scheduled, and the client computer is turned off at the scheduled time, the default behavior is to wait for the next scheduled time. The Reschedule Automatic Updates Scheduled Installations policy, if set to a value between 1 and 60, causes Automatic Updates to reschedule installation for the specified number of minutes after system startup.
   No Auto-Restart For Scheduled Automatic Updates Installations This policy causes Automatic Updates to forego a restart required by an installed update when a user is logged on to the system. Instead, the user is notified that a restart is required for installation to complete, and can restart the computer at his or her dis­cretion. Remember that Automatic Updates cannot detect new updates until restart has occurred.
   Specify Intranet Microsoft Update Service Location This policy allows you to redirect Automatic Updates to a server running SUS. By default, the client will log its interactions on the SUS server to which it connects. However, this policy allows you to point clients to another server running IIS for statistics logging. This dual policy provides the opportunity for clients to obtain updates from a local SUS server, but for all clients to log SUS statistics in a single location for easier retrieval and analysis of the log data, which is stored as part of the IIS log. IIS logs typically reside in %Windir%\System32\Logfiles\W3svc1.
Automatic Updates clients poll their SUS server every 22 hours, minus a random offset.
Any delay in patching should be treated as unacceptable when security vulnerabilities are being actively exploited. In such situations, install the patch manually so that sys­tems do not have to wait to poll, download, and install patches.
After approved updates have been downloaded from the SUS server, they will be installed as configured—manually or automatically—at the scheduled time. If an approved update is later unapproved, that update is not uninstalled; but it will not be installed by additional clients. An installed update can be uninstalled manually, using the Add Or Remove Programs application in Control Panel.

SUS Troubleshooting
Although SUS works well, there are occasions that warrant monitoring and trouble-shooting.
Monitoring SUS
The Monitor Server page of the SUS Administration Web site displays statistics that reflect the number of updates available for each platform, and the date and time of the most recent update. The information is summarized from the Windows Update meta­data that is downloaded during each synchronization. Metadata information is written to disk and stored in memory to improve performance as systems request platform appropriate updates.
You can also monitor SUS and Automatic Updates using the following logs:
Synchronization Log  You can retrieve information about current or past syn­chronizations, and the specific packages that were downloaded by clicking View Synchronization Log in the left navigation bar. You can also use any text editor to open the (Extensible Markup Language) XML–based database (History-Sync.xml) directly from the SUS Web site’s \AutoUpdate\Administration directory in IIS.
Approval Log For information about packages that have been approved, click View Approval Log in the left navigation bar. Alternatively, you can open History-Approve.xml from the SUS Web site’s \AutoUpdate\Administration directory in IIS.
Windows Update Log The Automatic Updates client logs activity in the %Windir%\Windows Update.log file on the client’s local hard disk.
Wutrack.bin The client’s interaction with SUS is logged to the specified statistics server’s IIS logs, typically stored in the folder: %Windir%\System32\Logfiles \W3svc1. These logs, which are verbose and cryptic, are designed to be analyzed by programs, not by humans.
SUS System Events
The synchronization service generates event log messages for each synchronization per-formed by the server, and when updates are approved. These messages can be viewed in the System log using Event Viewer. The events relate to the following scenarios:

   Unable to connect Automatic Updates could not connect to the update service (Windows Update or the computer’s assigned SUS server).
   Install ready—no recurring schedule Updates listed in the event were down-loaded and are pending installation. An administrator must click the notification icon and click Install.
   Install ready—recurring schedule Updates listed in the event are down-loaded and will be installed at the date and time specified in the event.
  Installation success Updates listed in the event were installed successfully.
  Installation failure Updates listed in the event failed to install properly.
   Restart required—no recurring schedule An update requires a restart. If installation behavior is set for notification, restart must be performed manually. Windows cannot search for new updates until the restart has occurred.
   Restart required—recurring schedule When Automatic Updates is config­ured to automatically install updates, an event is registered if an update requires restart. Restart will occur within five minutes. Windows cannot search for new updates until after the restart has occurred.
Troubleshooting SUS
Software Update Services on a Windows Server 2003 computer may require the follow­ing troubleshooting steps:
   Reloading the memory cache If no new updates appear since the last time you synchronized the server, it is possible that no new updates are available. However, it is also possible that memory caches are not loading new updates properly. From the SUS administration site, click Monitor Server and then click Refresh.
   Restarting the synchronization service If you receive a message that the syn­chronization service is not running properly, or if you cannot modify settings in the Set Options page of the administration Web site, open the Microsoft Manage­ment Console (MMC) Services snap-in, right-click Software Update Services Syn­chronization Service and choose Restart.
   Restarting IIS If you cannot connect to the administration site, or if clients can-not connect to the SUS serve, restart the World Wide Web Publishing Service in the same manner.
If Automatic Updates clients do not appear to be receiving updates properly, open the registry of a client and ensure that the following values appear in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate:

WUServer Should have the URL of the SUS server, for example, http: //SUS_Servername
WUStatus Server Should have the URL of the same SUS server or another IIS server on which synchronization statistics are logged
And, in the AU subkey:
Use WUServer Should be set to dword:00000001
SUS Backup and Recovery
As with any other server role or application, you must plan for recovery in the event of a server failure.
Backing Up SUS
To back up SUS, you must back up the folder that contains SUS content, the SUS Administration Web site, and the IIS metabase.
First, back up the metabase—an XML database containing the configuration of IIS. Using the MMC IIS snap-in, select the server to back up and, from the Action menu, select All Tasks, then Backup/Restore Configuration. Click Create Backup and enter a name for the backup. When you click OK, the metabase is backed up.
Then back up the following using Ntbackup or another backup utility:
   The default Web site, which is located unless otherwise configured in C:\Inetpub \Wwwroot.
   The SUS Administration Web site. SUSAdmin is, by default, a subfolder of C:\Inetpub\Wwwroot. In that event, it will be backed up when you back up the default Web site.
   The AutoUpdate virtual directory, also by default a subfolder of C:\Inetpub \Wwwroot.
   The SUS content location you specified in SUS setup or the SUS options. You can confirm the SUS content location in IIS manager by clicking Default Web Site and examining the path to the Content virtual root in the details pane.
   The metabase backup directory, %Windir%\System32\Inetsrv\Metaback, which contains the copy of the metabase made earlier.
This process of backing up the metabase, and then backing up the components of SUS, should be repeated regularly because updates will be added and approved with some frequency.
SUS Server Recovery
To restore a failed SUS server, perform the steps described below. If a certain step is unnecessary, you may skip it, but perform the remaining steps in sequence.
1. Disconnect the server from the network to prevent it from being infected with viruses.
2. Install Windows Server 2003, being sure to give the server the same name it had previously.
3. Install IIS with the same components it had previously.
4. Install the latest service pack and security fixes. If the server must be connected to the network to achieve this step, take all possible precautions to prevent unnec­essary exposure.
5. Install SUS into the same folder it was previously installed.
6. Run NTbackup to restore the most recent backup of SUS. This will include the SUS content folder, the Default Web Site, including the SUSAdmin and AutoUpdate vir­tual directories, and the IIS metabase backup.
7. Open the MMC IIS snap-in and select the server to restore. From the Action menu, select All Tasks, then Backup/Restore Configuration and select the backup that was just restored. Click Restore.
8.Confirm the success of your recovery by opening the SUS Administration Web site and clicking Set Options. Check that the previous settings are in place, and that the previously approved updates are still approved. 

Monday, June 7, 2010

Software Update Services

To maintain a secure computing environment, it is critical to keep systems up to date with security patches. Since 1998, Microsoft has provided Windows Update as a Web-based source of information and downloads. With Windows XP and Windows 2000 service pack 3, Microsoft added Automatic Updates, whereby a system automatically connects to Windows Update and downloads any new, applicable patches or “hot-fixes.” Although the Windows Update servers and Automatic Updates client achieve the goal of keeping systems current, many administrators are uncomfortable with either computers or users deciding which patches should be installed, because a patch might interfere with the normal functioning of a business-critical application.
The latest improvements to these technologies deliver Software Update Services (SUS). SUS is a client-server application that enables a server on your intranet to act as a point of administration for updates. You can approve updates for SUS clients, which then download and install the approved updates automatically without requiring local administrator account interaction.
In this lesson you will learn to install and administer SUS on a Windows Server 2003 computer. The following Topic will guide you through issues related to client configuration.
Understanding SUS
Since 1998, Microsoft Windows operating systems have supported Windows Update, a globally distributed source of updates. Windows Update servers interact with client-side software to identify critical updates, security rollups, and enhancements that are appropriate to the client platform, and then to download approved patches.
Administrators wanted a more centralized solution that would assure more direct con­trol over updates that are installed on their clients. Software Update Services is a response to that need. SUS includes several major components:
Software Update Services, running on an Internet Information Services (IIS) server  :The server-side component is responsible for synchronizing infor­mation about available updates and, typically, downloading updates from the Microsoft Internet-based Windows Update servers or from other intranet servers running SUS.
The SUS administration Web site: All SUS administration is Web-based. After installing and configuring SUS, administration typically consists of ensuring that the SUS server is synchronizing successfully, and approving updates for distribu­tion to network clients.
Automatic Updates The Automatic Updates client is responsible for download­ing updates from either Windows Update or an SUS server, and installing those updates based on a schedule or an administrator’s initiation.
Group Policy settings Automatic Updates clients can be configured to synchro­nize from an SUS server rather than the Windows Update servers by modifying the clients’ registries or, more efficiently, by configuring Windows Update policies in a Group Policy Object (GPO).
Installing SUS on a Windows Server 2003 Computer
SUS has both client and server components. The server component runs on a Windows 2000 Server (Service Pack 2 or later) or a Windows Server 2003 computer. Internet Information Services (IIS) must be installed before setting up SUS and, as you learned in Chapter 6, “Files and Folders,” IIS is not installed by default on Windows Server 2003. For information about how to install IIS, see Chapter 6.
SUS is not included with the Windows Server 2003 media, but it is a free download from the Microsoft SUS Web site at http://go.microsoft.com/fwlink/?LinkID=6930.
After downloading the latest version of SUS, double-click the file and the installation routine will start. After you agree to the license agreement, choose Custom setup and the Setup Wizard will prompt you for the following information:
   Choose File Locations Each Windows Update patch consists of two compo­nents: the patch file itself and metadata that specifies the platforms and languages to which the patch applies. SUS always downloads metadata, which you will use to approve updates and which clients on your intranet will retrieve from SUS. You can choose whether to download the files themselves and, if so, where to save the updates.
If you choose the Save the Updates to This Local Folder option, the Setup Wizard defaults to the drive with the most free space, and will create a folder called SUS on that drive. You can save the files to any NT file system (NTFS) partition; Microsoft recommends a minimum of 6 gigabytes (GB) of free space.
   Language Settings Although the SUS administrative interface is provided in English and a few additional languages, patches are released for all supported locales. This option specifies the localized versions of Windows servers or clients that you support in your environment.
   Handling New Versions Of Previously Approved Updates Occasionally, an update itself is updated. You can direct SUS to approve automatically updates that are new versions of patches that you have already approved, or you can continue to approve each update manually.
   Ready To Install Before installation begins, the Setup Wizard will remind you of the URL clients should point to, http://SUS_servername. Note this path because you will use it to configure network clients.
  Installing Microsoft Software Update Services The Setup Wizard installs SUS.
   Completing the Microsoft Software Update Services Setup Wizard The final page of the Setup Wizard indicates the URL for the SUS administration site, http://SUS_servername/SUSAdmin. Note this path as well, because you will admin­ister SUS from that Web location. When you click Finish, your Web browser will start and you will be taken automatically to the SUS administration page.

Software Update Services installs the following three components on the server:
■ The Software Update Synchronization Service, which downloads content to the SUS server
■ An IIS Web site that services update requests from Automatic Updates clients
■ An SUS administration Web page, from which you can synchronize the SUS server and approve updates

Configuring and Administering SUS
You will perform three administrative tasks related to SUS: configuring SUS settings, synchronizing content and approving content. These tasks are performed using the SUS Administration Web site, shown in below Figure, which can be accessed by navigat­ing to http://SUS_servername/SUSAdmin with Internet Explorer 5.5 or later, or by open­ing Microsoft Software Update Services from the Administrative Tools programs group. The administration of SUS is entirely Web-based.

Configuring Software Update Services
Although some of the configuration of SUS can be specified during a custom installa­tion, all SUS settings are accessible from the SUS Administration Web page. From the Software Update Services administration page, click Set Options in the left navigation bar. The Set Options page is shown in below Figure.
The configuration settings are as follows:
Proxy server configuration If the server running SUS connects to Windows Update using a proxy server, you must configure proxy settings.
DNS name of the SUS server In the Server Name box, type the fully qualified domain name (FQDN) of the SUS server, for example, sus1.contoso.com.
Content source The first SUS servDer you install will synchronize its content from Microsoft Windows Update. Additional SUS servers can synchronize from Windows Update, from a “parent” SUS server, or from a manually created content distribution point. See the sidebar, “SUS Topology” for more information.
New versions of approved updates The Set Options page allows you to mod­ify how SUS handles new versions of previously approved updates. This option is discussed earlier in the lesson.
File storage You can modify the storage of metadata and update files. This option is also discussed earlier in the lesson.
Languages This setting determines the locale specific updates that are synchro­nized. Select only languages for locales that you support in your environment.
Synchronizing SUS
On the SUS Administration Web page, click Synchronize Server. On the Synchronize Server page, as shown in Below Figure, you can start a manual synchronization or config­ure automatic, scheduled synchronization. Click Synchronize Now and, when synchro­nization is complete, you will be informed of its success or failure, and, if the synchronization was successful, you will be taken to the Approve Updates page.

To schedule synchronization, click Synchronization Schedule. You can configure the time of day for synchronization, as shown in Below Figure, and whether synchronization occurs daily or weekly on a specified day. When a scheduled synchronization fails, SUS will try again for the Number of Synchronization Retries to Attempt setting. Retries occur at 30-minute intervals.



Approving Updates
To approve updates for distribution to client computers, click Approve Updates in the left navigation bar. The Approve Updates page, as shown in below Figure, appears. Select the updates that you wish to approve, then click Approve. If you are unsure about the applicability of a particular update, click the Details link in the update summary. The Details page that opens will include a link to the actual *.cab file that is used to install the package, and a link to the Read More page about the update, which will open the Microsoft Knowledge Base article related to the update.


The Automatic Updates Client
The client component of SUS is Windows Automatic Updates, which is supported on Windows 2000, Windows XP, and Windows Server 2003. The Automatic Updates client is included with Windows Server 2003, Windows 2000 Service Pack 3, and Windows XP Service Pack 1.
For clients running earlier releases of the supported platforms, you can download Automatic Updates as a stand-alone client from the Microsoft SUS Web site,at http://go.microsoft.com/fwlink/?LinkID=6930. The client, provided as an .msi file, can be installed on a stand-alone computer or by means of Group Policy (assign the pack-age in the Computer Configuration\Software Settings policy), SMS, or even a logon script. If a localized version of the client is not available, install the English version on any locale.
The Automatic Updates client of Windows Server 2003 is configured to connect auto­matically to the Microsoft Windows Update server and download updates, then prompt the user to install them. This behavior can be modified by accessing the Automatic Updates tab in the System Properties dialog box, accessible by clicking System in Con­trol Panel, in Windows XP and Windows Server2003. In Windows 2000 click Automatic Updates in Control Panel. The Automatic Updates tab is shown in below Figure. Auto­matic Updates can also be configured using GPOs or registry values.

Download Behavior
Automatic Updates supports two download behaviors:
  Automatic Updates are downloaded without notification to the user.
   Notification If Automatic Updates is configured to notify the user before downloading updates, it registers the notification of an available update in the system event log and to a logged-on administrator of the computer. If an administrator is not logged on, Automatic Updates waits for a user with administrator credentials before offering notification by means of a balloon in the notification area of the system tray.
Once update downloading has begun, Automatic Updates uses the Background Intel­ligent Transfer Service (BITS) to perform the file transfer using idle network band-width. BITS ensures that network performance is not hindered due to file transfer. All patches are checked by the SUS server to determine if they have been correctly signed by Microsoft. Similarly, the Automatic Updates client confirms the Microsoft signature and also examines the cyclical redundancy check (CRC) on each package before installing it.
Installation Behavior
Automatic Updates provides two options for installation:
   Notification Automatic Updates registers an event in the system log indicating that updates are ready for installation. Notification will wait until a local adminis­trator is logged on before taking further action. When an administrative user is logged on, a balloon notification appears in the system tray. The administrator clicks the balloon or the notification icon, and then may select from available updates before clicking Install. If an update requires restarting the computer, Auto­matic Updates cannot detect additional updates that might be applicable until after the restart.
   Automatic (Scheduled) When updates have been downloaded successfully, an event is logged to the system event log. If an administrator is logged on, a notifi­cation icon appears, and the administrator can manually launch installation at any time until the scheduled installation time.

At the scheduled installation time, an administrator who is logged on will be noti­fied with a countdown message prior to installation, and will have the option to cancel installation, in which case the installation is delayed until the next sched­uled time. If a non-administrator is logged on, a warning dialog appears, but the user cannot delay installation. If no user is logged on, installation occurs automat­ically. If an update requires restart, a five-minute countdown notification appears informing users of the impending restart. Only an administrative user can cancel the restart.

Configuring Automatic Updates Through Group Policy
The Automatic Updates client will, by default, connect to the Microsoft Windows Update server. Once you have installed SUS in your organization, you can direct Auto­matic Updates to connect to specific intranet servers by configuring the registry of cli­ents manually or by using Windows Update group policies.
To configure Automatic Updates using GPOs, open a GPO and navigate to the Com­puter Configuration\Administrative Templates\Windows Components\Windows Update node. The Windows Update policies are shown in Figure 9-7.

The following policies are available, each playing an important role in configuring effective update distribution in your enterprise:
   Configure Automatic Updates The Configure Automatic Updates Behavior determines the behavior of the Automatic Updates client. There are three options: Notify For Download And Notify For Install, Auto Download And Notify For Install, and Auto Download And Schedule The Install. These options are combina­tions of the installation and download behaviors discussed earlier in the lesson.
   Reschedule Automatic Updates Scheduled Installations If installations are scheduled, and the client computer is turned off at the scheduled time, the default behavior is to wait for the next scheduled time. The Reschedule Automatic Updates Scheduled Installations policy, if set to a value between 1 and 60, causes Automatic Updates to reschedule installation for the specified number of minutes after system startup.
   No Auto-Restart For Scheduled Automatic Updates Installations This policy causes Automatic Updates to forego a restart required by an installed update when a user is logged on to the system. Instead, the user is notified that a restart is required for installation to complete, and can restart the computer at his or her dis­cretion. Remember that Automatic Updates cannot detect new updates until restart has occurred.
   Specify Intranet Microsoft Update Service Location This policy allows you to redirect Automatic Updates to a server running SUS. By default, the client will log its interactions on the SUS server to which it connects. However, this policy allows you to point clients to another server running IIS for statistics logging. This dual policy provides the opportunity for clients to obtain updates from a local SUS server, but for all clients to log SUS statistics in a single location for easier retrieval and analysis of the log data, which is stored as part of the IIS log. IIS logs typically reside in %Windir%\System32\Logfiles\W3svc1.
Automatic Updates clients poll their SUS server every 22 hours, minus a random offset.
Any delay in patching should be treated as unacceptable when security vulnerabilities are being actively exploited. In such situations, install the patch manually so that sys­tems do not have to wait to poll, download, and install patches.
After approved updates have been downloaded from the SUS server, they will be installed as configured—manually or automatically—at the scheduled time. If an approved update is later unapproved, that update is not uninstalled; but it will not be installed by additional clients. An installed update can be uninstalled manually, using the Add Or Remove Programs application in Control Panel.

SUS Troubleshooting
Although SUS works well, there are occasions that warrant monitoring and trouble-shooting.
Monitoring SUS
The Monitor Server page of the SUS Administration Web site displays statistics that reflect the number of updates available for each platform, and the date and time of the most recent update. The information is summarized from the Windows Update meta­data that is downloaded during each synchronization. Metadata information is written to disk and stored in memory to improve performance as systems request platform appropriate updates.
You can also monitor SUS and Automatic Updates using the following logs:
Synchronization Log  You can retrieve information about current or past syn­chronizations, and the specific packages that were downloaded by clicking View Synchronization Log in the left navigation bar. You can also use any text editor to open the (Extensible Markup Language) XML–based database (History-Sync.xml) directly from the SUS Web site’s \AutoUpdate\Administration directory in IIS.
Approval Log For information about packages that have been approved, click View Approval Log in the left navigation bar. Alternatively, you can open History-Approve.xml from the SUS Web site’s \AutoUpdate\Administration directory in IIS.
Windows Update Log The Automatic Updates client logs activity in the %Windir%\Windows Update.log file on the client’s local hard disk.
Wutrack.bin The client’s interaction with SUS is logged to the specified statistics server’s IIS logs, typically stored in the folder: %Windir%\System32\Logfiles \W3svc1. These logs, which are verbose and cryptic, are designed to be analyzed by programs, not by humans.
SUS System Events
The synchronization service generates event log messages for each synchronization per-formed by the server, and when updates are approved. These messages can be viewed in the System log using Event Viewer. The events relate to the following scenarios:

   Unable to connect Automatic Updates could not connect to the update service (Windows Update or the computer’s assigned SUS server).
   Install ready—no recurring schedule Updates listed in the event were down-loaded and are pending installation. An administrator must click the notification icon and click Install.
   Install ready—recurring schedule Updates listed in the event are down-loaded and will be installed at the date and time specified in the event.
  Installation success Updates listed in the event were installed successfully.
  Installation failure Updates listed in the event failed to install properly.
   Restart required—no recurring schedule An update requires a restart. If installation behavior is set for notification, restart must be performed manually. Windows cannot search for new updates until the restart has occurred.
   Restart required—recurring schedule When Automatic Updates is config­ured to automatically install updates, an event is registered if an update requires restart. Restart will occur within five minutes. Windows cannot search for new updates until after the restart has occurred.
Troubleshooting SUS
Software Update Services on a Windows Server 2003 computer may require the follow­ing troubleshooting steps:
   Reloading the memory cache If no new updates appear since the last time you synchronized the server, it is possible that no new updates are available. However, it is also possible that memory caches are not loading new updates properly. From the SUS administration site, click Monitor Server and then click Refresh.
   Restarting the synchronization service If you receive a message that the syn­chronization service is not running properly, or if you cannot modify settings in the Set Options page of the administration Web site, open the Microsoft Manage­ment Console (MMC) Services snap-in, right-click Software Update Services Syn­chronization Service and choose Restart.
   Restarting IIS If you cannot connect to the administration site, or if clients can-not connect to the SUS serve, restart the World Wide Web Publishing Service in the same manner.
If Automatic Updates clients do not appear to be receiving updates properly, open the registry of a client and ensure that the following values appear in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate:

WUServer Should have the URL of the SUS server, for example, http: //SUS_Servername
WUStatus Server Should have the URL of the same SUS server or another IIS server on which synchronization statistics are logged
And, in the AU subkey:
Use WUServer Should be set to dword:00000001
SUS Backup and Recovery
As with any other server role or application, you must plan for recovery in the event of a server failure.
Backing Up SUS
To back up SUS, you must back up the folder that contains SUS content, the SUS Administration Web site, and the IIS metabase.
First, back up the metabase—an XML database containing the configuration of IIS. Using the MMC IIS snap-in, select the server to back up and, from the Action menu, select All Tasks, then Backup/Restore Configuration. Click Create Backup and enter a name for the backup. When you click OK, the metabase is backed up.
Then back up the following using Ntbackup or another backup utility:
   The default Web site, which is located unless otherwise configured in C:\Inetpub \Wwwroot.
   The SUS Administration Web site. SUSAdmin is, by default, a subfolder of C:\Inetpub\Wwwroot. In that event, it will be backed up when you back up the default Web site.
   The AutoUpdate virtual directory, also by default a subfolder of C:\Inetpub \Wwwroot.
   The SUS content location you specified in SUS setup or the SUS options. You can confirm the SUS content location in IIS manager by clicking Default Web Site and examining the path to the Content virtual root in the details pane.
   The metabase backup directory, %Windir%\System32\Inetsrv\Metaback, which contains the copy of the metabase made earlier.
This process of backing up the metabase, and then backing up the components of SUS, should be repeated regularly because updates will be added and approved with some frequency.
SUS Server Recovery
To restore a failed SUS server, perform the steps described below. If a certain step is unnecessary, you may skip it, but perform the remaining steps in sequence.
1. Disconnect the server from the network to prevent it from being infected with viruses.
2. Install Windows Server 2003, being sure to give the server the same name it had previously.
3. Install IIS with the same components it had previously.
4. Install the latest service pack and security fixes. If the server must be connected to the network to achieve this step, take all possible precautions to prevent unnec­essary exposure.
5. Install SUS into the same folder it was previously installed.
6. Run NTbackup to restore the most recent backup of SUS. This will include the SUS content folder, the Default Web Site, including the SUSAdmin and AutoUpdate vir­tual directories, and the IIS metabase backup.
7. Open the MMC IIS snap-in and select the server to restore. From the Action menu, select All Tasks, then Backup/Restore Configuration and select the backup that was just restored. Click Restore.
8.Confirm the success of your recovery by opening the SUS Administration Web site and clicking Set Options. Check that the previous settings are in place, and that the previously approved updates are still approved.