I've been looking at what WMI is capable of doing the past few days
specifically in regards to computer maintenance.

In this test in my lab domain the shell is running under the context of me a
lowely user with no Admin priviledges on either the local or remote machine.
So I'm providing the credentials of a domain admin when making the call.


## create administrative credentials for remote connections
$pass = ConvertTo-SecureString -string "MakeIt_So" -AsPlainText -Force
$cred = New-Object -typename System.Management.Automation.PSCredential
-argumentlist "Continuum\Picard", $pass

## this shell is running in the context of a normal user but Picard is a
Domain admin
get-wmiobject -class Win32_QuickFixEngineering -computerName Worf
-credential $cred

## The error message returned via stderr is
format-default : Exception retrieving member "Install Date": "Access denied "


$?
false

## PowerShell does not set the LastExitCode
$LastExitCode
0

## However the Error collect does contain the same description and HRESULT
as in the above error message
$Error[0]
format-default : Exception retrieving member "Install Date": "Access denied "



## use the WMI console to access the same class in the same shell and
credentials is successful
wmic /node:Worf /user:Continuum\Picard /password:MakeIt_So qfe
wmic /node:Worf /user:Continuum\Picard /password:MakeIt_So path
Win32_QuickFixEngineering


## The following classes also fail with the same error
Win32_Processor
win32_NTLogEvent

## this WMI query along with many does work
get-wmiobject -class Win32_Bios -computername Worf -credential $cred



I have tried accessing the Win32_QuickFixEngineering remotely on XP, W2K3
and Vista and the all fail if impersonation is used. However when the process
is running under the context of an Admin the same code succeeds.




I believe this to be a PS bug but would appreciate a second look if someone
has time. To repro this the Powershell session must be running under a normal
user account.

again the commands are. Change the credentials and computer name to match
your environment. PS must be run in the context of a normal user; they can't
have admin rights on the remote machine in order to validate whether
impersonation works.

## create administrative credentials for remote connections
$pass = ConvertTo-SecureString -string "MakeIt_So" -AsPlainText -Force
$cred = New-Object -typename System.Management.Automation.PSCredential
-argumentlist "Continuum\Picard", $pass

## this shell is running in the context of a normal user but Picard is a
Domain admin
get-wmiobject -class Win32_QuickFixEngineering -computerName Worf
-credential $cred

thx
bob

On Sep 13, 12:02 pm, Bob Landau <BobLan...@xxxxxx>
wrote:

> I've been looking at what WMI is capable of doing the past few days
> specifically in regards to computer maintenance.
>
> In this test in my lab domain the shell is running under the context of me a
> lowely user with no Admin priviledges on either the local or remote machine.
> So I'm providing the credentials of a domain admin when making the call.
>
> ## create administrative credentials for remote connections
> $pass = ConvertTo-SecureString -string "MakeIt_So" -AsPlainText -Force
> $cred = New-Object -typename System.Management.Automation.PSCredential
> -argumentlist "Continuum\Picard", $pass
>
> ## this shell is running in the context of a normal user but Picard is a
> Domain admin
> get-wmiobject -class Win32_QuickFixEngineering -computerName Worf
> -credential $cred
>
> ## The error message returned via stderr is
> format-default : Exception retrieving member "Install Date": "Access denied "
>
> $?
> false
>
> ## PowerShell does not set the LastExitCode
> $LastExitCode
> 0
>
> ## However the Error collect does contain the same description and HRESULT
> as in the above error message
> $Error[0]
> format-default : Exception retrieving member "Install Date": "Access denied "
>
> ## use the WMI console to access the same class in the same shell and
> credentials is successful
> wmic /node:Worf /user:Continuum\Picard /password:MakeIt_So qfe
> wmic /node:Worf /user:Continuum\Picard /password:MakeIt_So path
> Win32_QuickFixEngineering
>
> ## The following classes also fail with the same error
> Win32_Processor
> win32_NTLogEvent
>
> ## this WMI query along with many does work
> get-wmiobject -class Win32_Bios -computername Worf -credential $cred
>
> I have tried accessing the Win32_QuickFixEngineering remotely on XP, W2K3
> and Vista and the all fail if impersonation is used. However when the process
> is running under the context of an Admin the same code succeeds.
>
> I believe this to be a PS bug but would appreciate a second look if someone
> has time. To repro this the Powershell session must be running under a normal
> user account.
>
> again the commands are. Change the credentials and computer name to match
> your environment. PS must be run in the context of a normal user; they can't
> have admin rights on the remote machine in order to validate whether
> impersonation works.
>
> ## create administrative credentials for remote connections
> $pass = ConvertTo-SecureString -string "MakeIt_So" -AsPlainText -Force
> $cred = New-Object -typename System.Management.Automation.PSCredential
> -argumentlist "Continuum\Picard", $pass
>
> ## this shell is running in the context of a normal user but Picard is a
> Domain admin
> get-wmiobject -class Win32_QuickFixEngineering -computerName Worf
> -credential $cred
>
> thx
> bob

Looks to be similar -- if not the same as -- this issue that MoW
reported some months back:
https://connect.microsoft.com/feedba...6942&SiteID=99

- Oisin

Wow, I am really impressed with the members in this group.

Oisin, I believe it to be the same issue that was reproduced slightly
differently. Where as /\/\o\/\/ or (MoW) found the error accessing the
non-default properties/members.

I stumbled upon it simply by querying the class Win32_QuickFixEngineering.

I don't know how you were able to match the two issues. I did search for
Win32_QuickFixEngineering and came up with no hits. I think I'll still submit
this so that Testing will verify that what is causing the problem with MoW
bug is resolved with this isssue.

"Oisin Grehan" wrote:

> On Sep 13, 12:02 pm, Bob Landau <BobLan...@xxxxxx>
> wrote:

> > I've been looking at what WMI is capable of doing the past few days
> > specifically in regards to computer maintenance.
> >
> > In this test in my lab domain the shell is running under the context of me a
> > lowely user with no Admin priviledges on either the local or remote machine.
> > So I'm providing the credentials of a domain admin when making the call.
> >
> > ## create administrative credentials for remote connections
> > $pass = ConvertTo-SecureString -string "MakeIt_So" -AsPlainText -Force
> > $cred = New-Object -typename System.Management.Automation.PSCredential
> > -argumentlist "Continuum\Picard", $pass
> >
> > ## this shell is running in the context of a normal user but Picard is a
> > Domain admin
> > get-wmiobject -class Win32_QuickFixEngineering -computerName Worf
> > -credential $cred
> >
> > ## The error message returned via stderr is
> > format-default : Exception retrieving member "Install Date": "Access denied "
> >
> > $?
> > false
> >
> > ## PowerShell does not set the LastExitCode
> > $LastExitCode
> > 0
> >
> > ## However the Error collect does contain the same description and HRESULT
> > as in the above error message
> > $Error[0]
> > format-default : Exception retrieving member "Install Date": "Access denied "
> >
> > ## use the WMI console to access the same class in the same shell and
> > credentials is successful
> > wmic /node:Worf /user:Continuum\Picard /password:MakeIt_So qfe
> > wmic /node:Worf /user:Continuum\Picard /password:MakeIt_So path
> > Win32_QuickFixEngineering
> >
> > ## The following classes also fail with the same error
> > Win32_Processor
> > win32_NTLogEvent
> >
> > ## this WMI query along with many does work
> > get-wmiobject -class Win32_Bios -computername Worf -credential $cred
> >
> > I have tried accessing the Win32_QuickFixEngineering remotely on XP, W2K3
> > and Vista and the all fail if impersonation is used. However when the process
> > is running under the context of an Admin the same code succeeds.
> >
> > I believe this to be a PS bug but would appreciate a second look if someone
> > has time. To repro this the Powershell session must be running under a normal
> > user account.
> >
> > again the commands are. Change the credentials and computer name to match
> > your environment. PS must be run in the context of a normal user; they can't
> > have admin rights on the remote machine in order to validate whether
> > impersonation works.
> >
> > ## create administrative credentials for remote connections
> > $pass = ConvertTo-SecureString -string "MakeIt_So" -AsPlainText -Force
> > $cred = New-Object -typename System.Management.Automation.PSCredential
> > -argumentlist "Continuum\Picard", $pass
> >
> > ## this shell is running in the context of a normal user but Picard is a
> > Domain admin
> > get-wmiobject -class Win32_QuickFixEngineering -computerName Worf
> > -credential $cred
> >
> > thx
> > bob

>
> Looks to be similar -- if not the same as -- this issue that MoW
> reported some months back:
> https://connect.microsoft.com/feedba...6942&SiteID=99
>
> - Oisin
>
>