WMI win32 access denied workgroup NOT domain 'microsoft you're killing me!'

O.K., desperation time, before I start I am not talking about a Domain
here. I am only talking about a simple home workgroup. I have WMI
security working without trouble at work in our corporate domain, but
can't work out why I can't get it to work at home where I do not want
a domain. Here is my problem. If I use [Computer
Management][Services and Applications][WMI] and bring up the
properties on a local machine, it works fine. If – however – I
<right-click> on [Computer Management] and then connect to any other
computer in my workgroup; then attempt to get the properties of WMI, I
simply receive the message that "Failed to connect to <computer name>
because Win32: access is denied" I have made absolutely sure that the
local administrator's accounts are exactly the same name and password.
I have made absolutely sure that the remote machine's ‘WMI Security
settings' for the local administrator are maxed out and inherited from
"Root" namespace down. I have tried many other bits and pieces, but
simply can't get this to work. In my Corporate Domain at work,
security is set through ‘domain security objects' and I have no
trouble writing scripts that use WMI on remote machines. Just can't
get it to work at home and it is driving me crazy. Please any help on
what to try? Because I can't get the bloody authentication to work, I
can't get Microsoft's WMI explorer to return structures on computer in
my home network other than the one I am working on, which is really a
pain in the #$%^rse.

mark tognella wrote:

> O.K., desperation time, before I start I am not talking about a Domain
> here. I am only talking about a simple home workgroup. I have WMI
> security working without trouble at work in our corporate domain, but
> can't work out why I can't get it to work at home where I do not want
> a domain. Here is my problem. If I use [Computer
> Management][Services and Applications][WMI] and bring up the
> properties on a local machine, it works fine. If – however – I
> <right-click> on [Computer Management] and then connect to any other
> computer in my workgroup; then attempt to get the properties of WMI, I
> simply receive the message that "Failed to connect to <computer name>
> because Win32: access is denied" I have made absolutely sure that the
> local administrator's accounts are exactly the same name and password.
> [snip]
Hi

I'm not so sure that it helps that the username/password is the same,
because it still different users (different SIDs).

Most likely you need to connect with explicit user credentials, use
SWbemLocator.ConnectServer instead of GetObject("winmgmts:...")

IWbemLocator::ConnectServer
http://msdn.microsoft.com/library/e...nnectserver.asp

Subject: Login with explicit username and password
Newsgroups: microsoft.public.win32.programmer.wmi
http://groups.google.com/groups?th=2b5bcad76f5debaa

Subject: ImpersoantionLevel other than impersonate
Newsgroups: microsoft.public.scripting.wsh
http://groups.google.com/groups?th=89ff50603f12dcfb


Also, if this is Windows XP computers, you might have a ForceGuest
as well.

WinXP in a workgroup setting defaults to authenticate all connections
coming from "the network" as the Guest User (only possible to change
on WinXP Pro).

More about this here:
http://groups.google.com/groups?sel...E11%40hydro.com



--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/sc...er/default.mspx

Thanks so much Torgeir. The XP Security Settings\Local
Policies\Security Options setting to Classic was the problem. What a
strange thing for Microsoft to use as a default. Talk about 'a needle
in a haystack.' Thank god you were there to read my post. Ta.

I assume this was happening on XP SP2?

Does it also work if you just run the following command?

netsh firewall set service type=remoteadmin mode=enable scope=all profile=all

"mark tognella" <togbabe@yahoo.co.uk> wrote in message news:3e1ebef8.0408170254.47ce9cf9@posting.google.com...
> Thanks so much Torgeir. The XP Security Settings\Local
> Policies\Security Options setting to Classic was the problem. What a
> strange thing for Microsoft to use as a default. Talk about 'a needle
> in a haystack.' Thank god you were there to read my post. Ta.

mark tognella wrote:
> *Thanks so much Torgeir. The XP Security Settings\Local
> Policies\Security Options setting to Classic was the problem. Wha
> a
> strange thing for Microsoft to use as a default. Talk about '
> needle
> in a haystack.' Thank god you were there to read my post. Ta. *


I have the same problem!

I can't follow the solution that you have found...

Could you please give me a step by step?

Thanks in advance!!


-
edbizz
-----------------------------------------------------------------------
Posted via http://www.mcse.m
-----------------------------------------------------------------------
View this thread: http://www.mcse.ms/message958061.htm

edbizzi wrote:

> mark tognella wrote:
>
>> *Thanks so much Torgeir. The XP Security Settings\Local
>> Policies\Security Options setting to Classic was the problem.
>>
>> What a strange thing for Microsoft to use as a default. Talk
>> about 'a needle in a haystack.' Thank god you were there to
>> read my post. Ta. *
>
> I have the same problem!
>
> I can't follow the solution that you have found...
>
> Could you please give me a step by step?
>
> Thanks in advance!!!
Hi

Mark changed the ForceGuest setting.

WinXP in a workgroup setting defaults to authenticate all connections
coming from "the network" as the Guest User (only possible to change
on WinXP Pro).

More about this here:
http://groups.google.com/groups?sel...E11%40hydro.com



--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/sc...er/default.mspx

Thanks for that explanation and link to the page on how to change the ForceGuest setting.

I had the same problem, computer A (Win XP Pro Desktop) could browse computer B (Win XP Pro Laptop) but once I tried viewing contents within a shared folder I would get the Access is denied error message. I could however, view shared resources on computer A from computer B.

Once I changed it from Classic to GuestOnly and rebooted my system I was able to browse my shared resources on computer B from computer A.

Thanks very much torgeir.

supertone44 wrote:
> Once I changed it from Classic to GuestOnly and rebooted my system I
> was able to browse my shared resources on computer B from computer A.

Wasn't it the other way around? You changed it from Guest Only back to
Classic?

--

Best Regards,

James Crosswell
Software Engineer
Microforge.net Limited
http://www.microforge.net

James Crosswell wrote:
> Wasn't it the other way around? You changed it from Guest Only back to
Classic?

No actually I changed it from Classic to GuestOnly, but now I realize that the Guest account has been turned on which I realize is not good for security reasons.

So, I changed it back to Classic and now I am having the same problem. Any other suggestions? Previously I had read in another post on another forum that if you uninstalled the File and Printer Sharing service and then reinstall them that it fixed the problem for one user so I did that but it did not work.

I can ping each computers ip address and computername from one to the other, so I know there is no conflict with ip addresses or name resolution on the network and I have made sure that each computer is part of the same workgroup and that both computers have a unique name apart from each other and the workgroup name.

I have also tried with my firewall on each system turned off and I get the same results.

Any help with this would be greatly appreciated.

Thanks,

Steve Costello

supertone44 wrote:
> James Crosswell wrote:
>
>>Wasn't it the other way around? You changed it from Guest Only back
>
> to
> Classic?
>
> No actually I changed it from Classic to GuestOnly, but now I realize
> that the Guest account has been turned on which I realize is not good
> for security reasons.
>
> So, I changed it back to Classic and now I am having the same problem.
> Any other suggestions? Previously I had read in another post on another

If you're getting access denied errors then the firewall won't have
anything to do with it (you'd get an RPC Server Unavailable if you
couldn't connect to the appropriate port). So the problem is likely to
do with permission on either the DCOM service or WMI itself.

If you're in a workgroup then you basically have to connect as a user
that is an administrator on the local machine (that you're trying to
connect to. That basically implies (if you want to use a single
username/password to connect to all of the machines on your network)
having a user (say "bob") defined on each and every machine in the
workgroup. "bob" must be a local administrator on each and every machine
and the password for bob must be the same on every machine... bit of a
pain, I know, but without any central authentication system (i.e. a
domain controller) there's no way around this.

Providing you've got such a user and you're connecting using that user's
credentials, you have to look at the security settings on DCOM and WMI.

DCOM
----

1. Click Start, and then click Run.
2. In Open, type DCOMCNFG, and then click OK.
3. Expand Component Services node
4. Expand Computers node
5. Right click My Computer node
6. Select Properties
7. Select [Default] COM Security tab

Under "Default Launch Permissions" you should ensure that at least
INTERACTIVE, SYSTEM, and Administrators have "Allow Launch".

The "Default Access Permissions" should only list SYSTEM.

These are the default values, so you can simply revert to these by
deleting the following registry key:

HKLM\SOFTWARE\Microsoft\Ole\DefaultAccessPermission

WMI
---

1. Click Start, and then click Run.
2. In Open, type DCOMCNFG, and then click OK.
3. Expand Component Services node
4. Expand Computers node
5. Expand My Computer node
6. Expand DCOM Config node
7. Right click Windows Management [and] Instrumentation
8. Select Properties


Verify the following settings
Authentication Level = Default
Launch Permissions = Everyone
Access Permissions = Use Default

Let me know how you get on.

--

Best Regards,

James Crosswell
Software Engineer
Microforge.net Limited
http://www.microforge.net