V doesn't show up in Programs and Features

[tmenke]

Our office is running inventory software that runs WMI queries on our computers in order to track who has what installed for licensing purposes.

Since V is licensed we tried to do a query on how many V installs we had to make sure we were within our license numbers. problem is, our query came back with zero installs.

I investigated this further and noticed that V doesn't show up in Programs and Features to uninstall it. eventually I discovered that it only shows up in Programs and Features if you're logged in as the person who originally installed it (which is usually me).

I don't know if it matters or not, but when I install V, I do usually install it for all users, but it still appears to only show up in Programs and Users under my account and not anyone elses.

is there any way to correct this so that V shows up in Programs and Features regardless of who is logged in? I suspect this would also resolve our query problems. We're running Windows 7 Professional and Enterprise SP1 64bit

Thanks in advance!

[FileViewer]

when I install V, I do usually install it for all users, but it still appears to only show up in Programs and Users under my account and not anyone elses.

Yes, this is done deliberately.I do not think that you would want any user to be able to uninstall the software.

Is there any way to correct this so that V shows up in Programs and Features regardless of who is logged in?

I do not want to do this in the setup program, but if you wish, you can use the Windows Registry Editor to do this.

All you need to do is copy the existing entry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\V64 to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\V64

Code: Select all

I suspect this would also resolve our query problems

I really don't think so, as this entry will be visible for all users, not just those who are using V.

Our office is running inventory software that runs WMI queries on our computers in order to track who has what installed for licensing purposes.

V has its own licensing scheme - it does not use the Windows Software Licensing Service or WMI.

You will not be able to use WMI to get licensing details unless WMI was used by one of your admins when V was first installed.

[tmenke]

Yes, this is done deliberately.I do not think that you would want any user to be able to uninstall the software.

This wouldn't be a problem for us since only IT staff are administrators on our computers, everyone else is a regular user and unable to uninstall anything in the Program Files directory regardless of what is shown in Programs and Features

I made the change in the registry that you described and logged in with a non-admin account and I can confirm it does show up in Programs and Features, and the non-admin is prompted for admin credentials if I attempt to uninstall.

As for the licensing part of my question, I apologize, I think I was unclear. The inventory software I spoke of merely queries the computer for what is installed on it and tallies it up for us, which then we compare that number with how many licenses we purchased. We use it for all of our other licensed software and it works quite well to monitor these sorts of things, but since V doesn't show up in Programs and Features unless you're logged in as the user that installed V, The inventory doesn't see that V has been installed and so usage is not being tracked.

Now that I've made the change in the registry, I had my coworker run an inventory scan of my test computer and V does show up now,

so I need to figure out how to write a script that queries the current_user branch, if it's there, then it copies it to the local_machine branch.

EDIT: crud, as I think about it more, querying current_user won't work since the logged on user won't necessarily be the user who installed V.

[FileViewer]

crud, as I think about it more, querying current_user won't work since the logged on user won't necessarily be the user who installed V.

You can tell if V has been installed by the existence in the Registry of HKEY_CURRENT_USER\Software\Prineas\FileViewer.

However, I am not sure if it is possible for an Administrator to query the Registry for all user accounts.

[tmenke]

Yes, this is done deliberately.I do not think that you would want any user to be able to uninstall the software.

yeah, I don't want users to uninstall software, but Windows already takes care of that and users can't uninstall software, Only administrators can.

You do realize that there are some good reasons why you don't want to hide stuff from Programs and Features right? And not just for our particular issue of inventory management.

By tying it into the installers account, you unnecessarily make that account crucial/special to the uninstall process. Say the person who installed the software leaves the organization and the account gets deleted. Now you can no longer easily remove the software if need be, an administrator needs to manually start deleting files and registry entries by hand instead of having an automated process.

It's pretty standard in every program I've ever seen to list the program in programs and features for all users. Only administrators can uninstall anyway. Who cares if the users can see what's installed if they can't remove anything, so why add an unnecessary layer on top of it?

Don't mean to tell you how to write your software though, I've just never encountered this sort of thing before.

[rmassone]

I have already submitted the same feedback in the past and I know the reasons behind this design choice, nevertheless I prefer the "conventional" approach of Windows clearly detailed by tmenke.

V is a software with a really long history and, I suppose, a quite large number of users. What I've seen since I started using it in the late nineties is that the author always tries to do his best to include new features or adapt the program following user requests. And this behaviour comes from one of those requests, so changing it may adversely affect some users that rely on it.
On the other hand it is also important to consider how much the operating system changed since the 95/NT4 days (when V was first released). Today users have a lower security profile with limited privileges and also administrators are required to confirm some tasks through the UAC prompts. While it is still possible to find older operating systems not supporting UAC or disable most of it on newer OS, none of these is considered a best practice, so I'm considering the usage in two different scenarios: out of the box Windows (running the default settings) and enterprise users. In these scenarios there's no way to remove a software without admin permissions.
Some software, usually installed directly from webpages or supporting side-by-side installations with previous versions, installs in the user profile. In this situation the software doesn't rely on the user admin privilege and thus it cannot write on either the %ProgramFiles% directory or the HKLM hive, so the software is installed in the %LOCALAPPDATA%\Vendor\AppName path and all the settings are saved in the HKCU hive.

Given that, I think there's an inconsistency in the way the current version of V is installed, because it uses a global binaries repository (%ProgramFiles%) along with a private settings repository (HKCU), triggering some issue such as the one mentioned by tmenke:

By tying it into the installers account, you unnecessarily make that account crucial/special to the uninstall process. Say the person who installed the software leaves the organization and the account gets deleted. Now you can no longer easily remove the software if need be, an administrator needs to manually start deleting files and registry entries by hand instead of having an automated process.

Note @tmenke: given the really reduced footprint of V, the easiest way to remove V in the described scenario is to reinstall V (same architecture, possibly same version) from another user account and then to remove it.

You can tell if V has been installed by the existence in the Registry of HKEY_CURRENT_USER\Software\Prineas\FileViewer.

However, I am not sure if it is possible for an Administrator to query the Registry for all user accounts.

The way registry is loaded doesn't permit to access the hive belonging to another user unless the user is currently logged on. Furthermore it requires to know the SID of the user who installed the software and this SID may be local to the machine or belonging to a directory service (e.g. Active Directory). This makes it a really hard task.
Also if I'm not wrong the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\V64 mentioned earlier in the thread refers to a 64-bit setup, while the 32-bit setup uses a different key ("V" instead of "V64") and is probably placed in the HKCU\Software\Wow6432Node branch if the 32-bit setup is executed on a 64-bit computer.

One option is to write a small script that actually fixes the registry as soon as the software is installed, but of course it's up to the user who installs the software to also fix the registry, and it's often left behind for a future time. Not to mention the update/upgrade process which may be triggered by V itself, eventually from a different user account, spreading registry keys all around.

A better option is to rely on the Application Compatibility Toolkit (from Microsoft) and write a small fix (actually a registry key redirect. Look at CopyHKCUSettingsFromOtherUsers and VirtualRegistry) to redirect all the access to the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Vxx key to the HKLM hive. I don't know if this actually solves the 32/64 bit problem described earlier in this post because it depends on a built-in registry redirection feature of Windows.

Links to the Application Compatibility Toolkit

• Application Compatibility (http://technet.microsoft.com/en-us/wind ... ility.aspx)
• Application Compatibility Toolkit (ACT) Technical Reference (http://technet.microsoft.com/en-us/libr ... 25181.aspx)
• Compatibility Fixes for Windows 8, Windows 7, and Windows Vista (http://technet.microsoft.com/en-us/libr ... 83989.aspx)

A note from the CopyHKCUSettingsFromOtherUsers page on the TechNet website (http://technet.microsoft.com/en-us/libr ... 38375.aspx):

Applications should be modified so as not to apply per-user settings while elevated. In addition, you should consider whether to apply settings to the per-user or per-computer registry for any application that administers the computer or requires Administrator privileges.

I think that the best and most conservative solution is to allow the user to choose the preferred setup behaviour, possibly saving this choice in the settings/preferences (HKLM) so that further updates use the same setting.