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 -scriptblock {Get-Item HKLM:\System\CurrentControlSet\Services\msahci }

    Hive: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Name                           Property                                    PSComputerName                            
----                           --------                                    --------------                            
msahci                         Start           : 2                              
                               Type            : 1                                                                   
                               ErrorControl    : 3                                                                   
                               ImagePath       :                                                                     
                               Group           : SCSI Miniport                                                       
                               DriverPackageId :                                                                     

PS C:\test\ps> Invoke-Command -computername -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  :
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.
LVL 43
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

What does this show:
Invoke-Command -ComputerName -ScriptBlock { ipconfig } 

Open in new window

Is that your IP or the remote machine's?

And from your machine, try

Any surprises there?

Finally, I presume when you changed one of the registry values, you were just using regedit, not PowerShell?
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 -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...

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.
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.
Defend Against the Q2 Top Security Threats

Were you aware that overall malware worldwide was down a surprising 42% from Q1'18? Every quarter, the WatchGuard Threat Lab releases an Internet Security Report that analyzes the top threat trends impacting companies worldwide. Learn more by viewing our on-demand webinar today!

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.
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.
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 += "..." }

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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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?
footechAuthor Commented:
Unfortunately I can confirm that it still occurs with PS 4.0.
In that case, perhaps you should report it here:
footechAuthor Commented:
Thanks for the suggestion, I have done so.
footechAuthor Commented:
Ultimately I was able to find the answer behind the behavior myself, but I appreciate cantoris' willingness to bounce some ideas around.
Many thanks for the points - very generous given that you fixed the problem yourself!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.