The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The Software Update Services Feature Pack for Systems Management Server 2.0—usually called the SMS 2.0 SUS Feature Pack—was a genuine Microsoft add-on released in late 2002. It extended an existing SMS 2.0 installation with security-update and Office-update inventory, update-package creation, targeted deployment, scheduling, and Web-based reporting.
It was not the standalone Software Update Services server, and it is not a usable patch-management product today. SMS 2.0 reached the end of extended support on April 12, 2011; Microsoft subsequently retired its scan tools and update catalogs. The Feature Pack is now primarily useful as historical documentation of how Microsoft moved from manual patching toward centralized software-update management.
As an Amazon Associate I earn from qualifying purchases.
What the SMS 2.0 SUS Feature Pack was
Microsoft Systems Management Server 2.0, or SMS 2.0, was an on-premises systems-management platform for collecting inventory, organizing computers into collections, distributing software, and producing reports. The SUS Feature Pack added specialized tools for finding and deploying certain Microsoft security and Office updates through that existing SMS infrastructure.
The name is easy to misunderstand. The Feature Pack was related to Microsoft’s Software Update Services initiative, but it was an SMS 2.0 add-on, not simply the standalone SUS server product and not an early version of modern Windows Server Update Services (WSUS). SMS remained responsible for client communication, inventory, collections, advertisements, package distribution, scheduling, and reporting.
Contemporary coverage describes the Feature Pack as released in November 2002. It was available as an add-on rather than a separately licensed modern endpoint-management platform, but it still required a functioning SMS 2.0 environment and all of the administration, database, client, and distribution infrastructure that implied. See the contemporary technical walkthrough and architectural review.
Why Microsoft built it
By the early 2000s, worms such as Code Red and Nimda had demonstrated the operational consequences of leaving known vulnerabilities unpatched. Finding the right update was only one part of the problem. Large organizations also needed to determine which computers were affected, test updates, distribute the correct files, control reboots, and prove what had happened afterward.
SMS software distribution could already deploy executable packages, but administrators had to perform much of the update research and targeting manually. That process was slow and error-prone across large estates. The Feature Pack attempted to combine vulnerability assessment with SMS software distribution: scan computers, store the results in the SMS database, select applicable updates, build deployment packages, advertise them to collections, and report on the outcome.
The five principal components
1. Office Inventory Tool for Updates
The Office Inventory Tool for Updates (OUIT) inventoried supported Office products and their update state. Historical documentation describes support for Office 2000 and Office XP. It commonly ran on a schedule such as weekly, returned its findings through SMS inventory, and made the results available for reporting and deployment decisions.
Installation created SMS programs and advertisements with names including Office Update Tool, Office Update Tool (expedited), and Office Update Tool Sync. The exact behavior depended on the historical package and the SMS configuration.
2. Security Update Inventory Tool
The Security Update Inventory Tool (SUIT) scanned clients for installed operating-system security updates and compared local results with Microsoft’s security-update catalog. Its scan technology was based on the Microsoft Baseline Security Analyzer 1.2 generation, not a current vulnerability scanner.
Scan data was collected through SMS inventory mechanisms and stored in the SMS database. The results could identify updates applicable to particular computers and feed those findings into the distribution workflow. That did not mean the tool detected every missing update or supported every Microsoft product.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →3. Distribute Software Updates Wizard
The Distribute Software Updates Wizard automated much of the administrative work involved in turning update metadata and downloaded files into SMS deployments. It could help administrators:
- select relevant updates;
- download or locate update files;
- create SMS packages and programs;
- specify installation parameters;
- distribute content to SMS distribution points;
- target selected collections; and
- track deployment status.
It was an automation layer over SMS software distribution, not an all-knowing patch installer. Administrators sometimes had to repair source files, correct download locations, choose the correct update variant, or enter installer switches manually.
4. SMS Web Reporting
SMS Web Reporting provided browser-based views of update and inventory data, including installed and missing updates, patch status by computer, patch status by update, and patch status by product. It also exposed broader hardware inventory, software inventory, site, and status information.
5. SMS Additional Web Reports
The Additional Web Reports component supplied further report definitions for examining SMS data. Together with the standard reporting tools, these reports helped administrators investigate patch coverage and identify computers that required attention.
Recommended Free Tools
How its architecture worked
The Feature Pack is best understood as a pipeline rather than a single patch-management service:
- Synchronize metadata. Obtain the relevant historical Microsoft catalog or update information.
- Scan clients. Run the Office or Security Update Inventory Tool through SMS advertisements.
- Collect inventory. Clients return scan results through the SMS client and inventory process.
- Evaluate applicability. The site compares discovered machine state with the available update information.
- Create a package. Use the Distribute Software Updates Wizard to create or select an SMS package and source directory.
- Define installation behavior. Specify the correct command-line parameters for the particular update.
- Target collections. Use SMS collections based on operating system, service pack, location, inventory data, or other criteria.
- Advertise and deploy. Deliver the package through SMS software distribution, usually beginning with a test collection.
- Refresh inventory. Rerun the scan and hardware inventory, allowing results to reach the site.
- Review reports. Confirm installation, identify reboot-pending systems, and investigate failures.
This sequence explains an important distinction: a scan result was inventory data, not instantaneous compliance. Several independent programs, advertisements, inventory cycles, site-processing steps, and report refreshes could intervene between installation and the status visible to an administrator.
Historical installation prerequisites
Contemporary technical material identifies SMS 2.0 Service Pack 3 or later as a prerequisite. The precise requirements could vary by SMS edition, feature, service pack, hotfix, client platform, language, and update package. A surviving archive should therefore be checked against the particular environment rather than treated as a universal compatibility chart.
A historically workable installation also required:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- an operational SMS 2.0 site;
- SMS clients installed and communicating with the site;
- working hardware inventory;
- appropriate administrative permissions and service accounts;
- database and reporting infrastructure supported by the SMS release;
- access to the period’s update catalogs and binaries;
- test computers or collections; and
- the correct language and platform version of each update.
The original package is commonly identified as SMSSUSFP_enu.exe. It unpacked individual modules that were then installed separately. That filename describes historical distribution; it does not establish that the package remains officially available or safe to use.
A representative SMS 2.0 deployment procedure
The following describes the period workflow for archival understanding only. It is not a recommendation for deploying security updates today.
Install and unpack the modules
Run the historical Feature Pack package, commonly named SMSSUSFP_enu.exe, and unpack the component installers. Install the Office inventory, Security inventory, distribution, and reporting components into the SMS environment as appropriate.
Synchronize update information
Run the relevant synchronization program to retrieve update metadata that was current for that period. Security-update catalog data was associated with files such as mssecure.cab. Historical catalogs and download endpoints should not be assumed to work now.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteScan clients
Run the generated scan advertisements against the intended client collections. Wait for scan results to return to the SMS site before relying on the wizard to determine applicability.
Create and distribute a package
In the SMS 2.0 Administrator’s Console, use the Distribute Software Updates Wizard to select the scan tool, choose the applicable updates, create or select an SMS package, define a source directory, obtain the update files, and set installation parameters. Distribute the package to a test collection before expanding the advertisement.
Handle installer switches carefully
Historical Microsoft update packages did not all use the same command-line syntax. Examples documented for particular packages include:
/q:a /r:nand, for some Windows 2000 or Windows XP packages:
/quiet /norestartThese are examples, not universal Feature Pack switches. A no-restart option may suppress an automatic reboot while leaving the update inactive or incompletely detectable until the computer restarts.
Refresh the status
After deployment, rerun the Security Update Inventory Tool or Office Inventory Tool. Then trigger hardware inventory—for example, through the Systems Management applet on the client—allow the results to upload and process, and refresh the Web Reports.
One historical console example schedules a report from:
Site Database > Tools > Reports > QueriesIt refers to scheduling All Systems by System Name through the report’s task menu. These labels belong to the SMS 2.0 Administrator’s Console; modern Configuration Manager, Intune, WSUS, and Windows Update interfaces do not use the same paths.
What it could cover—and what it could not
Capabilities
- inventory of operating-system security updates within the supported historical scope;
- inventory of Office updates for supported Office versions;
- targeted deployment through SMS collections and advertisements;
- scheduled update operations;
- centralized reports by computer, update, and product; and
- integration with existing SMS software distribution.
Limitations
The Feature Pack depended on old scanners, catalogs, operating systems, Office versions, and installer conventions. Downloads could fail, historical links could be incorrect or broken, and different update formats could cause the wizard to stumble. Status reporting could also lag behind the actual client state because scanning, hardware inventory, site processing, and report refreshes were separate steps.
Free tools Windows power users keep installed
One-click scans. No signup required.
Microsoft’s later retirement notice documented significant limits in the SMS 2.0 and SMS 2003 scan tools. SUIT and ESUIT did not support Internet Explorer 7 or later, and the Office Detection Tool used by OUIT had been deprecated. Microsoft also noted unsupported product areas including SQL Server, MSDE, and Windows MSDE. The tools therefore could not provide comprehensive validation across an entire Microsoft estate.
Best Value
Other practical problems included reboot requirements, stale catalogs, language and architecture mismatches, dependence on healthy SMS clients, limited coverage outside the catalog’s supported products, and possible false positives or false negatives. The Feature Pack had no contemporary support for modern Windows servicing models, cloud-managed devices, or current security baselines.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common failure modes
The scan runs but reports do not change
First confirm that the advertisement actually executed. Then verify client-to-site communication, start or schedule Hardware Inventory Agent, check SMS status messages, allow inventory data to process, and refresh the report only after new data has reached the site.
The wizard cannot download an update
Possible causes include retired links, broken historical URLs, the wrong language or architecture, catalog inconsistency, supersedence changes, or an installer format the wizard cannot recognize. Historically, an administrator could obtain the correct file from a verifiable source, confirm its product and prerequisite chain, place it in the expected source directory, configure the command line manually, and test it on a non-production computer. That recovery path is not a reason to deploy the system today.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteAn update remains “not ready”
A historical walkthrough notes that an update could remain unready until installation parameters were specified. Use the wizard’s syntax or properties information, then verify the switches against documentation for that specific update. Do not assume that parameters from another package apply.
The update installs but remains listed as missing
Possible explanations include a pending reboot, missing hardware inventory, wrong language or architecture, a stale catalog, an installation command that did not do what was expected, or a scanner that could not properly detect the product or update. Separate these states: the installer ran; the update is active; the computer has rebooted; and the inventory report has refreshed.
Feature Pack fixes and hotfix history
Microsoft KB 837782 lists historical fixes and related Knowledge Base references for the Feature Pack. It is useful when documenting an old installation or reconstructing the product’s maintenance history, but a KB archive does not prove that every fix remains obtainable, applicable, or compatible with a surviving site. Consult the archived KB material in the context of the exact SMS release and service-pack level.
Retirement and successor context
SMS 2.0 reached the end of extended support on April 12, 2011. Microsoft stated that its Security Update Inventory Tool and Extended Security Update Inventory Tool would be retired and that update catalogs would no longer be provided. Microsoft recommended moving to newer update-management tooling, including the System Center Configuration Manager-era product line.
Historically, SMS 2003 incorporated related software-update functionality more directly; the Distribute Software Updates Wizard that had been a separate SMS 2.0 installer became integrated into SMS 2003’s software-update functionality. SMS 2003 is also obsolete. Later Configuration Manager products were the on-premises successor line, but modern Configuration Manager does not work by installing the SMS 2.0 SUS Feature Pack.
For a surviving SMS 2.0 environment, the sensible objective is containment, documentation, and migration—not using the Feature Pack to claim that an unsupported Windows estate has been brought into compliance. Microsoft specifically warned that the old scan tools had limited scope and could create risk if relied upon for broad update validation.
Terminology at a glance
| Term | Meaning in this history |
|---|---|
| SMS 2.0 | Microsoft’s legacy on-premises systems-management platform. |
| SUS | Software Update Services, the historical Microsoft update-service family and concept associated with the Feature Pack. |
| SUS Feature Pack | An add-on that used SMS 2.0 for inventory, targeting, distribution, scheduling, and reporting. |
| MBSA | Microsoft Baseline Security Analyzer; the Security Update Inventory Tool used MBSA 1.2-generation scanning technology. |
| WSUS | A later Windows update-management service; it is not the same architecture as the SMS 2.0 Feature Pack. |
| Configuration Manager | The later enterprise management product line descended from SMS; it does not use the SMS 2.0 add-on. |
Why it matters historically
The SMS 2.0 SUS Feature Pack marked an important transition in enterprise patch management. It recognized that patching was not merely downloading an executable: administrators needed inventory, applicability assessment, controlled rollout, reboot planning, and evidence. Its limitations also show why later products needed better catalogs, broader product coverage, more reliable detection, tighter integration, and support for newer servicing models.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
