Microsoft Software Update Services: Frequently Asked Questions

Microsoft Software Update Services is a no-charge add-in component for Windows 2000 and Windows Server 2003 that is designed to greatly simplify the process of keeping computers in your organization up to date with the latest critical updates, security updates, and service packs. SUS installs a web-based application that enables administrators to quickly and reliably deploy updates to desktop and server machines running Windows 2000, Windows XP, and Windows Server 2003. The updates can be synchronized from the live Windows Update servers and saved on the SUS server. Then, after approving only the updates you have tested and want to distribute, they can be downloaded from the SUS server by the Automatic Updates component on client machines.

SUS consists of the following downloadable components:

• Microsoft Software Update Services. This is the server component installed on a computer running Windows 2000 Server or Windows Server 2003 inside your corporate firewall. It synchronizes with the Windows Update site to deliver all critical updates for Windows 2000, Windows XP, and Windows Server 2003. The synchronization can be automatic or completed manually by the administrator. When the updates are downloaded, you can test the updates in your environment and then decide which updates to approve for installation throughout your organization. The SUS server component is available in English and Japanese.
• Automatic Updates. The Automatic Update component is included in Windows 2000 Service Pack 3 (SP3) and later, Windows XP SP1 and later, and Windows Server 2003; it can be easily installed on Windows 2000 SP2 and Windows XP RTM. This component enables your Windows servers and Windows client computers to connect to a server running SUS and receive any updates. You can control which server each Windows client should connect to as well as schedule when the client should perform all installations of critical updates—either manually or through Group Policy and the Active Directory directory service. Automatic Updates is available in 24 languages.

Click the links below to download the SUS components:

• Server component - Microsoft SUS (SUS10SP1.exe)
• Client component - Automatic Updates (wuau22*.msi)

Note: The client component download is only required for Windows 2000 SP2 and Windows XP RTM. The client component is included with Windows 2000 SP3 or later, Windows XP SP1 or later, and Windows Server 2003.

• Group Policy component (wuau.adm administrative template)

No. The SUS server is only designed to communicate with the Automatic Updates component on client computers and does not provide for access to an internal Windows Update Web site. Even in a SUS environment, if you click the Windows Update link in the Start menu, you will be directed to the external Windows Update Web site from which you would install updates, instead of from the SUS server.

The Automatic Updates component is supported on Windows 2000 Service Pack 2 (SP2) and later operating systems.

• If you are running Windows 2000 SP2 (either Professional or Server family) or Windows XP RTM, you will need to install the Automatic Updates component using the appropriate language-specific MSI file.
• If you are running Windows 2000 SP3 or later, Windows XP SP1 or later, or Windows Server 2003, the Automatic Updates component comes with the operating system, so there is no need to install the client MSI file.

• The server component of SUS is available in English and Japanese.
• Automatic Updates, the client component of SUS, is available in 24 languages: Arabic, Chinese (Simplified) and Chinese (Traditional), Czech, Danish, Dutch, English, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, and Turkish.

Software Update Services provides the ability to filter Windows operating system (OS) updates by the locale property selected for the OS installation. Updates synchronized from Windows Update to the SUS server will be for only those locales specified. For Windows, only corresponding localized versions can run on the specified locale. For example, only Japanese-localized versions of the OS can run on Japanese locales.

For .NET Framework and Windows SharePoint Services, each localized version can run on any OS locale. For example, a German-localized version of .NET Framework can run on an English OS.

Software Update Services filters updates based on the OS locale but does not support the ability to filter updates for the locales of other OS components, such as .NET Framework and Windows SharePoint Services. Because any localized updates for these components (.Net Framework and Windows SharePoint Services) can run on any component locale, all language versions of the updates are synchronized for these components.

SUS is not intended to serve as a replacement to other enterprise software distribution solutions such as Microsoft Systems Management Server. Many customers are using solutions like SMS for complete software management, including response to security and virus issues. Such customers should continue to use these solutions. To improve the Systems Management Server experience, Microsoft released the SMS 2.0 Software Update Services Feature Pack in the third quarter of 2002—adding security patch improvements and enabling you to determine which computers need software updates.

See Choosing a Security Update Management Solution where you'll find a table that highlights differences between Software Update Services (SUS) and Systems Management Server (SMS) in the area of deploying critical updates.

Yes. They can co-exist and be used together.

No. Other than sharing an acronym, there is no shared code between the two products.

We recommend that you start with the SUS public newsgroup, which is accessible through a browser. In the left navigation pane, click Management Technologies>Main>Software Update Services. If you prefer to use Outlook Express, you can subscribe to the microsoft.public.softwareupdatesvcs newsgroup hosted on the msnews.microsoft.com news server.

Comments and suggestions can be posted to the SUS public newsgroup or sent to the Microsoft SUS feedback e-mail alias at cwufdbk@microsoft.com.

Windows Software Update Services is the next version of Software Update Services (SUS). It is scheduled for release in the second half of 2005. WSUS will extend the capabilities of SUS to enable updating of various versions of Office, SQL Server, Exchange, and additional Microsoft products over time, in addition to updating the versions of the Windows operating systems supported by SUS. WSUS will deliver additional benefits:

• Built-in update status assessment and reporting
• Dramatically increased IT productivity
• Greater administrative control
• Reduced IT costs

Please see the Windows Software Update Services home page for more information on WSUS.

SUS and WSUS are components of Windows 2000 Server, Windows Server 2003, Small Business Server 2000 and Windows Small Business Server 2003. Consequently, SUS is, and WSUS will be, available at no additional charge to licensees of these products.

SUS and WSUS do not have their own client access license (CAL). However, when you are updating your computers that run SUS and WSUS, you will need to access the server on which the SUS or WSUS server component runs, and therefore each computer requires a Windows or Core CAL. Note that this is a licensing requirement for the Windows Server on which the SUS or WSUS server is running, and not a licensing requirement specific to SUS or WSUS.

The general exceptions to this CAL licensing requirement for Windows Server are:

1. When the access is through the Internet and unauthenticated.
2. When the service being accessed can be run on Windows Server 2003 Web Edition (that is, the service and the way in which it is used meet the requirements specified in the product use rights for Windows Server 2003 Web Edition).

Because computers that are updated using SUS or WSUS access the SUS or WSUS server through the organization's internal network, the first exception does not apply to use of SUS or WSUS.

The second exception is applicable when SUS is used and the SUS server is running on Windows Server 2003, Web Edition.

The second exception is applicable when WSUS is used if the WSUS server is running on Windows Server 2003, Web Edition, and the WSUS database is using the default built-in WSUS database or an MSDE database installed on the same computer. Using a remote database invalidates this exception.

To summarize, if you are updating your computers using a SUS or WSUS server running on Windows Server 2003, Web Edition, and you are not using a remote database for the WSUS server, no CALs are required to update these computers. In all other situations, you need a Windows or Core CAL for each computer running WSUS or SUS that you are updating.

Yes. Note that machines covered by a valid Windows or Core User CAL do not require an additional Windows or Core Device CAL.

No. The CAL exception is only available for Windows Server 2003 Web Edition. Any deployment configuration of SUS or WSUS on any edition of Windows 2000 Server requires a Windows or Core CAL for each machine updated by SUS or WSUS.

Depending on the number of machines without a Windows or Core CAL that are being updated through SUS, customers may either:

1. Implement SUS on Windows Server 2003, Web Edition, and use this installation to update the machines that do not have a Windows or Core CAL or
2. Purchase CALs for the machines that do not have them. This option would also allow these machines to benefit from additional services of the Windows Server (for example, authentication, file and print, and other applications or services that may be installed on the server).

Microsoft recommends that customers evaluate the options and make the choice that best meets their needs.

No. Additional Device CALs are not required, unless there are devices that are not covered by the User CALs.

Windows Server 2003, Web Edition, only runs on machines with a maximum of two processors and 2 GB of RAM.

Please see the Windows Server 2003 Web Edition Overview and FAQ.

There is no impact. SUS and WSUS use the HTTP protocol, not the SMB protocol.

No. The built-in WSUS database and MSDE do not have database CAL requirements.

No, this is not permitted per the product use rights for Windows Server 2003, Web Edition.

If WSUS accesses a remote SQL Server instance, a Windows or Core CAL and a SQL Server CAL are required for each user or device updated through WSUS. SQL Server may also be licensed on a per processor basis instead of a per user or per device basis. Please see How to Buy SQL Server for more information on SQL Server licensing.

SUS 1.0 supports updates for Windows 2000 (with Service Pack 2 and later), Windows XP Professional, and Windows Server 2003. It does not include provisions for updates to any other Microsoft products such as Microsoft Office, SQL Server, or Exchange Server.

Yes. Microsoft is committed to providing you a means to help keep your network secure. All security updates associated with Security Bulletins for Windows are included in SUS.

The following updates are supported:

• Windows Critical Updates
• Windows Security Updates (Critical, Important, Moderate, and Low)
• Windows Update Rollups
• Windows 2000, Windows XP, and Windows Server 2003 Service Packs

The Windows Update Web site is refreshed with security updates (and other content) at the same time as security bulletins are released. We strive to release updated SUS content at the same time as it becomes available on Windows Update, but occasionally there may be a short delay (2 to 3 hours).

Yes. Service packs are now available through SUS starting with Windows 2000 SP4 and Windows XP SP1. Future service packs for Windows Server 2003 will also be made available through SUS as the service packs are released.

SUS now delivers service packs. The service packs use a command-line switch to install in quiet mode, so no user interaction is needed. The service packs also use a command-line switch to create backup files so that the service packs can be uninstalled, if necessary.

If you run out of disk space, it is possible that you are syncing more than the necessary languages for your environment. With only one language selected, the disk space required to save the updates locally has gone from approximately 300 MB to 1.5 GB. To check how many languages you are syncing, go to the SUS Admin page, click Set Options in the left navigation pane, and then check locales for which you are synchronizing content. If you are synchronizing more languages than you want, you will need to do the following:

• Click Clear All.
• Select the check box for only the languages you need to distribute to clients.
• Click Apply.
• Navigate to the \SUS\Content\Cabs folder on your hard drive.
• Delete all content in that folder.
• Synchronize your SUS server. This will pull down only content for the languages that you have selected now.

The Automatic Updates user interface (UI) is probably not hanging but is instead waiting for the service pack install to complete. There is no animation to indicate that the install is continuing, and you will not receive feedback about the progress of the install until it is complete. This is especially true since the service pack install is done in quiet mode with no UI from the service pack installer. The service pack install can take several minutes, especially on slower hardware, so the best option is to wait until the Automatic Updates UI indicates that the install has finished.

Service packs (as well as certain other updates) are exclusive in nature, meaning that they should be installed separately from any other update. When the Automatic Updates client detects updates and one of them is exclusive, only the exclusive update will be offered for install on the client machines. This ensures that after install and reboot, the next detection cycle by the Automatic Updates client will offer and install only updates that are applicable to the new service pack.

No. It is not possible to integrate your own updates or third-party updates into SUS.

No. SUS 1.0 does not support the delivery of drivers, even though the Automatic Updates component does attempt to detect drivers. The "Windows Update.log" file on computers running Windows XP or Windows Server 2003 will contain the following entry when checking for updates available on your SUS server:

Error IUENGINE Querying software update catalog from
http://mysusserver/autoupdatedrivers/getmanifest.asp (Error 0x80190194)

This entry is expected on computers running Windows XP or Windows Server 2003 and does not interfere with the ability of SUS and Automatic Updates to deliver and install critical Windows updates.

New content is typically released weekly on Wednesday mornings (PST), although occasionally there is no new content to release. On rare occasions, new content or updates to the detection of content may be released on days other than Wednesday.

The SUS e-mail notification service keeps you informed of the latest critical updates as soon as they are available. These optional e-mail alerts are for informational purposes only and are not required to run SUS.

Occasionally, the mailer system used for the SUS e-mail notification service has a backlog of e-mails to send.

No. In the current version of SUS, there is no way to selectively download only one platform type of updates that you intend to distribute. This is a feature that we plan to integrate into future versions of SUS.

This most often occurs because the detection criteria for an update has changed—not because the update itself, or the update binaries, have changed. If the update itself ever changes (binary change), that would be documented in the knowledge base (KB) article associated with the update.

This is normally caused by improper detection criteria, combined with the fact that the update is either failing to install each time or succeeding each time but not creating something for which the update detection is searching. If you have computers that suffer from this type of problem, first consult the KB article related to the update to verify that installation is occurring. Then check the SUS public newsgroup to see if the problem is already known.

SUS 1.0 is not natively aware of updates that supercede previous updates. Internet Explorer (IE) cumulative patches are the best example of that. As best practice, when each new IE cumulative patch is released and you approve it for distribution, you should also un-approve all previous IE cumulative patches. You should also check KB articles for all other updates for supercedence information and un-approve any updates on the SUS server that have been superceded by other updates also on the SUS server.

Not at this time.

An Intel X-86 or compatible P700-level processor, 2 megabytes (MB) of RAM, and 6 gigabytes (GB) of available hard-disk space.

Up to 15,000 clients can be supported by a single SUS server. You can also use multiple SUS servers in a single environment.

Yes. SUS 1.0 with SP1 allows for this. However, Microsoft recommends that you run SUS 1.0 SP1 on a dedicated server that has no other roles in your environment.

Yes. SUS 1.0 with SP1 allows for this. Please note that SUS SP1 will also function on Microsoft Windows Small Business Server 2003.

As a result of security enhancements in Windows Server 2003, you may encounter problems accessing the SUS site after you install SUS SP1. Please read the SUS SP1 Release Notes for a full description of how to resolve this issue.

The updated administrative template, with additional SUS with SP1 functionality exposed, can be downloaded at Software Update Services 1.0 ADM File for Service Pack 1.

The wuau.adm file should be installed on a computer that is being used to administer your domain-based group policies. Follow these steps:

1. Copy wuau.adm to %windir%\inf. (Replace the existing wuau.adm file.)
2. In the Group Policy tree, right-click Administrative Templates under the Computer Configuration tree.
3. Select Add/Remove Templates.
4. If "wuau" is listed in the Current Policy Templates, click Remove. If it is not listed, go to the next step.
5. Click Add and select wuau.adm. Then click Open.
6. Verify that "wuau" is now listed in the Current Policy Templates, then click Close.
7. The policies to configure the Automatic Updates component on client computers can now be found in Computer Configuration>Administrative Templates>Windows Components>Windows Update.

This can occur if the original setup for SUS 1.0 was done by running the MSI file directly from the Internet, instead of saving it locally and then running it. When the SUS with SP1 setup attempts the upgrade, it must read certain information from the previous MSI installer before proceeding. To fix this issue, you should uninstall SUS 1.0 and then re-install SUS with SP1. The following steps help make the uninstall/re-install easier. Completing these steps will prevent the need to re-download all updates, will preserve the previous sync and approve history, and will also retain the list of currently approved updates so that the SUS administrator will not need to determine what has already been tested and approved.

1. Copy the contents of the \SUS\Contents\Cabs folder to a back-up location.
2. Copy the following files to a back-up location:

\wwwroot\approveditems.txt \wwwroot\autoupdate\dictionaries\approveditems.txt \wwwroot\autoupdate\dictionaries\settings.txt \wwwroot\autoupdate\administration\history-sync.xml \wwwroot\autoupdate\administration\history-approve.xml

3. Uninstall SUS 1.0.
4. Install SUS with SP1.
5. Copy the files and folders that you backed up to their original locations.
6. Restart the WuSyncService by following these steps:

Run Services.msc from a command prompt. Locate Software Update Services Synchronization Service. Right-click, then choose Properties, and then choose Restart.

7. Open the SUS Admin page, and then verify your settings and approved items.
8. Synchronize the SUS server.

The proxy configuration in SUS settings is used by the SUS server only if it downloads from the public Windows Update servers. SUS-to-SUS synchronization does not use the proxy configuration information specified in the SUS settings. When the SUS server synchronizes against another SUS server, it uses a WinHTTP called WINHTTP_ACCESS_TYPE_NO_PROXY. This is by design, to prevent internal SUS servers from syncing content, and possibly approved updates, from a rogue SUS server set up on the Internet.

SUS 1.0 only works when configured to use Port 80, and the Automatic Updates component on the clients are only capable of communicating with the SUS server on that port.

One method is to push the contents to a new drive. To do so, follow these steps:

1. Create a new partition on the new drive.
2. Move the contents of the \SUS\content folder over to the root of the new partition.
3. In the Computer Management snap-in, go to the Disk Management section.
4. Right-click the new partition and select Change Drive Letter and Path.
5. Select Add, then select Mount in the following empty NTFS folder.
6. In the same dialog box, select the path to the original copy of the content folder (e.g. C:\SUS\content).

This can occur if the date on your SUS server is not correct and is remedied by reseting the date.

This can typically be accomplished by using host headers that allow the computers in the DMZ to reach the SUS server that is not in the DMZ.

Prior to moving SUS to a new server, it is best if you use Group Policy to set the Automatic Updates (AU) component to a disabled state, then move to the new SUS server and re-enable AU. Failure to do this will cause download jobs that are in progress to continue attempting to download from the old server.

If you do have download jobs attempting to hit the old SUS server, you can delete them using the BITSAdmin tool, which is included on the Windows XP and Windows Server 2003 CDs. You can find examples of how to use this tool at BITSAdmin Examples on MSDN.

If you already had URLScan installed prior to installing SUS and it is set to block all *.exe files, SUS install doesn't change that URLScan setting, so the client computers will not be able to download any of the patches or updates. In order to correct this problem, you need to change urlscan.ini to allow *.exe requests, and then restart Internet Information Services (IIS) or restart the SUS server.

Another common cause of not being able to download updates is when the "server name" entry in the SUSAdmin>Set options page does not match the name specified in the Automatic Updates policy (WSUServer).

SUS only requires communication through port 80.

You need to allow access to the following URLs:

• www.microsoft.com/download
• http://technet.microsoft.com/wsus/bb466196.aspx

Beginning with Windows 2000 Service Pack 3 (SP3) and Windows XP Service Pack 1 (SP1), the Automatic Updates component has been included in the service packs, eliminating the need to download and install the client component separately. The Automatic Updates component is also included in Windows Server 2003.

Please see KB article 326693, How to Force Automatic Updates 2.2 to Perform a Detection Cycle, for this workaround.

If the end user is part of the local administrators group, he or she will be able to interact with Automatic Updates (AU) by initiating downloads or installs. If the end user is not part of the local administrators group, he or she will not be able to interact with AU and will not see the AU balloon or tray icon. For end users who are not local administrators, the only way that AU will properly update their machine is if scheduled installs are set.

You can use SUS reporting features described in the Software Update Services Deployment White Paper, but that is only applicable to updates installed through SUS. For general verification of whether updates are installed properly:

Microsoft recommends that you run the Microsoft Baseline Security Analyzer (MBSA) to see if the clients have all the required updates.

You can also run the KB article for each update available through SUS explains how to determine if the respective update is properly installed on computers with different platforms. You can easily access many of the KB articles by clicking the Details link for the update in the SUS Approve Updates page, and then clicking the Info icon in the update description.

If you are using SUS 1.0 SP1, you can set the NoAutoRebootWithLoggedOnUsers policy to prevent reboots from occurring if any user is logged on when the scheduled install occurs. It is not possible to prevent the automatic reboot if there are no users logged on to the computer when the scheduled install occurs.

After creating registry keys (instead of using policy) to configure the Automatic Updates (AU) component, you need to either restart the AU service, or restart the computer, in order to get the AU client to pick up the new settings.

To install the Automatic Updates component now, follow these steps:

Get the original winnt.sif or unattend.txt file that was used for setup.

Modify the unattend file and change AutoUpdate = On in the [Components] section. Leave everything else the same.

Copy the file to a share that has open access.

In a script, run "sysocmgr.exe /i:%windir%\inf\sysoc.inf /u:<path_to_unattend.txt> /q."

Note that if the original unattended setup was done on Windows XP RTM and then Windows XP SP1 is applied, you may also need to use the /f switch with the sysocmgr command.

On the client machine(s), open %windir%\Windows Update.log and look for entries that look like http://mysusserver/autoupdate/getmanifest.asp to confirm that the Automatic Update component is being properly redirected to your SUS server.

Even if the Automatic Update client is being redirected to your SUS server, if you have not disabled (through policy) or prevented (through firewall) access to the external Windows Update Web site, your users can still access that Web site through the browser. Accessing the external Windows Update Web site through the browser will result in it being logged to the Windows Update.log file.

To verify that the live Windows Update Web site is being accessed through the browser, and not through the Automatic Updates component, look for a call to https://v4.windowsupdate.microsoft.com/consumerdrivers/getmanifest.asp. This indicates that the external Windows Update Web site is being accessed, since Automatic Updates uses a call to http://CorpWU-01/autoupdatedrivers/getmanifest.asp on Windows XP and Windows Server 2003, and does not check for drivers at all on Windows 2000.

No. Users need only have a valid CAL to access the server on which SUS is hosted—for example, through Windows 2000 Server, Windows Server 2003, or Windows Small Business Server 2003.