Effective patch management is a complicated process that involves several stages. The solution you choose must be able to help you with each of these.
Inventory and assessment – Identify missing patches and the devices that need them. You also need to determine which computers already have them installed, as well as get a count of devices missing each patch.
Patch testing – A lot of testing has already been done for you by the OS vendor, but they can’t account for every application since everyone’s computing environment is different. They may not always catch every conflict. So it still makes sense to do a test deployment on a subset of machines to discover any conflicts with applications deployed by your organization.
Deployment – Distribute the patches to your live environment after confirming there are no conflicts with any of your existing applications.
Verification – Verify that the patch installed correctly is present and is no longer needed by the target computers.
Proactive Patch Management
Having a proactive patch management strategy in place can provide immediate and tangible benefits for both your organization and its end users. Greatly reduced downtime, lower rates of virus infection and hacker attacks and fewer resources spent on fixing client devices are all benefits that you can enjoy.
Patch management can be a cumbersome and daunting task. With the right patch management strategy, it doesn't have to be that way. Proactive patch management leads to considerably lower unexpected downtime, happier end users and significant cost savings.
What are the minimum requirements for WSUS?
For WSUS 3.0, Windows Server 2003 SP1 or later and Windows Server 2008 are supported. For Windows 2000 Server, you must download WSUS 2.0 SP1.
What can be patched with WSUS?
WSUS supports a wide range of operating systems and applications which is constantly updated. However as a reference, Windows 2000 Professional SP3 or later, Microsoft Office XP (2002) or later, Microsoft SQL Server, Exchange Server 2000 or later and Windows Defender are some of the more common platforms supported.
What Classifications are supported?
Critical Updates, Definition Updates, Drivers, Feature Packs, Security Updates, Service Packs, Tools, Update Rollups and Updates are available to choose from.
SMS
The primary scanning tool you’ll need is the SMS 2003 Inventory Tool for Microsoft® Updates, or ITMU. The ITMU scans each client computer to detect whether updates are needed for each client, and reports that information back to the SMS site server.
If you still have Windows NT® 4.0 clients or Windows® clients that don’t have SP3, then you’ll want to continue to use the Security Update Inventory Tool and the Microsoft Office Inventory Tool for updates.
Because these scanning tools are modular, rather than being built into SMS itself, the framework exists for third parties to develop additional scanning tools for their own products.
MBSA
The Microsoft Baseline Security Analyzer provides a streamlined method to identify missing security updates and common security misconfigurations. MBSA 2.3 release adds support for Windows 8.1, Windows 8, Windows Server 2012 R2, and Windows Server 2012. Windows 2000 will no longer be supported with this release.
Scanning for Secure Configuration
In addition to scanning for missing security updates, MBSA scans for system configurations—also referred to as vulnerability assessment (VA) checks—that are not secure. For a detailed list of what is checked by this scan, see the MBSA documentation included in the MBSA Help file. The secure configuration scan can be done in the following phases:
- Perform the scan.
- Analyze the scan.
- Correct any issues that you find.
The next sections describe each of these phases.
Performing the Scan
Run MBSA and clear the Check for security updates check box when performing the scan.
Analyzing the Scan
The resulting report appears similar to the patch scan described earlier. When you click the link, a page appears with the details of the issue found, the solution to the issue, and instructions to correct the issue.
Compare the issue details against your security policy and if the issue is not addressed by your policy, follow the provided instructions.
Correcting Issues Found
For each issue listed in the scan report, click the How to correct this link. The page that appears provides the solution and instructions to correct the issue.
Requirements for Performing Remote Scans
MBSA uses the following network services to scan a computer:
Windows NT 4.0 SP6 and later, Windows 2000, Windows XP (local scans only on Windows XP computers that use simple file sharing), Windows Server 2003, Windows Vista, or Windows Server 2008.
- IIS 4.0, 5.0, 5.1, or 6.0 (required for IIS vulnerability checks)
- SQL Server 7.0, 2000 (required for SQL vulnerability checks)
Note: If any of the services are unavailable or disabled, administrative shares (C$) are not accessible, or if these services do not have an exception configured in the Windows Firewall, the scan will result in errors.
Password Scans
Password check performed by MBSA may take a long time, depending on the number of user accounts on the computer. The password check enumerates all user accounts on the target computer and performs limited password change attempts using common password pitfalls, such as a password that is the same as the user name. To limit the impact of weak password checks of domain controllers, MBSA does not perform a full set of weak password checks against domain controllers. For information about the MBSA password check, see "Security update checks" in the MBSA Help file.
Differences Between Mbsa.exe and Mbsacli.exe
For most functions of MBSA, the GUI tool, Mbsa.exe, and the command-line tool, Mbsacli.exe, perform the same functions. In some cases, the command-line interface provides more technical options for advanced administrators. The following command-line switches are examples of command-line interface–based features that are not available in the MBSA GUI tool:
/nvc.
This switch instructs MBSA to not attempt to connect to the Internet to check for an updated version of the MBSA scan tool.
/qp.
This switch instructs MBSA to not show scan progress.
/qt.
This switch instructs MBSA to not display the completed scan report immediately after a scan completes.
/Unicode.
This switch instructs MBSA to provide the completed scan report in Unicode format.
/u.
This switch lets you specify the user name of an administrator-level user on the target computer(s).
/p.
This switch lets you specify the password of an administrator-level user on the target computer(s).
/catalog.
This switch lets you specify an alternate location for the offline catalog (Wsusscn2.cab) file.
/rd.
This switch lets you specify an alternate location for the completed scan report. (This is useful when running MBSA in a non-user context or as a domain administrator.) You can use this switch to place completed scan reports on a network share or in a local directory.
/nd.
This switch instructs MBSA to not download any files from the Microsoft Web site when performing a scan. In other words, it instructs MBSA to perform the scan like it would in offline mode.
/xmlout.
This switch instructs MBSA to perform a security scan (no vulnerability assessment checks) using the most basic files necessary to perform an MBSA scan (Mbsacli.exe and Wusscan.dll) without performing a full MBSA installation. This is useful for performing a basic security scan without having to install all MBSA features. This mode allows a limited set of command-line switches, including only /catalog, /wa, /wi, /nvc, and /Unicode. When the mbsacli command runs without any command-line switches, it runs a default scan against the local computer.
