Thank you for posting this on the MBSA discussion group.
Although I don't know how your application works, MBSA scans using the
results determined from the target client's WUA client. If the client has
connectivity to Microsoft Update, the client makes its assessment based on
live data from the Microsoft Update web site and reports results back to
If the client is WSUS assigned, then the WUA agent will both try to scan
using MU, then filter those results based on the WSUS admin's approved
list - and provide a result to MBSA.
If the client is not WSUS-assigned and does not have direct access to the
Microsoft Update live web site, then the offline CAB (wsusscn2.cab) file
will be used. This file will be passed over the wire to the client, the WUA
client will make its assessment, then report back to MBSA.
The logic across all sources (MU, WSUS, offline CAB) is all the same, but
MBSA only reports on Service Packs, Rollups and Security Update - nothing
else (not optional updates, no drivers - nothing else). So the results
across these data sources should always be the same - excepting for items
not approved by a WSUS admin in a WSUS-managed case.
If at any time in any of these processes, the logic from any source (MU,
WSUS, offline CAB) indicates that the target WUA client version isn't high
enough to process the included logic, MBSA will deploy an updated WUA client
and submit a MUAUTH.CAB file that authorizes WUA to respond to MBSA.
Without this, MBSA would never get a response from WUA as it would not be
considered an authorized caller.
Beyond the explanation and use of WSUSSCN2.CAB, its contents and the use of
MUAUTH.CAB, it would be more helpful to know which updates are displaying in
your application and which updates are displayed by MBSA. Since direct
access and use of the CAB file isn't supported, I would be concerned that
your application may not be extracting/assessing the contents of the CAB
file correctly or may be missing critical content that's needed for your
particular client. I mention this because MBSA uses the same technology as
the live Microsoft Update web site - and any error at that level is usually
reported by customers very quickly and fixed immediately - which ultimately
trickles down to MU, WSUS, SMS, SCCM and MBSA results directly thereafter.
Feel free to get more details on the MUAUTH.CAB and WSUSSCN2.CAB file from
the MBSA home page at www.microsoft.com/mbsa
Doug Neal [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
If newsgroup discussion with experts and MVPs is unable to solve a problem
to your satisfaction, feel free to contact PSS for support on the Microsoft
Baseline Security Analyzer (MBSA). Information is available at the following
This e-mail address does not receive e-mail, but is used for newsgroup
Post by Harry Johnston [MVP]
This would be best answered by the folks in
microsoft.public.security.baseline_analyzer. Forwarded to that group by
cross-post for the convenience of the OP.
I have a two part question here.
First, I use an application that uses wsusscn2.cab to scan for needed
patches. I have a test machine I use, and when I use wsusscn2.cab, it
shows I need 20 patches. If I use the same file from the MBSA program,
it shows I need 22 patches. Doesn't MBSA use the same wsusscn2.cab file
that anyone can download from Microsoft? I wonder why the 2 patch
Second - what is the muauth.cab file for? Is that for being able to
detect Device Drivers, Hotfixes, Updated system files, Service packs, and
New Windows features?
I only ask because my application will only scan for patches since it
only uses the wsusscn2.cab file to scan against - however, MBSA uses the
same file, but also the wuredist.cab file and the MBSA program will pick
up many old patches (for example, ms04-044 - which is a patch from 2004;
very old one).
Thanks in advance.