1 of 1 people found this helpful
Maybe this helps:
you can use a "File Exists with Registry Value Rule" rule in combination with the Reg-Path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion" and the Reg-Key "ProgramFilesDir". In order to get "Program Files" on 32bit and "Program Files (x86)" on 64bit OS you have to check "Use 32-bit registry". On the 32bit OS the value is looked up in the above location, on 64bit "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion" is used.
1 of 1 people found this helpful
The ProgramFiles(x86) common path identifier is not defined in the Microsoft SDP schema.
Only ProgramFiles is defined, so this is the one you must use, and then parent-path to get to ..\Program Files (x86).
Set commonPath = PROGRAM_FILES
Set path = ..\Program Files (x86)\yourApplicationFilePath
The reason you want to use commonPath in this way is because hardcoding the path at the root of C: then assumes that %ProgramFiles% is always on drive C:. It might not be, and your package would fail detection. By using the commonPath value in this way, your package is portable for when %ProgramFiles% exists on a different volumeID. (e.g. drive D:)
Nice idea, but with a caveat: on older localized OS the path has not to be "Program Files". On german Windows XP it's name "C:\Programme" for example.
For language-specific rules and hard-coded paths, there should be appropriate conditional blocks defined with a Windows Language = <value> rule (just as there might be for a Processor Architecture rule when the registry keys differ on x86 and x64).
The presumption in all of the above advice is that the package has been coded as English Only.
Of course, if one is using the PROGRAM_FILES common path value, then it probably resolves to 'C:\Programme' on German-language systems. -)
If one is trying to get to the equivalent of "Program Files (x86)" on a non-English system, then those adjustments should be made in the "Set Path" value also.
"The ProgramFiles(x86) common path identifier is not defined in the Microsoft SDP schema.
Only ProgramFiles is defined, so this is the one you must use, and then parent-path to get to ..\Program Files (x86)."
Really? because according to the msdn docs for the BaseApplicabilityRules Schema and the BaseTypes Schema the value of CSIDL="42" or ANY CSIDL value for that matter is passed directly on to Win32 SHGetFolderPath and the result is the correct folder. So there is no reason that that PROGRAM_FILESx86 common path should not be included in Patch manager as an option.
+1 for this feature.
There are FOUR FIVE different variables at work here, Jonathan.
The first is whether there even exists a documented CSIDL value for Program Files (x86).
CSIDL (Windows) does document this value, but does not specify to what it exactly refers, but I would say it's safe to assume that it refers to the %SystemDrive%\Program Files (x86) folder.
The second is whether SHGetFolderPath recognizes the value. According to the documentation it does not. See SHGetFolderPath function (Windows)
The second third is whether the Windows Update Agent recognizes the value and can extract it from the update metadata XML. Unfortunately, this has always been the weak link in the documentation process, and what the WUA does or does not recognize, or does or does not respond to, is a great unknown outside of the WUA team. Way back in the dark ages, all of the components were under the same Group Program Manager: WSUS, WUA, WU/MU ... but a while back the WUA got sent over to the Consumer OS group, and ever since then WSUS and the enterprise has been treated like the disowned stepchild.
The third fourth variable at work is whether the Software Distribution Package (SDP) schema supports the value. While the CSIDL may be passed directly to the shell, there still has to be a definition for it in the XML schema declaration so that SCUP, and other third party package tool developers, know that it's an authorizied value for use.
And finally, once all of the above three four conditions are met, it becomes practical for the Package Wizard of Patch Manager to define that value in a dropdown.
At this time, the only proven workaround for addresssing 32-bit installation folders on a 64-bit system is to define the common path as PROGRAM_FILES and then back-pathing to get to %SystemDrive%\Program Files (x86).
Thanks for taking the time to respond.
It would be logical to assume so. Correct
You are correct here. SHGetFolderPath may not recognize CSIDL_PROGRAM_FILESX86 on OS lower than VISTA
This appears to be the showstopper at least until support for XP and lower is dropped.
there are no restrictions on the value of CSIDL in the schema other than that the value must be an integer.
<documentation>A numeric CSIDL value, as would be passed as the nFolder parameter to Win32 SHGetFolderPath.</documentation>
<restriction base="int" />
<element name="FileExists" substitutionGroup="sdp:ApplicabilityRuleElement">
<documentation>Checks for the existence of the specified file. If Csidl is specified, the MSUS Client will call Win32 SHGetFolderPath to retrieve the CSIDL and prepend it to Path to form the actual path to the file. Before checking the file, the Client will canonicalize the path to remove duplicate backslashes (among other things). If other optional metadata are specified, such as Version or Size, they must all match for this applicability rule to return true.</documentation>
<attribute name="Csidl" type="bt:Csidl" use="optional" />
Awesome, thanks for the ideas. Much appreciated!