I'll get a blank "Name" and "Property" column.
That does not indicate a problem per se; it is merely a display problem - see bottom section.
While you could use the [Microsoft.Win32.RegistryHive] type directly to get what you want, it'll be more complex and more verbose than using PowerShell's Get-ItemProperty cmdlet.
Get-ItemProperty by itself lacks the ability to target a remote registry, but you can combine it with PowerShell remoting, which may require prior setup on the target computer - see about_Remote_FAQ.
# Create a session on the target computer.
# The target machine must have PowerShell remoting enabled.
# You may have to specify credentials with -Credential
$session = New-PSSession -ComputerName '192.168.200.10'
# Use Invoke-Command with the session to execute your commands remotely.
$64bit = Invoke-Command -Session $session {
get-itemproperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKU:\${using:sid}\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Select-Object DisplayName, DisplayVersion, UninstallString, PSChildName |
Where-Object { $_.DisplayName -like "${using:process}*"}
}
$32bit = Invoke-Command -Session $session {
get-itemproperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
Select-Object DisplayName, DisplayVersion, UninstallString, PSChildName |
Where-Object { $_.DisplayName -like "${using:process}*"}
}
# Close the session.
Remove-PSSession $session
Important: Note how local variables $sid and $process are referenced as ${using:sid} and ${using:process}, which is necessary for the remotely executed script block to see them.
Note that output received via remoting undergoes serialization on the remote side and deserialization on the local side, which means that only a few well-known types are deserialized as their original types. All others are approximations of the original objects with static property values, based on the [pscustomobject] type.
While that can be a problem on occasion, it won't be in your case, since the objects that your command outputs are [pscustomobject] instances to begin with, due to use of Select-Object.
As for your original symptom:
The seemingly blank properties are a display problem and is unrelated to targeting a remote registry[1]:
The output formatting that is applied to $reg.opensubkey($key) is based on PowerShell formatting instructions for type Microsoft.Win32.RegistryKey, yet these instructions rely on such instances to be augmented with PowerShell provider properties, which are only present if you obtained the Microsoft.Win32.RegistryKey instances via Get-Item / Get-ChildItem.
By contrast, Microsoft.Win32.RegistryKey instances obtained directly via the .NET API lack the provider-added properties that formatting relies upon, causing the formatting definitions to render blank column values.
As stated, this problem exits independently of whether you're targeting the local or a remote registry, so let me demonstrate the problem with a local key:
$base = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::CurrentUser, 'Registry64')
$subkey = $base.OpenSubKey('Console')
$subkey # output
The above, even though opening HKEY_CURRENT_USER]\Console succeeded, yields a seemingly empty object:
Name Property
---- --------
A simple workaround is to force explicity display of the true properties with Format-List *, for instance:
PS> $subkey | Format-List *
SubKeyCount : 2
View : Registry64
Handle : Microsoft.Win32.SafeHandles.SafeRegistryHandle
ValueCount : 46
Name : HKEY_CURRENT_USER\Console
Note that the above won't provide a display of the target key's values and data, the way PowerShell provides by default, as a courtesy, via the calculated Property column; you'd have to do more work to display that too.
[1]
As an aside: There is currently (PowerShell Core 7.0.0-preview.3) a separate, but related problem when targeting a remote registry, but only if you do use Get-Item / Get-ChildItem: see this post
