Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 607
  • Last Modified:

PS Remoting returning local data instead of remote

Anyone ever seen this before?
I'm using PowerShell Remoting to query a remote machine for a couple of registry values (I'll just show one for this example).  What I'm currently seeing is when I run Get-Item, the values returned are actually for my local machine (I confirmed this by changing one of the registry values and re-running the command).  When I run Get-ItemProperty however, the value returned is from the remote machine.  See the code block below for examples of running the commands and look at the "Start" value.

PS C:\test\ps> Invoke-Command -computername wkstn1.domain.com -scriptblock {Get-Item HKLM:\System\CurrentControlSet\Services\msahci }


    Hive: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services


Name                           Property                                    PSComputerName                            
----                           --------                                    --------------                            
msahci                         Start           : 2                         wkstn1.domain.com               
                               Type            : 1                                                                   
                               ErrorControl    : 3                                                                   
                               ImagePath       :                                                                     
                               \SystemRoot\system32\drivers\msahci.sys                                               
                               Group           : SCSI Miniport                                                       
                               DriverPackageId :                                                                     
                               mshdc.inf_amd64_neutral_a69a58a4286f0b22                                             

PS C:\test\ps> Invoke-Command -computername wkstn1.domain.com -scriptblock {Get-ItemProperty HKLM:\System\CurrentControlSet\Services\msahci }


Start           : 0
Type            : 1
ErrorControl    : 3
ImagePath       : \SystemRoot\system32\drivers\msahci.sys
Group           : SCSI Miniport
DriverPackageId : mshdc.inf_x86_neutral_f64b9c35a3a5be81
PSPath          : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\msahci
PSParentPath    : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
PSChildName     : msahci
PSDrive         : HKLM
PSProvider      : Microsoft.PowerShell.Core\Registry
PSComputerName  : wkstn1.domain.com
RunspaceId      : a9ce6130-b4c5-4bca-8691-6391477b3e93
 

Open in new window


I have a feeling it's just a quirk of my machine, that it's entered a weird state after being up too long, and that it will go away after I reboot it, but I wanted to throw the question out there to see if anyone else had experienced it.  I'm running Win7 64-bit with PS 3.0 installed.
0
footech
Asked:
footech
  • 7
  • 5
3 Solutions
 
cantorisCommented:
What does this show:
Invoke-Command -ComputerName wkstn1.domain.com -ScriptBlock { ipconfig } 

Open in new window

Is that your IP or the remote machine's?

And from your machine, try
ping wkstn1.domain.com
and
nslookup wkstn1.domain.com

Any surprises there?

Finally, I presume when you changed one of the registry values, you were just using regedit, not PowerShell?
0
 
footechAuthor Commented:
That shows the IP of the remote machine.

All the DNS info is correct.  Both ping and nslookup return the correct info.  I've also referenced the remote machine by both its FQDN and its NetBIOS name to make sure there's no difference there.

Yes, when I changed the registry value I just used regedit.

Now for some additional information.
I have rebooted my machine and the behavior is still occurring (I really thought it would go away after a reboot)!  I have performed the same query against a different remote machine than what I did yesterday and the results are the same.

I'm starting to think PS 3.0 might be involved in some way.  I've only got a couple of machines with PS 3.0 installed to test with though, and one is down for the weekend.  Here's the results when I run the same Get-Item command on a different machine with PS 2.0 installed.
PS C:\temp> Get-Item HKLM:\System\CurrentControlSet\Services\msahci


    Hive: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services


SKC  VC Name                           Property
---  -- ----                           --------
  0   6 msahci                         {Start, Type, ErrorControl, ImagePath...}

PS C:\temp> Invoke-Command -computername mywkstn.domain.com -scriptblock { Get-Item HKLM:\System\Cur
rentControlSet\Services\msahci }


    Hive: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services


SKC  VC Name                           Property                                 PSComputerName
---  -- ----                           --------                                 --------------
  0   6 msahci                         {Start, Type, ErrorControl, ImagePath... mywkstn.domain.com

Open in new window

You'll probably notice in the above that it doesn't return any info about the values for the properties, and unless I use Get-ItemProperty I can't see the values.  I also see the same results as above when I enter an interactive remote session.  I think the machine I had the remote session to had PS 3.0 installed, but not certain, so I'll have to confirm with another machine that I'm certain of.
I'll perform some more tests on Monday with another PS 3.0 machine.
0
 
footechAuthor Commented:
I was wrong in my last post.  The machine I was connecting to with a remote session had PS 2.0 installed, so the reason for the difference in output was not at all related to being in a remote session.
So there's definitely different behavior depending on whether PS 3.0 is installed or not vs. PS 2.0 (haven't tested PS 4.0).  It seems PS 3.0 likes to try to display some info about the values contained within a registry key when you use Get-Item, whereas PS 2.0 does not (it only shows the info as seen in the last post).

I have repeated my tests from another machine with PS 3.0 installed and it shows the exact same behavior as my original machine I was testing with - namely that the info about registry values that PS 3.0 tries to display may not be correct when you're trying to use PS Remoting to query another machine.  It seems like it always tries to fill in this information with data from the local machine.  It's worth to note that this does not take place when you are in an interactive remote PS session.
0
Veeam Task Manager for Hyper-V

Task Manager for Hyper-V provides critical information that allows you to monitor Hyper-V performance by displaying real-time views of CPU and memory at the individual VM-level, so you can quickly identify which VMs are using host resources.

 
cantorisCommented:
Just a weird thought, try passing in the registry path in your script block in single quotes.

I've also seen different output from the registry provider between PowerShell versions before, though I've not used it massively.
0
 
footechAuthor Commented:
Unfortunately single quotes have no effect.

I'll do a little more reading to see if I can find any other report of similar behavior, but it seems like I've stumbled on quirk of PowerShell.
0
 
footechAuthor Commented:
Busy week and I couldn't get back to this sooner...
The explanation for this behavior appears to come from the formatting file "Registry.format.ps1xml".  In PS 3.0 it tries to be helpful by displaying info about the values contained within the key retrieved by Get-Item.  Here's the relevant section:

$result = (Get-ItemProperty -LiteralPath $_.PSPath |
    Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider |
    Format-List | Out-String | Sort).Trim()
$result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
if($result.Length -eq 5000) { $result += "..." }
$result

Open in new window

The object returned from a query of a remote machine will have a PSPath property that looks like "Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\msahci".  When the formatting of the object occurs back on the local machine, it uses this PSPath with Get-ItemProperty, and so is actually doing a lookup on local values.

It seems the appropriate solution would be for PS to recognize when the registry object returned is a deserialized object and adjust its formatting correctly to handle this situation.  Get-Item isn't really meant to get values from the registry, only keys (Get-ItemProperty should be used when interested in the values), so when the formatting tries to "helpful", in this scenario it is actually providing false data about the values.

I might see if I can change the formatting to handle this better, but I've never played around with the formatting before so we'll see.  Also it's not a critical issue since I know to use Get-ItemProperty when looking for registry values and their data.
0
 
cantorisCommented:
Nice find!
That's quite an astonishing oversight on MS's part.  Have you tried it in PowerShell 4 to see if it does it there too?
0
 
footechAuthor Commented:
Unfortunately I can confirm that it still occurs with PS 4.0.
0
 
cantorisCommented:
In that case, perhaps you should report it here:
https://connect.microsoft.com/PowerShell
0
 
footechAuthor Commented:
Thanks for the suggestion, I have done so.
0
 
footechAuthor Commented:
Ultimately I was able to find the answer behind the behavior myself, but I appreciate cantoris' willingness to bounce some ideas around.
0
 
cantorisCommented:
Many thanks for the points - very generous given that you fixed the problem yourself!
0

Featured Post

NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now