Discussion:
Cannot deploy security metadata. (0x00000005) PLEASE HELP!!
(too old to reply)
Kryten
2009-03-23 20:01:54 UTC
Permalink
Hi Everyone,

Really desperate to resolve this issue; it's driving us all crazy
here!

We have been able to scan our servers from the command line of mbsa
without any issue at all until the end of last week, when every scan
results in
a .txt file with this error contained within and no hotfix information
at all.

I've ensured that I'm using the latest version of MBSA and the latest
wsusscn2.cab
I've uninstalled and re-installed.
I've rebooted all the machines.
I've quadruple checked that I'm using the ADMINISTRATOR user acccounts
for the scans.
I've observed that I CAN successfully scan for SQL or IIS or OS or
Password, just don't work for Updates.
I've observed that I CAN query the WMI Win32_QuickFixEngineering class
with Powershell - no problem.
I am logging in to the server that I'm running the scans from as the
Administrator.
I have verified that I have the latest version of Windows Update Agent
on all the targets.

Every scan results in this error.

Please, please help if you can.

Thanks,
Stuart
Doug Neal [MSFT]
2009-03-24 16:12:04 UTC
Permalink
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
2.0 from pushing down the necessary catalog file (usually WSUSSCN2.CAB) 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 2.0 FAQ under the section
titled, "How can I scan a computer that is protected by a firewall?"). This
includes the need to potentially install a required Microsoft Security
Update number MS04-011, the QFE version of a non-public hot fix as well as
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 2.0 machine.
Depending on the settings of MBSA 2.0 on the scanning machine, MBSA 2.0 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.



It may be necessary to ensure Distributed COM is enabled and that the
Windows Update Agent has sufficient remote access rights on the remote
(target) machines.



To check and update these settings on the target computer, direct access to
the remote computer in necessary. On the remote (target) computer, use the
following steps:

a.. From a command prompt, type DCOMCNFG (or alternatively, open Component
Services from an MMC console)
b.. Expand Component Services | Computers | My Computer
c.. From the My Computer node, right click the 'My Computer' node and
choose Properties
d.. From the 'Properties' dialog, confirm the option to 'Enable
Distributed COM on this computer' is selected - then click OK
e.. From the My Computer node, expand the DCOM Config node
f.. Right-click the 'Windows Update Agent - Remote Access' object and
select Properties
g.. From the 'Windows Update Agent - Remote Access' Properties dialog,
select the 'Security' tab
h.. In the Security tab, choose EDIT to select each node to ensure the
appropriate workgroup or domain credentials that will be used by the
scanning MBSA 2.x machine are included in each of the 3 sections.
--
--
Doug Neal [MSFT]
***@online.microsoft.com

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
link:
http://support.microsoft.com/default.aspx

This e-mail address does not receive e-mail, but is used for newsgroup
postings only.
Post by Kryten
Hi Everyone,
Really desperate to resolve this issue; it's driving us all crazy
here!
We have been able to scan our servers from the command line of mbsa
without any issue at all until the end of last week, when every scan
results in
a .txt file with this error contained within and no hotfix information
at all.
I've ensured that I'm using the latest version of MBSA and the latest
wsusscn2.cab
I've uninstalled and re-installed.
I've rebooted all the machines.
I've quadruple checked that I'm using the ADMINISTRATOR user acccounts
for the scans.
I've observed that I CAN successfully scan for SQL or IIS or OS or
Password, just don't work for Updates.
I've observed that I CAN query the WMI Win32_QuickFixEngineering class
with Powershell - no problem.
I am logging in to the server that I'm running the scans from as the
Administrator.
I have verified that I have the latest version of Windows Update Agent
on all the targets.
Every scan results in this error.
Please, please help if you can.
Thanks,
Stuart
Kryten
2009-03-24 20:31:35 UTC
Permalink
Doug,

Thanks for the detailed and thoughtful reply.

I can verify that I can attach effortessly to the C$ on each target
server and
that AU and remote registry etc are all running on the targets. I can
manually copy the wsusscn2.cab across to the target and back again.

The targets all have the latest Update Agent installed.

The Account and Password I am using on each target is the Admin
account for the
target.

I have carried out the DCOM config you kindly detailed, as well as
turning
off the firewall and temporarily disabling AV. All to no avail.

I'm running out of ideas. Unless there are any other suggestions I
think it
might be time to engage MS, what do you think?

Thanks,
Stuart
Doug Neal [MSFT]
2009-03-25 23:14:44 UTC
Permalink
I'm sorry this didn't resolve the issue. You may want to consider
contacting CSS using the link below my signature line. There should be no
charge for the call since this is a security issue - specifically for the
security scan tool MBSA.

Please let me know if and how this is resolved so I can ensure you've been
supported and the issue resolved to your satisfaction. Thanks.
--
--
Doug Neal [MSFT]
***@online.microsoft.com

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
link:
http://support.microsoft.com/default.aspx

This e-mail address does not receive e-mail, but is used for newsgroup
postings only.
Post by Kryten
Doug,
Thanks for the detailed and thoughtful reply.
I can verify that I can attach effortessly to the C$ on each target
server and
that AU and remote registry etc are all running on the targets. I can
manually copy the wsusscn2.cab across to the target and back again.
The targets all have the latest Update Agent installed.
The Account and Password I am using on each target is the Admin
account for the
target.
I have carried out the DCOM config you kindly detailed, as well as
turning
off the firewall and temporarily disabling AV. All to no avail.
I'm running out of ideas. Unless there are any other suggestions I
think it
might be time to engage MS, what do you think?
Thanks,
Stuart
Loading...