This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Installing CutePDF and GhostScript with Patch Manager

It took me a while to get this package to work so I hope this helps others.

First you will need to download the CuteWriter.exe and converter.exe from CutePDF. The former is simply downloaded from their downloads section but the later can be found at http://cutepdf.com/download/converter.exe.

Converter.exe is an archive that you will need to open and extract the contents to its own directory. I use 7zip to accomplish this.

pastedImage_0.png

Once you get to the Select Package section of the Package Wizard change the type to Command Line Installation (.exe). Click the "I already have the content for the package locally on my network" radial button and click the folder icon on the right. Browse to CuteWriter.exe and select it. Select Binary Language as English. Enter /very silent for the Command Line parameter. Everything else is fine as the default.

Next click the "Use the Package Boot Helper program when performing installation of the software" check box. Click the shield icon on the right.

pastedImage_2.png

Remove all the enteries on this screen. Click the add action under before applying package. Make sure this action is enabled and put setup.exe (this refers to the GhostScrip installtion file) into the program name. This package will display a command prompt box when executed, but in my testing it's very quick and hardly noticable.

Under the Apply package section heading you'll see CuteWriter.exe and the settings will reflect what you have entered on the previous screen. (Mine shows packageboot.exe after coming back to it for this tutorial, not sure why but it works).

Once back to the previous screen click the Paper and Pencil button on the right next to the additional files label box.

At this point you'll see CuteWriter.exe, packageboot.xml, and packageboot.exe. You'll notice that CuteWriter.exe has a blue square with a white i in the corner of it. I removed this file and added it back in, but I'm not sure why it worked after I did that and only after I did that.

Next click Add Directory Content button at the top and browse to your directory that holds the content of converter.exe. Select the directory and click OK. Click Next.

Finish your package rules and you should be able to publish and install on any clients. I used simple rules for the prerequisite rules making sure the clients are XP sp3 or greater and 64-bit since that's the version I wanted to install. My Applicability Rules check for the absence of a registry key at HKEY_LOCAL_MACHINE\Wow6432Node\GPL using 32-bit register since it's in wow6432Node. The Installed rule checks for the presence of the registry key mentioned previously.

Hope this helps!


  • Hello:

    RE: Applicability Rule / Detection of package installation

    I appreciate that someone has posted in regards to creating an .exe package.

    I have been trying to find a solution to why the package continues prompting to install in Windows Update even after installation.

    I used the example from "Product Blog: Deploying Custom Packages with Patch Mananger" which used an MSI file; so I had to experiment with the rules. The following are scenarios I have faced:

    1) The first attempt was a simple package that successfully ran and placed the .exe file in C:\Users\%Userprofle%\Program Files; so, I just went with the basic rules for Windows version for Prerequisite, Application, and Installation rules. (Up until this point I had no experience with software packages other than WSUS).

    At first Patch Manager would just push the package but it would not display a notification in 'Windows Updates' window.

    2) I changed the Installation Rule to to 'File Exists', COMMON PATH: PROGRAM_FILES, Path: file://C:\Users\%userprofile%\program files.

    This caused the update to show in Windows Update as "1 important Update is available" and continued to Install it; but, this message keeps appearing after install.

    Afte setting 'File Exists' rule in Applicability Rules it would actually keep the update from pushing out at all. The package is alright with just the 'Windows version rule'.

    3) I followed the example as mentioned above "Installing CutePDF...", created the registry rules but the same thing happens: The update installs and then 'Windows Update' continues to prompt to install the update. I had to manually create a registry key for the software I am installing.

    If I delete the key then Windows Update states that 'Windows is up to date". If I create it again, then of course it states that it is available for install.

    The registry key create a 'Default' string but I have no idea what the value should be. I have tried 0, 1, 2, and 3, but not change to the installation behavior.

    Any suggestion is appreciated. Thank you.

  • When trying the file exists method did you give it more than just that the file existed? Maybe try giving it the size of the file as well as I'm assuming the update you are pushing will have a larger file size due to the patching that was done to it. Then in your installed rule you'll set your check as file exists with file size greater than the old size of the file.

    I'm thinking that the install rule is needing tweaking if you're getting the package to push but windows update is constantly nagging you that it needs to install it.

  • I have been trying to find a solution to why the package continues prompting to install in Windows Update even after installation.


    The most likely reason that any package would continue to prompt for installation after a successful installation is that the Installed Rules of that package are not properly identifying the installed package, as such, the package is not reported as Installed. Furthemore, the Applicability Rules should contain rules defined such that an installed package would return NotApplicable in the face of a failed installation ruleset, rather than NotInstalled.


    When used with file-based testing, these rules are quite simple:

    • The Installed Ruleset uses a FILE EXISTS or FILE VERSION rule to test for the File Version EQUAL TO the version number of one or more files of the installed package.
    • The Applicability Ruleset uses a FILE VERSION rule to test for the File Version LESS THAN the version number of the to-be-installed package.
    • In addition, if the package is intended as an Upgrade-Only package, the Prerequisite Ruleset should have a FILE EXISTS or REG KEY EXISTS rule to validate that the product is installed.

    There are thousands of packages in the Solarwinds catalog that use EXE installers. The exercise to create a package should be nothing more than cloning/editing one of these already-proven packages.

    I will also mention that you cannot test for rules based on environment variables or pathnames involving USERS. The Windows Update Agent runs in the context of the SYSTEM user and does not have access to %userprofile% resources. More importantly, those environment variables are not defined in the context of the WUAgent. As such, any rules using those values WILL FAIL in every instance they are evaluated.

  • Hello: I have added a number to the file size field and have tweaked the rules for the test_package. Out of three test VMs only two continue with the installation and one fails; this is progress, and I hope to understand the syntax of Applicability and Installation rules better.

    Anyway, I set the Applicability Rule to 'Registry Key Exists' and entered the software information to match the manual key I created in the VMs; then, I set the Installationed Rule to 'File Exists with Registry' with registry key and file size and 'File Exists' with just the file size.

    Next, I will try the recommendations from Mr. Garvin.

    Thank you.

  • Hello, Mr. Garvin:

    I have attempted to apply the 'simple' approach' as you mentioned. It really is frustrating to me only because of the time spent entering combinations of rules and no 'prize'.

    I should mention that this 'test package' is made up of a simple EXE: The file (patchtest.exe) runs and simply creates a text file (patchtestfile.txt) located in C:\Program Files\; so, there is no actual application being updated (if that matters). Patchtest.exe does not remain in any folder anywhere on the target system; therefore, I ask, should there be a location folder for the EXE on the target system which can be reference by a registry key? I have entered file version and size for both the EXE and text files in the rules (separate packages of course), but still no 'prize'.

    I also looked at the most recent Mozilla Firefox.exe package as an example. It seems very straight forward and has just one Applicability Rule and Installed Rule.

    I did notice the registry key path made reference to the installed location of the EXE, which is one thing not created by the simple patchtest.exe.

    Your advice is greatly appreciated.

  • So, it seems to me that part of the challenge here is that you've created an unrealistic test scenario, and specifically a test scenario in which it would be impossible to reliably test for the Installed vs Not Installed state.

    Take note of how typical applications operate. There's at least one EXE file permanently resident on the system, and quite often some form of registry identifiers as well.

    I would also ask.... have you viewed the introductory webcasts?

    [VIDEO] Package Creation Fundamentals

    [VIDEO] Package Creation Using Patch Manager

  • Mr. Garvin: I believe I am on the right path now. Thanks to your confirmation of the requirement of an EXE file "resident on the system". I manually copied the EXE file to a folder under C:\Program Files\ and matched a registry key to it. Windows Update no longer request to re-install the patch, although I found this function to be independent on whether the text file was created or not. This validates the mechanism for the Applicability and Installed Rules.

    I have communicated this to the software developer and he will be writing up a new 'patchtest.exe' which will create a registry key and folder containing the EXE file and will adjust accordingly. These are preliminary steps in understanding Patch Manager and using it to push custom 3rd Party Updates to our production environment.

    Thank you for your assistance.