Fixing the way Vista Auto-detects Installers
From Ben's Writing
The following is a simple way to get applications that MS Vista has auto-detected as installers, like
patch.exe, to work without user intervention (i.e. not making the user click ok for every security dialog).
The tool we use,
mt.exe, is freely available with the Platform SDKs, so for the purposes of this article, we assume they are installed.
Here is how to fix
patch.exe (available here) using a manifest as an example.
- Create a
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="184.108.40.206" processorArchitecture="X86" name="patch.exe" type="win32"/> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
NOTE: We use old versions of the schemas because they are known to work better with unloved XP machines (i.e. not fully updated).
- Embed the manifest in the executable:
mt.exe /manifest patch.exe.manifest /outputresource:patch.exe;#2
- Voila! You are done.
The above should work on other executables that have the misfortune of having the words: "setup", "install", "update", "patch", etc. in their name; or keywords in the "following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name"; etc.
The reason we need to embed the manifest is because of the heuristic used by Windows to detect installers. We short-circuit the heuristic by adding a requestedExecutionLevel to an embedded manifest vs. a side-by-side manifest. See Installer Detection Technology in Understanding and Configuring User Account Control in Windows Vista for more details. The short of it is that side-by-side manifests are checked well after the above keyword checks are done (leading to the false positive).
There are two caveats to this solution: The first is that the application may, in fact, need administrative privileges: in which case, the above will not help—it will not give you access to resources that you do not already posses. The second problem has to do with the executables resources: by convention, manifests must be the second resource, so if there is already a resource under that id, the above will not work either. Fortunately, most programs which this fix applies to do not have resources.
Turning Installer Detection Off
It turns out this is also a policy that can be changed using the Group Policy Object Editor:
- Drill down to: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options;
- User Account Control: Detect application installations and prompt for elevation - Disable;
- A reboot may be required.