0

This all feels like a bug, but I hope someone can prove me wrong.

PS version: 5.1.17763.592

I'm launching a powershell script from a UNC path with the "-file" and "-NoExit" parameter. This is done from a VB.net application. The VB.Net .exe is run as admin, the Powershell session also then starts as admin.

Dim script_path As String = "-NoExit -ExecutionPolicy RemoteSigned -file \\PATH\Test.ps1"
    Process.Start("Powershell", script_path)

This all launches fine, but for some unknown reason this Powershell instance do not behave the same way as if I were to run powershell as admin directly. For example:

Some registry information cant be found or is returned differently.

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Measure-Object

Returns 116 in "-file" instance, 36 in standard instance.

cd "HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\"

Returns not found in -file instance, but it do exist. I have found a few registry keys like this one.

This instance has 13 fewer modules avaliable (Get-Module -ListAvailable | Measure-Object), some cmdlets cant be run, for example Get-LocalUser.

It kind of feels like im remoting to a completely different computer when I'm not.

Same computer, same user, both powershell run as admin. enter image description here

I've tried:

  • Launch from a local directory (Not UNC)
  • Remove -NoExit param.
  • Launching cmd as admin manually then powershell.exe -NoExit -ExecutionPolicy RemoteSigned -file \\UNC\Test.ps1 (This do not have the same limited instance)

I would understand if this mode was somewhat limited and modules need to be imported manually, but it doesnt explain why registry information is returned differently.

David
  • 603
  • 2
  • 6
  • 15
  • Is this possibly a 32-bit/64-bit issue? Which is your VB app targeted at? I assume your OS is 64-bit, but there is also a 32-bit version of PowerShell installed, which will see different modules, etc - for example, `Get-LocalUser` is not found on my system under 32-bit PowerShell, but is ok under 64-bit. What if you run your code using the 32-bit version directly? Do you see the same 'problem' behaviour? – boxdog Sep 20 '19 at 09:20
  • Damn... This came across my mind too but I thought it would not be possible because of the registry keys "not found issue" but I get the same in 32-bit powershell, so looks like this is it. How can it be that 32-bit powershell cant read the same registry information as 64-bit..? – David Sep 20 '19 at 09:32
  • @David This might be of use to you: [How to access the 64-bit registry from a 32-bit Powershell instance?](https://stackoverflow.com/questions/630382/how-to-access-the-64-bit-registry-from-a-32-bit-powershell-instance) – Andrew Morton Sep 20 '19 at 10:32

0 Answers0