Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

3rd party package - how to test for per-user install

Is there any way to write an applicability rule that tests whether a per-user application has been installed?

I am trying to create a custom package that applies a patch that happens to be incompatible with a particular application installed on some machines in our environment. I need the package to only apply if this other application is not installed on the machine; but the only indication that this application exists is a registry entry in the user's uninstall key

HKEY_USERS\[SID]\Software\Microsoft\Windows\CurrentVersion\Uninstall\ProgramName

The application creates no files and appears to leave no other traces. Since the user SID will be different for every user on every machine, I need some way to test every SID under HKEY_USERS. Unfortunately, the basic rules only seem to allow explicit registry paths. I guess I could just add a script in packageboot that scans HKU for the key and only does the patch if it's not found, but then the package would continually be detected as applicable on those machines even though it's not.

Find more posts tagged with

Accepted answers

LGarvin

Is there any way to write an applicability rule that tests whether a per-user application has been installed?

It is not possible to test for per-user installations, which is why the Windows Update Agent has never been able to patch per-user installations of products, such as Office, etc.

The WUAgent operates in the context of the SYSTEM user. As such, the registry trees in HKCU representing interactive users are not accessible to the WUAgent during update installation. As a result, there is no way to do the requisite registry checks that would be necessary to detect the presence of such keys/values in the USER hive.

All comments

jbaits

You could have the script create a registry key and dword value after it checks for the installed application (ex. not installed dword=0 installed dword=1). That would allow you to make an applicability rule (reg dword value < 1) based on your own registry value limiting the update to running once per machine.

LGarvin

Is there any way to write an applicability rule that tests whether a per-user application has been installed?

It is not possible to test for per-user installations, which is why the Windows Update Agent has never been able to patch per-user installations of products, such as Office, etc.

andrewm.

Thanks, that's a good suggestion. I might need to consider something like that

andrewm.

Ah, that makes sense. Thanks for the explanation.

It leaves me with a question, though. The Google Chrome update is designed to replace any per-user installations with a per-machine installation. But due to the limitation you described, would the agent even be able to detect that an outdated per-user installation exists?

andrewm.

Never mind, I see that you just discussed this very topic in the thread

LGarvin

Generally speaking, yes; however, Chrome is a rather unique case.

The HKLM\Software\[Wow6432Node\]Microsoft\Windows\CurrentVersion\App Paths key contains a set of subkeys for installed application on the system. In those subkeys are values relating to the installation location of the application. As you scan through those subkeys you'll see, as expected, that installations are generally found in %ProgramFiles%. But, for a per-user installation of Chrome, Google actually buries the executable in the %userprofile%\AppData\Local\Google\Chrome\Application folder. Now, arguably this is an improper use of the %userprofile%\AppData folder tree, but there it is.In a per-machine installation, that registry value would point to the %ProgramFiles% folder.

So, regardless of where the file is installed, or the lack of access to anything that might be in HKCU, we are able to identify the currently installed location of the chrome.exe, and get the version number of it. For a per-machine installation we also check the chrome.dll, which is tracked down via the HKLM\~\CurrentVersion\Uninstall key (in a per-user installation this value is found in the HKCU\~\CurrentVersion\Uninstall key), so since the registry key is missing in a per-user installation (remembering our previous conversation on the impact of missing registry keys in a File Exists with Registry Key rule), the missing key makes the rule return True.

If the per-user instance of chrome.exe is current, which it always should be if it's being used, since Chrome is a self-updating (transparently!) application. will the Patch Manager (Upgrade) package render as Not Applicable. If the installed instance of chrome.exe is not the current version (which is a clue that maybe Chrome isn't actually being used on that system), the WUAgent launches the chrome_installer.exe from the package. It is the chrome_installer.exe that removes the per-user instance and replaces it with a per-machine instance.

If you want to force the conversion of a per-user installation to a per-machine installation, regardless of the state of the current per-user installation, I believe that changing the first rule to just a Registry Key Exists rule and placing it in an ANY block with the other two rules, will then relegate the package to merely checking for the existence of a per-user Chrome installation -or- the existence of an outdated per-machine Chrome installation.