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

Issue building new package (No PROGRAM_FILESx86 common path?)

Hi All,

I am creating a Custom Update Package for Citrix Receiver 3.4.

I have it working fine with 32 bit systems, but i am having an issue detecting applicability on x64 systems. Unfortunately, I am unable to reference the registry as i had hoped becuase this particular application doesn't have the path in the registry as you would assume.

That said, I need to determine if the file at the following location exists and is less than version 3.4.0.29577

PATH: C:\Program Files (x86)\Citrix\Receiver\Receiver.exe

When i do this for the x32 version, i can simply use the Common Path or "PROGRAM_FILES" and use the Path value of "Citrix\Receiver\Receiver.exe" to determine its existence.

However, when i try to create the package for a x64 system, where the path of the executable is "C:\Program Files (x86)\Citrix\Receiver\Receiver.exe",

I get he following error in WindowsUpdate.log (verbose enabled) when i select Common Path of "NONE" and enter the full Path of "C:\Program Files (x86)\Citrix\Receiver\Receiver.exe" into the Path field.

2013-01-25    08:16:51:905    1144    17b0    EEHndlr      EE: FileVersion expression: path=C:\Program Files (x86)\Citrix\Receiver\Receiver.exe, comparison=32013-01-25    08:16:51:905    1144    17b0    EEHndlr      EE: FileVersion evaluated to Error!, return hr=0x80070002

Where i believe this can be addressed is to have the x86 "Program Files" path available in "Common Paths". Doing some research with packages i had created using SCUP, which has this feature and I used it heavily, prior to having procured Patch Manager, i was able to determine that this value is the equivalent of 'CSIDL="42"'

Note that the PROGRAM_FILES value is "38" as i have confirmed in the XML view.

2 questions:

Can the Common Path of "PROGRAM_FILESx86" be added to the 'Common Paths" list somehow?

Is there a config file i can add the entry into?

Is there a means to altering the XML that can only be viewed on the "Applicability Rules" pane of the wizard?

Thanks

Find more posts tagged with

Accepted answers

All comments

callidus

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.

David_Di_Blasio

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 )

David_Di_Blasio

Here's the original thread I found that information on.

callidus

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.

gfraetis

Awesome, thanks for the ideas. Much appreciated!

LGarvin

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.

homes32

"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.

LGarvin

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).

homes32

Thanks for taking the time to respond.

#1:

It would be logical to assume so. Correct

#2:

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.

#3:

see #4

#4:

there are no restrictions on the value of CSIDL in the schema other than that the value must be an integer.

BaseTypes.xsd

----------------------------------------

<simpleType name="Csidl">
     <annotation>
     <documentation>A numeric CSIDL value, as would be passed as the nFolder parameter to Win32 SHGetFolderPath.</documentation>
     </annotation>
     <restriction base="int" />
</simpleType>

BaseApplicabilityRules.xsd

---------------------------------------------

<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>

</annotation>

</extension>

</complexContent>

</complexType>

</element>