WMI failing on windows 2000 server in a windows 2003 domain

[Drew]

I have a windows 2000 server with service pack 4 joined to an out of the box
domain in our testing lab.
The problem is that any way i try to connect with basic WMI queries i get an
error.

If I launch wbentest and enter in the connect screen
namespace \\servername\root\default
connection
using |WBemLocator (Namespaces)
returning |WbemServices
Credentials
User domain\administrator
password <password>
authority <blank>


the error message that is returned is
Number: 0x80070005
Facility: Win32
Description: Access is denied.

If i leave the username and password blank i get the same error

I think it is a domain issue because this did not happen before
Thnaks
Drew

[Jason Gurtz]

Post by Drew
the error message that is returned is
Number: 0x80070005

[...]

Post by Drew
I think it is a domain issue because this did not happen before

I had an issue like this that was affecting all the client machines on
our network. we would get access denied trying to connect locally or
remotely (try using wmimgmt.msc, right-click WMI Control and choose
properties)

I opened a case w/ msft support and we found the issue was being
propagated via the Default Domain Policy GPO which was affecting the
following registry key:

HKLM\System\CurrentControlSet\Services\winmgmt\Security\Security
(REG_BINARY)

You can try backing up and then deleting this key, followed by
net stop winmgmt
net start winmgmt

You will probably see the issue resolved then. Next try

secedit /refreshpolicy (gpupdate /force on newer machines)
net stop winmgmt
net start winmgmt

If it is broken again, then you have a problem in the domain/group policy

The end resolution for us was:

- set Windows Management Instrumentation Service, DCOM service, and
MSDTC service policy settings to “not defined"

This solution is odd because these policy settings were only to define
these services to have the startup value of automatic; the security
settings in these policies were the default ones and even regardless of
that, manually adding various groups with appropriate access settings
did not solve the issue. We did not investigate at a low enough level
to determine exactly where in the schema the incorrect security settings
were, but they have got to be in LDAP somewhere; investigation of all
files in the SYSVOL share failed to turn up the invalid settings. Use
of Regmon and Filemon failed to turn up any errors. Since our issue has
been solved I did not get a chance to investigate using the TokenMon
tool <http://www.sysinternals.com/Utilities/Tokenmon.html>. That may be
helpful.

You may also be seeing one or two Event ID: 1090 from Source Userenv in
the application event log followed by a 1704 from SciCli? That would be
a further indication of a problem with GP.

Good luck,

~Jason

--