Skip to main content


Microsoft Baseline Security Analyzer Frequently Asked Questions

Published: July 1, 2005 | Updated: August 20, 2010

On This Page


Microsoft Baseline Security Analyzer (MBSA) is an easy to use tool that helps small and medium businesses determine their security state in accordance with Microsoft security recommendations and offers specific remediation guidance. Improve your security management process by using MBSA to detect common administrative vulnerabilities and missing security updates on your computer systems.

MBSA 2.2 provides easy access to offline mode and corrects a problem with automatic fallback to the offline catalog if the Microsoft Update site or WSUS Server is not available.

MBSA 2.2 is an update to MBSA 2.1.1 to correct automatic fallback to the offline catalog. MBSA 2.2 adds and corrects a number of minor issues reported by customers including:

  • Added the option to choose offline mode from graphical and command-line interfaces
  • Added support for additional security catalogs (for future use)
  • Added /cabpath command-line option to obtain catalogs from a user-selected directory or network share
  • Corrected automatic fallback to offline mode if Microsoft Update or WSUS servers are unavailable
  • Removed download link in completed scan reports since it is no longer possible to accurately identify the correct package in a multi-package download
  • Removed product version from cache directory path when using offline catalog (CAB) file

These improvements are in addition to the two important functional changes included in the previous version of MBSA:

  • From the command line, customers can now save completed MBSA scan reports to a specific directory or network share using the /rd option in mbsacli. This will allow administrators to script MBSA to output completed scan reports to a specific network share to assist in consolidating MBSA scan reports.
  • In both the command-line and GUI interface, MBSA will no longer automatically update the Windows Update Agent (WUA) on the target machines scanned by MBSA. Administrators will now need to select the option to "Configure computers for Microsoft Update and scanning prerequisites" to install the latest WUA agent on each scanned machine. Automatic installation was the default setting in earlier versions of MBSA. The new default (which disables automatic updating of clients) may cause an increase in scan failures for clients that require a newer WUA client, but ensures administrators that an MBSA scan will not install any revised or updated files on target machines. The command-line interface includes the new /ia option to deliberately enable automatic updates of the WUA client. This replaces the previous /nai option to disable automatic updating of the WUA client – which was the default behavior in earlier MBSA versions.

MBSA offers extended security configuration checks beyond the other Microsoft updating technologies. Furthermore, MBSA is designed to be used in conjunction with Microsoft Update (MU), Windows Server Update Services (WSUS), the SMS Inventory Tool for Microsoft Updates (ITMU), and System Center Configuration Manager (SCCM) 2007 in order to audit and verify the update state of a target machine. MBSA 2.2 offers consistency with the other tools since it also utilizes the common Windows Update Agent (WUA) infrastructure.

MBSA scans for administrative vulnerabilities as well as missing security updates for a variety of Microsoft products. Scanning for administrative vulnerabilities is supported for Windows 2000; Windows XP; Windows Server 2003; Windows Vista; Windows Server 2008; Windows 7; Windows Server 2008 R2; Microsoft Internet Information Services (IIS) 5.0, 5.1, and 6.0; Microsoft Internet Explorer 5.01, 5.5, and 6.0 (including Internet Explorer 6.0 for Windows XP SP2 and Internet Explorer 6.0 for Windows Server 2003); Microsoft SQL Server 7.0, SQL Server 2000 and SQL Server 2005; and Microsoft Office 2000, Office XP, and Office 2003.

Scanning for security updates is dynamic, constantly expanding and is based on the Microsoft Update catalog. To view the products that MBSA can check for missing security updates, refer to the Products Supported by WSUS page. The list of products will change over time as new detection logic is published through Microsoft Update.

Note: For products that are not installed on a scanned computer, MBSA does not perform the security updates check for those products and does not list them in the Security Update Scan Results table in the report.

MBSA will detect a WSUS-managed client and correctly offer only the updates that have been approved by the WSUS administrator. MBSA also allows an administrator to configure MBSA so that the Microsoft Update site is not used for security update evaluation in either the graphical and command-line versions. The completed MBSA scan report will include which sources were used to assess the security state – WSUS Server, Microsoft Update live site, or Microsoft Update (offline) using the file.

Any update published on Microsoft Update as a security update, update rollup, or service pack can be scanned using MBSA. In rare cases, there may be an exception for a unique issue that has security implications. These updates have been defined by Microsoft as follows:

Security update—A broadly released fix for a product-specific security-related vulnerability. Security vulnerabilities are rated based on their severity which is indicated in the Microsoft security bulletin as critical, important, moderate, or low.

Update rollup—A tested, cumulative set of hotfixes, security updates, critical updates, and updates packaged together for easy deployment. A rollup generally targets a specific area, such as security, or a component of a product, such as Internet Information Services (IIS).

Service pack—A tested, cumulative set of all hotfixes, security updates, critical updates, and updates, as well as additional fixes for problems found internally since the release of the product. Service packs may also contain a limited number of customer-requested design changes or features.

If you have corporate hotfixes installed on the scanned computer, detection will observe those updates based on file version as determined by Microsoft. Typically files with a newer than expected version would be accepted, unless Microsoft had determined that a higher versioned file was not secure, in which case the update would be offered in the report.

Note: Updates such as the Malicious Software Removal Tool will be offered by MBSA due to their relationship to certain security issues. This tool has been classified as an update rollup.

Microsoft Update is a a Web site that can scan a single computer and indicate missing/needed security and non-security updates and install them as a group, as long as the computer is connected to the Internet and can reach the Microsoft Update Web site. MBSA allows multiple computers to be assessed for missing/needed security updates at one time by remote scan, whether or not the target computers can access the Internet and the Microsoft Update web site.

Note: Microsoft Update also offers users non-security updates such as "Critical Updates" and "Optional Updates." These non-security updates are not offered by MBSA.

Beginning with SMS 2003 Service Pack 1 and in all versions of SCCM 2007, SMS and SCCM have an integrated tool to access the Windows Update Agent directly for scanning security updates, and they do not use MBSA for scanning. SMS no longer uses MBSA to perform security scans, but rather uses the Microsoft Update technologies used by SMS 2003, SCCM 2007, WSUS Server, SBS Server and MBSA.

MBSA provides support for performing the security updates portion of a scan against the Update Services server that each scanned computer is assigned to as well as performing a standalone scan for customers without an Update Services server. Although administrators can select options in the MBSA to ignore or exclusively observe the Update Services approved list of updates, by default the security scan is performed against the list of approved security updates on the Update Services server and against the complete list of available security updates available in the Microsoft Update catalog. Items not approved on the Update Services server for the scanned computer are given an informational score only and are not scored against the cumulative security assessment score. Items that are approved, but are not installed on the target computer, are given an appropriate warning and are considered security risks.

MBSA provides an Advanced Update Services option to allow target computers that do not have an assigned Update Services server to report an error so that they can be clearly identified to the helpdesk. From a command prompt, this is provided by the /wa (WSUS approved) option.

MBSA is localized into four languages: English, German, French, and Japanese. The underlying update detection will accurately scan target computers in any language supported by the Microsoft Update and Windows Server Update Services technologies.

Not directly, but this file is supported when used in conjunction with the public Windows application programming interface (API) provided by Windows Update Agent. The API accepts this file only with a valid digital signature from Microsoft and uses it to perform a scan of the specified computer. Refer to the Windows Server Update Services Software Development Kit (SDK) for details.

The MBSA EULA must be accepted by the end customer, which prevents MBSA from being integrated into third-party solutions or redistributed by other means.

As a tool without a formal support lifecycle, Customer Support Services (CSS) supports only the latest version of MBSA.

Because clients can be scanned using an online source (Microsoft Update or an assigned Update Services server) in addition to the offline catalog (, the report can include a specific heading called "Catalog synchronization date". If the offline catalog was used, the time that catalog was generated is displayed in the report and can be used to determine if the latest catalog was used. To check the version of the offline catalog, follow these procedures:

Step 1: If you do not have the file, download it from and save it to C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\MBSA\Cache\ You may use any folder, but this is where MBSA will store the file after MBSA has downloaded it.

Step 2: Open C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\MBSA\Cache\ using any program able to view an archive file type of *.cab.

Step 3: Open from the file, and then the package.xml file inside it.

Step 4: View the OfflineSyncPackage header element for the CreationDate. It should be set to a value such as "2010-08-09T22:13:59Z" (for example). Use the value you find to determine when the file was generated by Microsoft.

The latest version of MBSA is version 2.2, which is also referred to as 2.2.2170.0 in the About Microsoft Baseline Security Analyzer link in the graphical interface or when run in the command-line interface. If a newer version of MBSA is released, MBSA will automatically report that a newer version of MBSA is available in the graphical and command-line interfaces. In the command-line interface, this check can be disabled with the /nvc option.

System Requirements

MBSA can be installed, run on, and scan Windows 2000 Service Pack 3 or later, Windows XP Home Edition, Windows XP Professional, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows 2008 R2, with a few considerations. Although MBSA can be installed on Windows XP Home Edition and can perform a local scan, a computer running Windows XP Home Edition cannot be scanned remotely for administrative vulnerabilities. Windows XP Professional can be scanned remotely if it is joined to a domain. If it is not joined to a domain, a computer running Windows XP Professional can be scanned remotely only after the Local Security Setting is set to Classic - local users authenticate as themselves and simple file sharing is disabled.

MBSA does not run on Windows XP Embedded and Windows IA64 platforms, but remote scans against these platforms are fully supported. Windows 2000 Datacenter is not supported by MBSA because the required Windows Update Agent is not supported on this platform.

Clustered SQL Server configurations are supported for local administrative vulnerability scanning, however several specific checks are now documented in the MBSA help for specific limitations in a remote scan. Scanning for security updates uses Windows Update Agent.

Previous versions of MBSA would automatically attempt to install the latest Windows Update Agent on each target machine. With the most recent releases of MBSA, the default setting is meant to prevent installation of any revised WUA client unless the option to "Configure computers for Microsoft Update and scanning prerequisites" is selected by the administrator. Without enabling this feature, the required WUA client may not be present on the scanned computer. This may lead to an increase in the number of warnings listed below, but ensures that – by default – no changes are made to the target machines without administrator consent. If the WUA agent is missing or is a lower version than required to perform a security scan, the completed MBSA scan report will include one of the following errors:

  • "Computer has an older version of the client and security database demands a newer version"


  • "Windows Update Agent not found or the computer is not running Windows 2000 SP3 or later"

No. Windows Update Agent is an integrated part of the Windows platform and an important part of security that enables you to obtain updates from an Update Services server or from Microsoft Update as needed. All Windows computers with an Internet connection running Windows 2000 SP3 or later with Automatic Updates configured, or who have accessed the Microsoft Update Web site, will automatically be updated to the latest version of the WUA client.

Windows Update Agent is a Windows component. This component provides update management and is tightly integrated into the Windows platform. With the recent increase in security, it has become preferable to access and assess machines using a dedicated client present on the machine, rather than leaving the client open to easy access to its root directory and its local registry. For customers with clients that do not connect to the Internet or an Update Services server, MBSA can be used to automatically deploy this Windows component using the "Configure computers for Microsoft Update and scanning prerequisites" option or the /ia option in the command-line interface.

No. But when MBSA scans a computer that is managed by a WSUS Server it will automatically report update status that includes the administrator settings for the WSUS approved updates.

The required services are listed in the MBSA Help file (linked to in the left-hand pane of MBSA user interface). These requirements include Remote Registry service, Server service, Workstation service, File and Printer Sharing service, and Automatic Updates service. The file is downloaded from the Microsoft Web site over HTTP based on your Internet Explorer settings. Remote computer scans are performed by using TCP ports 135, 139, and 445. Where a firewall or filtering router separates two networks, TCP ports 135, 139, and 445, and UDP ports 137 and 138 must be open in order for MBSA to connect and authenticate to the remote computer being scanned.

MBSA does not flag local user accounts with blank passwords for computers running Windows XP using simple file sharing (includes computers running Windows XP Home Edition and computers running Windows XP Professional that are not joined to a domain and that have simple file sharing enabled). By default, these computers do not allow accounts with blank passwords to log on to the computer remotely over the network or for any other logon activity except at the main console logon screen.

Yes, this table describes the support for each platform. Some platforms are provided limited support in this version. Windows 2000 SP4 is a minimum requirement, in addition to the availability of Windows products for each processor type.

Installing MBSA UI
Installing WUA and
configuring Microsoft Update
Security updates
Administrative vulnerabilities
x86SupportedSupportedLocal and remoteLocal and remote
x64SupportedSupportedLocal and remoteLocal and remote
IA64Not supportedManual*RemoteNot supported
EmbeddedNot supportedManual*RemoteRemote

When scanning computers running a Windows XP Embedded edition or an Itanium-based (IA64) computer, the administrator must manually install and configure the appropriate WUA client.

Yes. Office 2000 is not supported by Microsoft Update, so MBSA will not provide security update scans for Office 2000 products. Also, MBSA and Microsoft Update do not support Office installations performed from an Administrative Installation Point (AIP). For more information on AIP installations, please refer to Knowledge Base Article 903773, "No appropriate Microsoft Office updates are displayed when you use Microsoft Update or Windows Server Update Services."

Initial Configuration

No. The latest version of MBSA will upgrade any previous version of MBSA.

MBSA uses your Internet Explorer settings to perform the download. Use the Internet Options settings page of Internet Explorer to configure these settings.

To configure proxy settings in Internet Explorer

  1. In Internet Explorer, click Tools and then click Internet Options.
  2. Click Connections, and then click LAN Settings.
  3. Do one of the following:

    If your network is configured to support auto detection of proxy servers, select Automatically detect settings.


    If your network is not configured to support auto detection of proxy servers, select Use a proxy server for your LAN, and then type the name or IP address of the proxy server in the Address box. If the proxy server uses a nonstandard port, type the port number in the Port box.

You can either perform the scan using the mbsacli command-line utility with the /nd (do not download) parameter, or you can perform the scan using the GUI. Before scanning you must copy the necessary files to the computer performing the scan. Four types of files are required:

After downloading the files from the Microsoft Web site, copy all files listed above to the following folder on the computer performing the security update scan:
C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\MBSA\Cache

Important: To ensure that MBSA has access to the most current versions of these files, you should download them on a weekly basis or after any release of security bulletins from Microsoft. This is especially important in the case of the security update catalog ( because Microsoft releases an updated version of this file whenever new security bulletins are released or updated.

When you run MBSA to perform security update checks on remote computers, MBSA deploys the Windows Update Agent to the remote computer. Although an ia64 version of the Windows Update Agent (WindowsUpdateAgent30-ia64.exe) is available for Itanium-based computers, MBSA does not automatically deploy this version. It must be installed and configured on Itanium-based computers before performing a security scan on those computers.

Step 1: Review system requirements

MBSA cannot scan a remote computer protected by a firewall unless the firewall is configured to open the ports that MBSA uses to communicate with the computer. The Windows Update Agent implements a remote scanning interface based on DCOM. The account being used to scan must possess local administrator rights. The computer must also be configured to meet the following conditions:

  • The Server service, Remote Registry service, and File and Print Sharing service must be running on the remote computer.
  • The required ports must be open on the firewall.
  • The Windows Update Agent must be installed and the Automatic Updates service must not be disabled.

Remote computer scans are performed using TCP port 135, a dynamic or static DCOM port, and ports 139 and 445. Where a firewall or filtering router separates two networks, TCP ports 135, 139, and 445, and UDP ports 137 and 138 must be open in order for MBSA to connect and authenticate to the remote computer being scanned. You must allow these ports to be open on the remote firewall if a personal firewall is being used.

Note: The use of DCOM for remote scanning through Windows Firewall on all versions of Windows XP may require a post-SP2 hotfix as described in Microsoft Knowledge Base article 895200. Customers may now obtain this fix by installing the COM+ update ( Microsoft Knowledge Base article 902400) using these procedures:

  1. Download the update from on the Microsoft Download Center.
  2. Copy the update to the computer you are updating and open a command prompt on that computer.
  3. Run the update using the command-line options described in Microsoft Knowledge Base article 824994 (specifically, the /B:SP2QFE command-line option). Doing this will install all of the Windows XP COM+ Hotfix Rollup Package 9 fixes, in addition to the fixes released in the security bulletin MS05-051.

Step 2: Configure Unmanaged Computers

DCOM allocates a dynamic port by default, but a firewall blocks access to these ports unless explicitly opened by using the following procedure:

  1. Open port 135 and a custom port in your firewall (some firewalls may allow port 135 by default). The port you select should be checked to ensure it is appropriate, or not associated with other applications.
  2. Configure Windows Update Agent to use this static custom port by setting a registry key as follows: HKEY_LOCAL_MACHINE\Software\Classes \AppID\{B366DEBE-645B-43A5-B865-DDD82C345492}\Endpoints REG_MULTI_SZ “ncacn_ip_tcp,0,n” (where n is the port number you have decided to use.) You may also configure the endpoint using the Component Services application in Control Panel. The Windows Update Agent - Remote Access endpoint is located under the path Component Services\Computers\My Computer\DCOM Config. Right-click and select Properties, then use the Endpoints tab on the Properties page to configure the static port.

Step 3: Configure Managed Computers

Use Group Policy to deploy specific administrative firewall and COM+ settings to target computers. You may use the Group Policy editor to create the needed configuration settings as documented in “ Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2”, in the section entitled “Deploying Windows Firewall Settings With Group Policy”.

Windows Firewall Settings: The following Windows Firewall settings should be used:

  • Windows Firewall: Allow remote administration exception. Used to enable remote configuration using tools such as Microsoft Management Console (MMC) and Windows Management Instrumentation (WMI).
  • Windows Firewall: Allow file and print sharing exception. Used to specify whether file and printer sharing traffic is allowed.
  • Windows Firewall: Define port exceptions. Used to specify excepted traffic in terms of TCP and UDP ports. In this step, define the same ports as you selected for unmanaged computers and from the system requirements step.

Additional details on the settings available within the administrative template for Windows Firewall have been documented in “ Using the Windows Firewall INF File in Microsoft Windows XP Service Pack 2” the sections labeled "Enabling Remote Administration" and “Adding Static Ports to Windows Firewall’s Default Exceptions List.”

COM+ Settings: The COM+ endpoint registry settings for the Windows Update Agent can be configured through Group Policy as part of a startup script. Guidance on how to assign startup scripts can be found on the Microsoft Web site: The script must include the following command: reg add HKLM\Software\Classes\AppID\{B366DEBE-645B-43A5-B865-DDD82C345492} /v Endpoints /t REG_MULTI_SZ /d ncacn_ip_tcp,0,n /f (where n is the port number you have decided to use).

Note: When using this method, be aware that additional administrative template settings may be needed in order to remove this registry setting when the functionality is no longer desired.


By default, a scan uses the Update Services server the client is assigned to, if any, as well as the Microsoft Update catalog. The results are compared and any unapproved Update Services updates are given an informational score (blue star) in the report. This allows MBSA to report best practice guidance on the settings for each update with or without an Update Services server.

Using the advanced options, security auditors can choose not to scan with the Update Services list of approved updates or Update Services administrators can choose not to scan with the Microsoft Update list of available updates and focus only on the approved set of updates. There is also a new option in the latest version of MBSA to select offline mode to use only the offline ( catalog file.

If an administrator chooses not to scan with the list of available updates on Microsoft Update, clients without an Update Services server cannot be scanned and will return an error, indicating they may not be getting the correct set of managed updates.

Although the first scan on a particular client will take a longer period of time than usual, subsequent scans will be much faster since the Microsoft Update and WUA configurations will already be established. On subsequent scans, performance depends upon the speed of the connection to the Microsoft Update site or Update Services server, as well as how recently the client has synchronized the catalog from its server. The number and types of products installed can also influence the performance of a scan. Be sure to check these timings based on your own hardware configuration and server settings since performance will vary.

Note: Scanning for the various administrative vulnerabilities can add time to this process, particularly when performing the check for weak passwords.

Scanning in MBSA is not performed in parallel unless multiple copies of MBSA are run at the same time to scan different computers. Mbsacli.exe can be used with the new /listfile (list of computer names or IP addresses) parameter to scan computers listed in a text file containing computer names or IP addresses. This file can be a maximum of 100 MB in size. Using scripting (not provided with the MBSA download package) administrators can populate this text file from an Update Services server target group or from Active Directory.

MBSA downloads the file at the initial scan, or any time the file has changed on the Microsoft Web site. Internet activity caused by MBSA can be completely eliminated by using the /nvc (no tool version check), /catalog (offline catalog file), and /nd (do not download) parameters of the command-line tool described in MBSA Help.

Note: To ensure that MBSA has access to the most current versions of these files, you should download them on a weekly basis or after security bulletins are released by Microsoft. This is especially important in the case of the security update catalog ( because Microsoft releases an updated version of this file whenever new security bulletins are released or updated.

The previous MBSA detection engine has been replaced with the Windows Update Agent, and it has been fully integrated into the MBSA-style scan. For users accustomed to the /HF mode of scanning in previous versions of MBSA, a lightweight solution requiring only Mbsacli.exe and Wusscan.dll is provided using the /xmlout (xml data) parameter. This parameter provides basic output to the console in XML format, making integration with other solutions fast and easy. The output includes all the data elements of the /HF mode and more.

Although the /HF parameters have been replaced with updated MBSA features, a local security update scan that does not include administrative vulnerabilities can be performed using a minimum of MBSA files.

To perform a local security update scan, copy the MBSACLI.EXE and WUSSCAN.DLL files from a full MBSA installation to a new directory on the local machine. You must also download the latest version of the security update catalog ( file and place it in the C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\MBSA\Cache directory.

If this is the first attempt to scan the target machine using MBSA or you want to ensure the WUA client on the local machine is updated to the latest version, you must also place the authorization catalog and latest Windows Update Agent installer file in the same C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\MBSA\Cache directory.

  • Authorization catalog for Windows Update site access (, available from the Microsoft Web site
  • The appropriate platform-specific Windows Update Agent (if not already installed). The latest versions for each platform can be found by examining the contents of the file located at

The /XMLOUT switch must be used to output scan results in this mode. And only a subset of the MBSA command-line features is available in this ("MBSA lite") mode:

  • /catalog (to specify an alternate location for the file)
  • /wa (show only updates approved on WSUS server)
  • /wi (show all updates regardless of those approved on WSUS server)
  • /nvc (do not check for newer version of MBSA)
  • /nd (do not attempt to download files from Microsoft Update site)
  • /unicode (render out in Unicode compliant format)

When using the /xmlout parameter, you must explicitly redirect the XML output into a file using standard console redirection. Also, the XML results must be processed separately from MBSA because they observe a different format than the full MBSA report files. The benefit of this parameter is to avoid the full installation package of MBSA 2.0 when only checking for updates on a single computer. If the minimum system requirements are met, only the engine files mentioned above are needed.

Yes. MBSA fully supports security update scans on x86, x64 and ia64 platforms. MBSA supports vulnerability assessment (VA) scans on x86 and x64 platforms.

Yes. MBSA can scan Windows XP Embedded remotely for security updates if the appropriate Windows Update Agent is already present (not all versions of Windows XP Embedded support installation of the WUA client). Scanning for common security misconfigurations is supported when scanning Windows XP Embedded. Refer to MBSA Help for a detailed description of the security update scanning and administrative vulnerability checking features, and limitations for these platforms.

Note: All MBSA system requirements must be met, so check with the computer's manufacturer or the system administrator of the computer. These requirements include the Workstation, Server, Remote registry, File and Print services and an up-to-date WUA client as listed in the MBSA Help file.

In addition to the current audit message written to the event log, additional events may be written based on the new remote installer used by MBSA to configure the target computer to use Windows Update Agent or Microsoft Update for scanning. An example of an event:

Event Type:Information
Event Source:MBSA
Event Category:None
Event ID:1
Time:1:33:44 PM
Description: Security analysis complete.
Scanned from nnn.nnn.n.n.
Microsoft Baseline Security Analyzer version 2.2.2170.0.

For more information, see Help and Support Center at

When using the MBSA command-line tool (Mbsacli.exe) to scan the local computer, you can only use a Universal Naming Convention (UNC) path or a mapped network drive as the argument to the /cabpath parameter, but not the older /catalog (offline catalog file) parameter.

Valid example commands include:

Mbsacli.exe /catalog (current directory)
Mbsacli.exe /catalog c:\catalogs\ (fully qualified path)
Mbsacli.exe /catalog \folder\ (relative path)
Mbsacli.exe /cabpath c:\catalogs\ (fully qualified path)
Mbsacli.exe /cabpath \\RemoteMachine\cabs (UNC path)


Several checks return a best practice score rather than a failed or potential risk score. These checks provide a link to corrective steps and guidance on the check that should be carefully reviewed. Examples of this include the following checks:

  • Incomplete Updates
  • Windows Firewall
  • SQL Server - Service Accounts
  • SQL Server - Sysadmin role members

The Incomplete Updates check will only report a yellow icon (potential risk) when at least one supported update is in a restart required state. Because there could be other updates in this state that cannot be determined because they were packaged in an older version of the installer, a complete check, and thus a passing score cannot be provided.

The Windows Firewall check will report a green icon (passing score) only when the firewall in enabled without any exceptions. All other configurations will report a blue icon as a means of exposing the details of the settings in the event the exception policy has been deemed safe by the computer administrator.

The two SQL Server checks (Service Accounts and Sysadmin role members) will always report a blue icon because a passing score may not be within the support policy for products that redistribute MSDE or WMSDE derivatives of SQL Server 2000. Only the products that use MSDE or WMSDE can assess the security of the configuration.

Maximum Severity corresponds to the maximum severity rating of the security bulletin issued by Microsoft. For a given security bulletin, there may be several affected products each having a different severity rating. The maximum severity represents the severity associated with the affected product having the highest level of severity within the bulletin. This value allows administrators to better prioritize update risk and deployment urgency.

This value is included in reports only when the offline catalog was used for the scan. When the security update catalog includes Microsoft Update (offline), this will be the case. Using the /catalog (offline catalog file) or /cabpath command-line parameters can ensure that this value is available for all reports and allows a more precise comparison of reports based on a specific point in time for customers that used this field in previous versions of MBSA.

Yes, this is a known issue in the Windows Small Business Server products. This may appear if the SBS Backup User has been used by the backup task at least one time, and will continue until that same user account has been logged into at the console interactively at least one time.

Yes. The updated samples are available at the Microsoft Download Center. The Microsoft Office Visio 2007 Connector for MBSA 2.2 is also a recommended download that may provide even more functionality than what is provided by the script samples.

Text output is provided by default when using Mbsacli.exe. This can be suppressed using the /qt (quiet text output) parameter and is the same output provided by the /ld (list report details) option.

Updates listed in the security update sections of the report represent items that have not been replaced by any newer updates. Many updates released by Microsoft are cumulative and include previous fixes, so it is commonly the case that additional levels of protection are also being provided. The fixes that are included from previous updates in the currently installed updates can be obtained from the security bulletin or the fix list for the update. Also, when installing an update, you can use this section of the report to confirm that the update has been installed by scanning the computer again when the update installation has completed (including any required restart of the computer).

No, the checks and scores used in MBSA cannot be modified. You can, however, use a script and filter out the items you are not interested in monitoring or reporting on.

These ratings help you prioritize and manage the risk associated with the security bulletin findings. A link to additional information is provided at the bottom of each MBSA report using the Result Details for security update checks. Visit the Microsoft Web site to review the specifics of each rating, and how to apply them in your environment.

MBSA displays different icons in the report score columns depending on whether a vulnerability was found on the scanned computer. There are two distinct types of checks performed by MBSA: administrative vulnerability (VA) checks and security update checks.

For the administrative vulnerability checks, a red X is used when a critical check failed (for example, a user has a blank password). A yellow X is used when a non-critical check failed (for example, an account has a password that does not expire). A green checkmark is used when a check passes (that is, no issue was found for that particular check). A blue asterisk is used for best practice checks (for example, checking if auditing is enabled), and a blue asterisk informational icon is used for checks that simply provide information about the computer being scanned (for example, the operating system version of the scanned computer).

For the security update checks, a red X is used when MBSA confirms that a security update is missing from the scanned computer. A yellow X is used for warning messages (for example, the computer does not have the latest service pack or update rollup), and a blue star is used for informational messages indicating either that an update is not of critical nature or that an update is not available to the computer because it has not been approved on the Update Services server. Scores cannot be changed or reassigned for system configuration checks.

Some updates replace files that are currently in use by Windows that cannot be fully installed until Windows is restarted. Updates installed using Automatic Updates, Windows Update, or Microsoft Update will provide an indication of this condition in the MBSA report: a partially installed update will be reported as not installed because a restart is required. In addition, any update that is not fully applied pending a restart is also indicated in the Windows Administrative Vulnerabilities section of a completed scan report. This VA check is not specific to any particular update, but does reflect the potential risk associated with updating any product and not restarting the computer if the update requested a restart. MBSA Help includes instructions you can use to inspect an update package and determine if it is packaged with this version of the installer.

Updates for multiple products within the same bulletin will be shown as different product families in the Issue column of the report summary. Each product-specific variation within the bulletin typically includes a different Knowledge Base article number; however, in some cases there could be multiple updates within the same product category.

For example, if a security bulletin applies to both Windows Media Player and SQL Server, the report summary lists two separate issues, with two separate Result Details to be viewed. In this example, each item would have the same bulletin ID, the standard naming convention for update titles would include the Knowledge Base article number, and the Description column would link to the support article Web page for the issue.

Another example is when more than one product exists within the same family, such as Skype and Windows Media Player (both are components of Windows). This example would provide separate updates in the same Result Details section of the report but share the same bulletin ID. If the product-specific Knowledge Base article ID is needed, the report can be viewed in any XML viewing program (such as Notepad or Internet Explorer), and the KBID attribute will contain the article number.

Finally, shortly after Microsoft Update is released, additional IDs will be included with published updates in the MBSA report that will directly relate to individual vulnerabilities addressed by the bulletin (typically in a "CAN-..." or "CVE-..." format as listed in the actual security bulletin). A new version of MBSA will not be needed, only the new data to be published with the updates being released.

No, the results are stored in the report in the order they are returned to MBSA from the Windows Update Agent. This version of MBSA does not support user-configured sorting in the reports, although the reports can be exported to Excel and sorted or processed by a script to present a certain order to an external application.

MBSA reports on security-related best practices. The Windows Malicious Software Removal Tool is a cumulative, monthly update that removes the residue from known malicious software that may be left behind even after the security bulletin has been applied to the computer. Unless this tool is run periodically, there could be malicious files or settings present on the computer.

Some updates published to Microsoft Update do not include links, however in most cases the security bulletin link will allow users to access the needed information.

The security reports are stored as .mbsa files in XML format in: %userprofile%\SecurityScans by default. From the command-line interface, completed MBSA scan reports can be placed in another directory or network share using the /rd (Report Directory) option in the command-line interface. The graphical interface does not support this new feature.

How to Correct Common Errors

Remote scanning requires that the most current version of the Windows Update Agent be present on the computer running MBSA, so you must install it before scanning remotely. Although MBSA includes a feature that you can use to automatically install the agent, you can also install it manually. You can obtain the installer from the Microsoft Download Center using one of the following links as appropriate for the computer reporting the error message:

  • For x86-based computers (WindowsUpdateAgent30-x86.exe) or
  • For x64-based computers (WindowsUpdateAgent30-x64.exe) or
  • For ia64-based computers (WindowsUpdateAgent30-ia64.exe), the latest versions are available by examining the contents of the file located at

MBSA 2.2 uses a security update cabinet file ( that is formatted differently than the previous version ( The reason for this change is described in Microsoft Knowledge Base article 926464. You will need to download the new offline scan file,, by clicking Save it to C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\MBSA\Cache\

MBSA and the Windows Update Agent require Windows 2000 Service Pack 3 or later. The version check performed by MBSA uses the system registry, so if a remote computer being scanned has the Remote Registry Service disabled, this error will appear. To correct this, ensure the Remote Registry Service is running on the target computer.

This message may appear if the remote installer has been blocked by antivirus or anti-spyware products when performing a remote scan of a computer with the Configure computers for Microsoft Update and scanning prerequisites option selected. You can configure the software that is preventing the MBSA installer from completing the installation to allow MBSA to update the target computer, or you can update the computer manually using the instructions in the FAQ topic MBSA uses files that it downloads from the Internet, but the computer I want to use to scan my network doesn't have Internet access. How can I use MBSA in an offline and secure environment?

This error may appear for several reasons:

  • If the client computer has a registration for an Update Services server, and the server cannot be contacted by the agent, this error will be returned.
  • If the server is on the network, but the client cannot contact the server, this error may also happen and indicates a possible problem in the proxy server configuration or connectivity issues that prevent the network name resolution process from allowing the client to locate the server on the network.

Check the proxy settings of the computer running MBSA, and ensure the assigned WSUS server is accessible on the network.

When downloading the Microsoft Update offline catalog ( before each attempt to scan, downloaded files are checked for a valid Microsoft digital signature before being used. When the file is missing, or the digital signature cannot be verified, these errors may occur.

To avoid this error message, it is recommended that the update (see Microsoft Knowledge Base article 835732) be installed on all Windows 2000 computers running MBSA to perform scanning.

This error may also appear if you use a proxy server such as Microsoft ISA 2000 Server if it does not include a policy that permits anonymous access to the Microsoft Update site. A resolution for this is described in Microsoft Knowledge Base article 885819.

Another cause for this issue may be that Internet Explorer is set to offline mode (Work Offline). MBSA requires either IE to be in online mode and be able to successfully pass through any proxy servers to obtain the file, or you may need to use the steps to obtain the necessary catalog and authentication files as detailed elsewhere in this FAQ for using the file in offline or secure modes when Internet connectivity isn’t available.

Also be sure to confirm both the scanning and target machines have the latest versions of the WUA client, which can also be obtained at the following locations:

  • For x86-based computers (WindowsUpdateAgent30-x86.exe) or
  • For x64-based computers (WindowsUpdateAgent30-x64.exe) or
  • For ia64-based computers (WindowsUpdateAgent30-ia64.exe), the latest versions are available by examining the contents of the file located at

This error means that the version of WUA is lower than the minimum required version stated in Unless the WUA version is equal or greater than the version needed by, scanning the computer will return an error.

To correct this, ensure the latest version of WUA is installed on the target computer. To have MBSA automatically correct this error, be sure to select the option to "Configure computers for Microsoft Update and scanning prerequisites" or use the /ia option in the command-line tool.

This error indicates that the Windows Update Agent was not able to communicate with the assigned Update Services server because of proxy configuration setting on the target computer. If a proxy server is in use, check the target computer's Internet Explorer Internet Options settings and ensure the Update Services server is in the proxy bypass list using either the Bypass proxy server for local addresses setting, or using the Advanced button in the exception list. Using the proxy bypass allows end-users to access the Internet via the proxy server, yet directly access local intranet servers. This is also needed to allow WUA to contact the WSUS server on the local network.

This error is common when scanning based on an IP address range. This is because MBSA will convert the range into a list of specific IP addresses for that range and attempt to resolve each IP address into the associated NetBIOS computer name. When that name resolution cannot be performed because the computer is switched off, or the IP address is not in use, this error will be returned.

The error can also happen when using a domain name of domain members are not accessible on the network, such as a laptop computer roaming outside the wireless network, or a desktop computer that has been shut down.

If you specify a DNS fully qualified domain name (FQDN) as the domain to be scanned, you will also see these errors. In that case, you need to use the NetBIOS compatible domain name.

While it is recommended that the service run as a low privileged account, the application that installed SQL Server/MSDE may require it to run with higher privileges. For example, instances of WMSDE currently are required to run as LocalSystem, and therefore need to be exempt from this check. WMSDE is a derivative of MSDE meant for use by Windows Server 2003 operating system components, such as Windows SharePoint Services. Check the documentation accompanying the application for information on the minimum level of privileges required.

For these reasons, this is an expected message when scanning specific Microsoft products that include MSDE or WMSDE, such as:

  • Windows Server Update Services
  • Windows SharePoint Services
  • Windows Small Business Server
  • Microsoft ISA Server 2004
  • Universal Description, Discovery, and Integration (UDDI)

In many installations (particularly in enterprise environments) it is useful for administrators to distinguish between the roles of the operating system administrator and the SQL Server administrator. In such scenarios it might be useful to remove the local Windows administrators' membership in the SQL Sysadmin role. However, instances of WMSDE currently are required to have the local Windows administrators' membership in the SQL Sysadmin role, and therefore need to be exempt from this check. WMSDE is a derivative of MSDE meant for use by Windows Server 2003 operating system components, such as Windows SharePoint Services. Check the documentation accompanying the application for information on the minimum level of privileges required.

For these reasons, this is an expected message when scanning specific products that include MSDE or WMSDE, such as:

  • Windows Server Update Services
  • Windows SharePoint Services
  • Windows Small Business Server
  • Microsoft ISA Server 2004
  • Universal Description, Discovery, and Integration (UDDI)

Before removing the BUILTIN\Administrators group from SQL Server, it is recommended that there be at least one other login that has administrative capabilities in SQL Server. Certain applications may rely on the ability of the BUILTIN\Administrators group to be able to administer SQL Server.

When scanning and viewing reports, MBSA will read data from This file contains a cab file and a large number of other files that may cause certain antivirus products to consume higher than usual processor and memory capacity when an application accesses These issues have been documented in the Microsoft Knowledge Base article 900638. By default, MBSA will attempt to scan computers using Microsoft Update and the optionally assigned Update Services server, and only uses the file when offline scanning is necessary.

The Windows Update Agent, Windows Update, and Microsoft Update do not support updating Windows 2000 Datacenter Edition. For additional information, refer to the Microsoft Web site. This is not a limitation for the Windows Server 2003 products.

This can happen if simple file sharing is enabled on Windows XP Professional, and will always be the case for Windows XP Home Edition computers being scanned remotely.

Although MBSA can be installed on Windows XP Home Edition and can be used to perform a local scan, a computer running Windows XP Home Edition cannot be scanned remotely for administrative vulnerabilities. Windows XP Professional can be scanned remotely if it is joined to a domain. If it is not joined to a domain, a computer running Windows XP Professional can be scanned remotely only after the Local Security Setting is set to Classic - local users authenticate as themselves and simple file sharing is disabled.

To disable Simple File Sharing, open Explorer, choose Tools, Folder Options, the View tab, and deselect the Use Simple File Sharing checkbox.

You may see error messages such as the following examples:

An unexpected error has occurred. The operating system returned error code <nnn>


An error occurred while scanning for security updates. (0xnnnnnnnn)

Microsoft Knowledge Base article 186063 can explain many error codes that may be returned to users of the WUA API, such as MBSA.

Error codes not listed in Microsoft Knowledge Base article 186063 may generally be located in MSDN.

Error codes returned by the operating system can be converted into text form using the command net helpmsg nnn. Start a command prompt and use this command with the specific error code in place of nnn.

For example:

C:\> net helpmsg 5
Access is denied.

When scanning by using the advanced Update Services option Scan using only the assigned Update Services server (or using the /wa command-line option to scan only WSUS approved updates), it is possible that the administrator of the WSUS server has not included English, German, French, or Japanese in the list of languages for updates that are synchronized from Microsoft Update. If a computer being scanned uses a language that is not available on the Update Services server, a default language is used for the localized properties of the update, and the default language may not be the same as the localized version of MBSA that was installed. For example, if a French edition of MBSA was installed, and only English language updates had been synchronized onto the Update Services server, the French MBSA report may include an English title for one or more security updates.

This check determines whether any services contained in the Services.txt file are installed on the scanned computer and lists the files with their current state (enabled or disabled). The Services.txt file is a configurable list of services to be checked on the scanned computers. The Services.txt file, installed by default with the tool, contains the following services:

  • TlntSvr (Telnet)
  • W3SVC (WWW)

MBSA may report the state of a disabled service, for example Telnet service may be reported as "stopped" rather than disabled. This is a known limitation in MBSA which can be resolved by removing the item from the services.txt file in the MBSA installation folder.

This error can appear when the version of IIS being scanned (on the target computer) is a higher version than on the computer that is running MBSA. This may also indicate that the IIS Common Files are not installed on the computer initiating the scan. If error code 0x80070005 or error code 0x8007007e is returned, it indicates access was denied by the remote IIS computer. This can occur when a remote computer running IIS is authenticated to via net use and scanned; and since the net use connection does not provide authorization for IIS administration, attempts to connect to the remote IIS computer fail with "access denied." For more information, please see the Systems Requirements section in the Readme.html file (installed with MBSA) or in MBSA Help (linked to in the left hand pane of the MBSA console). Note that the IIS 6.0 Common Files are required on the local computer when remotely scanning an IIS 6.0 server.

Depending upon the automatic configuration option selected for the scan, MBSA has the ability to deploy Windows Update Agent and perform a configuration change that allows the target computer to use Microsoft Update for scanning and obtaining updates. If either of these actions is needed for the target computer to be scanned, MBSA checks the Microsoft Web site to ensure it has the latest versions of the files needed for these changes and downloads them if newer files are available. Then, MBSA copies the files to the target computer and performs the configuration changes. This process can take several minutes depending upon network speed and available bandwidth.

MBSA relies on Internet Explorer (IE) settings to download files. Some corporate environments may also use a proxy server. Consequently, the client computer might not be configured correctly to access the Internet through a proxy server.

You must configure Internet Explorer to use your network's proxy server.

To configure proxy settings in Internet Explorer

  1. In Internet Explorer, click Tools and then click Internet Options.
  2. Click Connections, and then click LAN Settings.
  3. Do one of the following:

    If your network is configured to support auto detection of proxy servers, select Automatically detect settings.


    If your network is not configured to support auto detection of proxy servers, select Use a proxy server for your LAN, and then type the name or IP address of the proxy server in the Address box. If the proxy server uses a nonstandard port, type the port number in the Port box.

Yes, the Windows Update Agent provides a log file located at %windir%\WindowsUpdate.log. It can be configured to provide additional detail if needed using a registry setting, and has been documented in Microsoft Knowledge Base article 902093.

Note: Certain logging settings may cause degradation in system performance while scanning, and should only be used while diagnosing a specific issue.

ServerSecure.dll and XmlDb.dll may report registration errors if the system is not properly configured. To try and work around these errors, try the following steps:

Step 1: Click the Ignore button in the setup dialog box for these errors and allow setup to complete.

Step 2: Open a command prompt.

Step 3: Run the following commands (note that after entering each command, there will be a confirmation dialog box; click the OK button on the confirmation dialog, then proceed with the next command.)

Regsvr32.exe /u c:\windows\system32\atl.dll
Regsvr32.exe c:\windows\system32\atl.dll
Regsvr32.exe "c:\Program Files\Microsoft Baseline Security Analyzer 2\ServerSecure.dll"
Regsvr32.exe "c:\Program Files\Microsoft Baseline Security Analyzer 2\XmlDb.dll"

Be sure to adjust the folder names in these commands according to the installation folders for Windows and MBSA as needed.

This error can occur if the file is located in a read-only directory (such as on a CD-ROM). The MBSA command-line utility extracts files from the .cab file by writing files to the directory that the .cab file is in, and will report this error if it cannot write files to that directory. To avoid this error, make sure that is in a directory to which the account running mbsacli.exe has write access.

Windows Server 2003 Service Pack 1 provides an added level of security that prevents multiple connections to the same remote computer from using alternate credentials when the scanning computer is joined to a domain. When scanning a remote target computer and you want to use different credentials than your logged-in credentials, use the following command instead of the mbsacli /u and /p (user name and password) command-line options to specify the account to be used in the remote connection:

C:\> runas /netonly /user:<domain\username> "cmd.exe" (followed by one or more MBSA commands after the new command prompt window opens).


C:\> runas /netonly /user:<domain\username> "C:\Program Files\Microsoft Baseline Security Analyzer 2\mbsacli.exe <add any MBSA command-line options here>"

This is a known issue with MBSA when the computer name is greater than 15 characters and a supported version of SQL Server is present on the target machine.

The only workarounds available at this time are to ignore the result, use the MBSA script samples or Microsoft Office Visio 2007 Connector for MBSA 2.2 to filter out this result item, or, if using the graphical interface (GUI), deselect the option to perform "SQL administrative vulnerabilities" checks.

If MBSA is used within a batch file, you may need to ensure that sufficient redirection is provided for MBSA to capture the correct values. Within batch files, this often requires doubling the "%" indicators on both sides of the variable to ensure it will work correctly. For example, %IP% should be %%IP%% when used within a batch file.

MBSA can only provide reboot pending status when the option to Check for Windows administrative vulnerabilities is selected in the GUI or by default if "/n Updates" is not added to the command-line utility (CLI) to suppress this feature. Reboot pending status is obtained directly from the Windows Update Agent (WUA) client on each target machine. As long as the security update was installed using a WUA-supported process (Windows Update, Microsoft Update, SMS w/ITMU, or WSUS Server), MBSA can report any required pending reboot. If an update has been installed manually or through a third-party installation process, MBSA is unable to report reboot pending state.

For customers using the /xmlout option from the command-line utility, the pending reboot status is not available due to the limitation of using the /xmlout option. Workarounds may include running mbsacli.exe without any switches. This requires the full installation of MBSA (not the "MBSA Lite" installation option to simply install a few necessary files for patch scanning only). This will check the Administrative Vulnerabilities. If there is a pending reboot, it will be reported as listed below:

Issue: Incomplete Updates
Score: Check failed (non-critical)
Result: A previous software update installation was not completed. You must restart your computer to finish the installation. If the incomplete installation was a security update, then the computer may be at risk until the computer is restarted.

Another workaround is to query the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile. More details on the use of this registry key and the values that may be represented can be found at Microsoft Knowledge Base article 832475.

This is often the case when the c$ and remote registry of a target machine are unavailable to the MBSA machine performing the scan. This prevents MBSA from pushing down the necessary catalog file (usually and potentially an updated version of the WUA client bits, due to an inability to obtain administrator and c$ share access to the target machine.

Additionally, if a firewall is present, the multiple steps needed to enable DCOM through a firewall are required (see the MBSA FAQ under the section titled How can I scan a computer that is protected by a firewall?). This includes the need to potentially install the required Microsoft Security Update MS04-011, the QFE version of a non-public hot fix, and possibly firewall configuration changes to enable DCOM connections through the firewall.

After these requirements are met, MBSA will attempt to push down a MUAUTH.CAB file that executes on the remote (target) machine to authorize WUA to take commands from and respond to the scanning MBSA machine. Depending on the settings of MBSA on the scanning machine, MBSA may also attempt to push updated WUA client bits to the target. Any additional error (such as 0x00000005) may be due to insufficient permissions on the remote machine. If after following these steps, the problem is not resolved, it may be appropriate to contact Microsoft Product Support Services (PSS) to determine additional troubleshooting steps. Be sure to obtain a copy of the WindowsUpdate.LOG file on the target machine to help troubleshoot the issue..