Skip to Content

How to Retrieve Registry Value That Could Be in Two Separate Locations Using PowerShell

  • The article explains how to use PowerShell to retrieve a registry value that could be stored in two different locations due to Windows registry redirection feature.
  • The article provides two solutions: one using the OpenRemoteBaseKey method of the [Microsoft.Win32.RegistryKey] class, and another using the Get-ItemProperty cmdlet with the -ErrorAction parameter.
  • The article also gives some tips on how to avoid this problem in the future by using consistent versions of the applications or using the RegistryView enumeration of the [Microsoft.Win32.RegistryKey] class.

If you are a system administrator or a developer who works with Windows registry, you may encounter a situation where you need to retrieve a registry value that could be stored in two different locations. For example, you may want to get the TeamViewer ID of a remote computer, but the ID could be stored in either HKLM:\SOFTWARE\WOW6432Node\TeamViewer or HKLM:\SOFTWARE\TeamViewer, depending on the version of TeamViewer installed.

How to Retrieve Registry Value That Could Be in Two Separate Locations Using PowerShell

In this article, we will show you how to use PowerShell to check both locations and get the registry value you need. We will also explain why this problem occurs and how to avoid it in the future.

Why Does This Problem Occur?

The reason why some registry values could be stored in different locations is because of the Windows registry redirection feature. This feature allows 32-bit applications to run on 64-bit Windows systems by redirecting their registry access to a separate location under HKLM:\SOFTWARE\WOW6432Node.

This means that if you have a 32-bit version of TeamViewer installed on a 64-bit Windows system, its registry values will be stored under HKLM:\SOFTWARE\WOW6432Node\TeamViewer. However, if you have a 64-bit version of TeamViewer installed, its registry values will be stored under HKLM:\SOFTWARE\TeamViewer.

This can cause confusion and inconsistency when you try to access the registry values programmatically. For example, if you use the Get-ItemProperty cmdlet to get the ClientID value from the HKLM:\SOFTWARE\TeamViewer path, you may get an error if the value is actually stored under HKLM:\SOFTWARE\WOW6432Node\TeamViewer.

How to Solve This Problem Using PowerShell?

One way to solve this problem is to use the OpenRemoteBaseKey method of the [Microsoft.Win32.RegistryKey] class. This method allows you to open a remote registry key and specify whether you want to access the 64-bit or 32-bit view of the registry.

For example, if you want to get the TeamViewer ID of a remote computer named RemotePC, you can use the following PowerShell code:

# Open the remote registry key for 64-bit view
$reg64 = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', 'RemotePC', [Microsoft.Win32.RegistryView]::Registry64)

# Try to get the ClientID value from the 64-bit path
$prop64 = $reg64.OpenSubKey('SOFTWARE\TeamViewer').GetValue('ClientID')

# If the value is not found, open the remote registry key for 32-bit view
if (-not $prop64) {
    $reg32 = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', 'RemotePC', [Microsoft.Win32.RegistryView]::Registry32)

    # Try to get the ClientID value from the 32-bit path
    $prop32 = $reg32.OpenSubKey('SOFTWARE\TeamViewer').GetValue('ClientID')
}

# Output the ClientID value
if ($prop64) {
    Write-Host "The TeamViewer ID is $prop64"
}
elseif ($prop32) {
    Write-Host "The TeamViewer ID is $prop32"
}
else {
    Write-Host "The TeamViewer ID is not found"
}

This code will first try to get the ClientID value from the 64-bit path. If it fails, it will try to get it from the 32-bit path. If it still fails, it will output a message that the value is not found.

Alternatively, you can use a simpler approach by using the -ErrorAction parameter of the Get-ItemProperty cmdlet. This parameter allows you to control how PowerShell handles errors when executing a cmdlet. By setting it to SilentlyContinue, you can suppress any errors and continue with the next command.

For example, you can use the following PowerShell code to achieve the same result as above:

# Try to get the ClientID value from both paths
$prop = Get-ItemProperty -Path 'HKLM:\SOFTWARE\TeamViewer' -Name 'ClientID' -ErrorAction SilentlyContinue
if (-not $prop) {
    $prop = Get-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\TeamViewer' -Name 'ClientID' -ErrorAction SilentlyContinue
}

# Output the ClientID value
if ($prop) {
    Write-Host "The TeamViewer ID is $($prop.ClientID)"
}
else {
    Write-Host "The TeamViewer ID is not found"
}

This code will first try to get the ClientID value from the 64-bit path. If it fails, it will try to get it from the 32-bit path. If it still fails, it will output a message that the value is not found.

How to Avoid This Problem in the Future?

The best way to avoid this problem in the future is to use consistent versions of the applications that store registry values. For example, if you use TeamViewer, you should always install the same version (32-bit or 64-bit) on all your computers. This way, you can always access the registry values from the same path.

Another way to avoid this problem is to use the RegistryView enumeration of the [Microsoft.Win32.RegistryKey] class. This enumeration allows you to specify which view of the registry you want to access when opening a registry key. For example, you can use the following PowerShell code to open the HKLM:\SOFTWARE\TeamViewer key in both 64-bit and 32-bit views:

# Open the registry key in 64-bit view
$reg64 = [Microsoft.Win32.RegistryKey]::OpenBaseKey('LocalMachine', [Microsoft.Win32.RegistryView]::Registry64)
$key64 = $reg64.OpenSubKey('SOFTWARE\TeamViewer')

# Open the registry key in 32-bit view
$reg32 = [Microsoft.Win32.RegistryKey]::OpenBaseKey('LocalMachine', [Microsoft.Win32.RegistryView]::Registry32)
$key32 = $reg32.OpenSubKey('SOFTWARE\TeamViewer')

This way, you can access both views of the registry without relying on the redirection feature.

Conclusion

In this article, we have shown you how to retrieve a registry value that could be stored in two different locations using PowerShell. We have also explained why this problem occurs and how to avoid it in the future.

We hope you have found this article helpful and learned something new. If you have any questions or feedback, please feel free to leave a comment below.

Frequently Asked Questions (FAQ)

Here are some common questions and answers related to this topic.

Question: What is Windows registry redirection?

Answer: Windows registry redirection is a feature that allows 32-bit applications to run on 64-bit Windows systems by redirecting their registry access to a separate location under HKLM:\SOFTWARE\WOW6432Node.

Question: How can I check if an application is 32-bit or 64-bit?

Answer: One way to check if an application is 32-bit or 64-bit is to look at its file properties. Right-click on the application file and select Properties. Then go to the Details tab and look for the File version or Product version field. If it contains x86 or x32, it means it is a 32-bit application. If it contains x64 or x86_64, it means it is a 64-bit application.

Question: How can I get a list of all registry values under a given path?

Answer: One way to get a list of all registry values under a given path is to use the Get-ItemProperty cmdlet with the -Name * parameter. For example, you can use the following PowerShell code to get a list of all registry values under HKLM:\SOFTWARE\TeamViewer:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\TeamViewer' -Name *

This will output all the names and values of the registry values under that path.

Question: How can I modify or delete a registry value using PowerShell?

Answer: To modify or delete a registry value using PowerShell, you can use the Set-ItemProperty or Remove-ItemProperty cmdlets respectively. For example, you can use the following PowerShell code to change the ClientID value under HKLM:\SOFTWARE\TeamViewer to 123456:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\TeamViewer' -Name 'ClientID' -Value 123456

Or you can use the following PowerShell code to delete the ClientID value under HKLM:\SOFTWARE\TeamViewer:

Remove-ItemProperty -Path 'HKLM:\SOFTWARE\TeamViewer' -Name 'ClientID'

Disclaimer: The information provided in this article is for educational purposes only and does not constitute professional advice. The author and publisher are not responsible for any damages or losses that may result from using or relying on this information. Always consult a qualified expert before making any changes to your system or software.

Alex Lim is a certified IT Technical Support Architect with over 15 years of experience in designing, implementing, and troubleshooting complex IT systems and networks. He has worked for leading IT companies, such as Microsoft, IBM, and Cisco, providing technical support and solutions to clients across various industries and sectors. Alex has a bachelor’s degree in computer science from the National University of Singapore and a master’s degree in information security from the Massachusetts Institute of Technology. He is also the author of several best-selling books on IT technical support, such as The IT Technical Support Handbook and Troubleshooting IT Systems and Networks. Alex lives in Bandar, Johore, Malaysia with his wife and two chilrdren. You can reach him at [email protected] or follow him on Website | Twitter | Facebook

    Ads Blocker Image Powered by Code Help Pro

    Your Support Matters...

    We run an independent site that is committed to delivering valuable content, but it comes with its challenges. Many of our readers use ad blockers, causing our advertising revenue to decline. Unlike some websites, we have not implemented paywalls to restrict access. Your support can make a significant difference. If you find this website useful and choose to support us, it would greatly secure our future. We appreciate your help. If you are currently using an ad blocker, please consider disabling it for our site. Thank you for your understanding and support.