I have been testing a Powershell script to monitor the last install datetime of downloaded patches from WSUS on all my machines in the domain.
I found the path from http://technet.microsoft.com/en-us/magazine/gg153542.aspx
The paths which I use are:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Detect\
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Download\
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results\Install\
In all the paths above, there is a variable called LastSuccessTime which I use.
When I ran my script against all the machines, I cannot get anything from:
Windows 2008 R2 64-bit
Windows 2003 Enterprise 64-bit
Windows XP 64-bit
Windows Vista 64-bit
However, I was also get the registy info from Windows 7 64-bit or Windows 2003 32-bit.
The really weird things are:
1) I was able to use regedit to manually remote access those 64-bit machines and confirm that the path was valid and there is a LastSuccessTime field there.
So, I can confirm that the same path applies to all OSes.
2) On those 64-bit machines, I was able to fetch other registry entries without any problem.
3) I reran the script and this time shortening the path to see where the access was aborted.
It is in here
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
where the access was denied.
Could there be a restriction on reading the …\WindowsUpdate registry folder while WSUS is active for 64-bit machines?
Best Answer
As it turns out, it has to do with the following:
1) The Powershell ISE was running on 32-bit machine and it was trying to remotely scan a 64-bit Windows OS.
2) WSUS running on a 64-bit Windows OS is a 64-bit app.
3) 32-bit Powershell ISE and 32-regedit cannot remotely "see" the following WSUS entries: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\Results
You can only "see" as far as:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
The WindowsUpdate subkey is invisible to 32-bit app.
To solve the problem, always running Powershell on a 64-bit Windows OS and you can remotely "see" both 32-bit and 64-bit Windows OS.