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.

Package Boot customizations overwritten by Package Content Editor

If I open the Package Content Editor for a package that has a customized packageboot.xml, I get a prompt stating that packageboot.xml differs from the local console client cache and will be overwritten. If I click Yes, the package boot file is overwritten with a default file, wiping out any customizations. I can cancel the dialog, but this prevents me from making any modifications to the package contents. The only way that I can find to change the contents of a package with custom package boot is to first export the XML from the Package Boot Editor, then update the files and finally re-import the XML.

Isn't there a better way?

  • The package that has the customized packageboot.xml -- is that a Duplicate of a package from the Patch Manager catalog, or did you edit a catalog package directly?

    Can you identify a specific update package where this occurred, so that I can test the behavior on my own system?

  • I have reproduced the issue both with original packages directly from the catalog and with duplicates. It happens whether I have customized the package boot file myself or whether it was already customized in the package as received from the catalog. It appears to occur with any package that uses packageboot, but specifically, I have experienced it with Java Runtime Environment 7u11 (x64) (Upgrade) and Adobe Reader 11.0.0.379 (Upgrade).

  • Thanks Andrew.

    The behavior is expected if you customize the original package, because the catalog synchronization event is a full reconciliation; any customization to original packages will be overwritten (restored) during the next catalog sync. This is why making a duplicate package is important.

    I'm told that the behavior with the duplicate package scenario and PackageBoot has been reproduced in the lab, and has been fixed in the new release. The Patch Manager v1.85 Release Candidate (which adds support for Win8, Win2012, SQL2012, and WSUS v6) is available to you in your Customer Portal for download. The Release version of v1.85 will be available shortly. The 'RC' is a fully-supported installation, and you can upgrade from v1.85RC to v1.85Release when it becomes available.

  • You said that the behavior is expected because catalog synchronization overwrites original packages, but my packageboot.xml file is not overwritten during catalog synchronization, it is overwritten immediately after I click OK in the Package Content Editor dialog.

    Please try the following in your environment and let me know if your experience is the same as mine:

    Open the Adobe Reader 11.0.01.36 package in the Package Wizard. Click Next twice to get to the Select Package screen.

    Click the Package Boot Editor button and observe the customizations. Now close the package boot editor.

    Click the Package Content Editor button to open the Package Content Editor.

    Click OK to close the Package Content Editor. A dialog is displayed indicating that packageboot.xml is different from the local client cache and will be overwritten. Click Yes

    Click the Package Boot Editor button again and observe that the customizations are gone.

    Close the package boot editor and cancel the package wizard to leave the package unchanged.

  • This behavior you describe above, within the scope of a duplicated (or user-created package) with regard to the console cache issues has been fixed in v1.85. (By extension it is also fixed with respect to SolarWinds provided packages.)

    It is expected that PackageBoot will be overwritten as a result of synchronization, so modifying an original package is a doomed activity, in any event. Yes, it is true that the behavior also exists with regard to original SolarWinds packages, and it, too, has been fixed in v1.85, but in itself is functionally superseded by the fact that any customizations made to the original package are not going to be retained anyway. I realize that it may be pedantic that I continue to make the distinction between duplicated packages, or user-created packages, and those created by SolarWinds, but I don't want to create the impression that customizations to SolarWinds-originated packages have any expectation of permanence in any instance.

  • Thanks for the information, Lawrence. I have confirmed that this issue is resolved in the 1.85 RC