When a New Update is Available section in Patch My PC Publisher
Applies to: Patch My PC Publisher V3.x
The WHEN A NEW UPDATE IS AVAILABLE section on the Base Install Options tab of Patch My PC (PMPC) Publisher controls how Publisher handles new versions of applications that were previously created by Publisher. The behavior you choose determines whether existing applications are updated in place, new applications are created, and how older versions are retained or removed.

In this section, you can choose either:
Update existing application (Default)
When you enable the Update existing application (Default) option, Publisher updates an existing ConfigMgr application in place rather than creating a brand new application.
This is the default option and is commonly used because the application ID does not change in ConfigMgr when we update it to the new version. By keeping the same application ID:
Task sequences that reference the application continue to work without modification.
Existing required and available deployments remain intact, ensuring that the latest version of the application is automatically deployed or made available in Software Center to the same device collections that targeted the previous version.
This is especially valuable for operating system deployment scenarios, where administrators want task sequences to always install the most recent version without updating references every time a new release is published.
Before performing an in-place update, Publisher validates that the application is in a healthy state. This includes confirming that:
Publisher originally created and manages the application.
The corresponding application content exists on disk in the content source folder.
These checks are required to safely support additional behaviors such as application retention and cleanup.
When an in-place update occurs, Publisher:
Preserves the existing application object and application ID.
Updates application metadata such as:
Software version
Application Name
Description and related metadata.
Removes the existing Deployment Type.
Creates a new Deployment Type and corresponding content source folder.
Tip
Removing and recreating the deployment type results in two new revisions on the application object for each update. Over time, this causes the total number of application revisions to increase.
Important
In some environments using a Cloud Management Gateway (CMG), a small number of customers have historically observed issues when updating applications in place. In these cases, clients may encounter content or policy hash mismatches, where updated application policy does not consistently replicate through the CMG.
A common symptom of this behavior is an error similar to the following in CIDownloader.log on affected clients:
Evaluation Failed, 0x87D00289 (-2016410999), Unknown Error
These issues most commonly occur with applications that have multiple revisions, which can happen over time when an application is repeatedly updated in place.
If you encounter these symptoms in a CMG-enabled environment, the recommended workaround is to use Create a new application without modifying any previous applications instead of updating applications in place.
Delay the in-place application upgrade by x days
When you enable the Delay the in-place application upgrade by x days option, application updates are delayed for the specified number of days after the new version is synchronized from the catalog.
The delay is calculated from the date Publisher first detects the new version.
This allows time for validation or testing before updating production applications.
Example: If a new version is synchronized on February 3 and the delay is set to 3 days, the application will not be updated until a Publisher sync on or after February 6.
Create a new application
When you select the Create a new application option, Publisher creates a new ConfigMgr application for each new version instead of updating an existing application in place. Unlike the in-place update option, it creates a new application ID for every version.

This option is commonly used when administrators want to preserve each application version independently or avoid modifying existing application objects. It is also best suited for environments where strict version control is required, and task sequences are updated intentionally.
Because a new application is created each time:
Task sequences that reference older application versions will continue to install those versions until they are manually updated to reference the new application.
Existing required and available deployments remain associated only with the original application and do not automatically apply to the newly created application.
Common Settings
The following settings can be enabled and configured regardless of whether Update existing application or Create a new application are selected:
Retain up to x previously created applications
When you enable and configure the Retain up to x previously created applications option, it controls how many older application versions ConfigMgr retains when Publisher publishes new versions. It applies regardless of whether you choose to update applications in place or create a new application for each version.
Valid values range from 0 (the default) to 10.
When this value is set to 0, only the latest version of an application is kept in ConfigMgr. Any older versions are removed.
When this value is set to a value greater than 0, Publisher retains that number of older application versions alongside the latest version.
For example, setting this value to 1 ensures that the environment always contains the latest application version and one previous version. This allows for quick rollback to a last known good version if needed, while preventing excessive growth in the number of applications.
Tip
You can adjust application retention at the vendor and product levels in the Product Tree, giving you more granular control and allowing you to override the configured global setting.
This option is especially useful for third-party applications with a rapid release cadence, such as web browsers. Retaining additional versions makes it easier to roll back if needed using supersedence.
See Supersedence for more information about using supersedence in ConfigMgr.
Important
Publisher will not delete an application referenced by a task sequence, even if it exceeds the retention limit and the option to delete applications with deployments is enabled.
To delete applications referenced by task sequences, remove them from the task sequence first.
Behavior with update in place
When you enable the Update existing application (Default) option, application retention works by first preserving the current version before applying the update.
Before updating the application to the new version, Publisher duplicates the existing application and moves its content into a Retained Apps folder. Publisher then updates the application in place by removing the existing deployment type and creating a new deployment type for the latest version. This ensures the previous version is retained according to the configured retention count while the application ID remains unchanged.
If the number of applications exceeds the configured retention value, Publisher removes the oldest application versions, starting with those that fall outside the retention window.
Behavior with create new application
When you enable the Create a new application option, application retention is applied across the chain of independently created application objects.
Each new version is created as a separate application. If the number of applications exceeds the configured retention value, Publisher removes the oldest application versions, starting with those that fall outside the retention window.
Remove administrative categories from retained applications
By default, all administrative categories assigned to a ConfigMgr application are preserved when you retain older application versions. This is useful in scenarios such as operating system deployment frontends, where administrative categories are used to populate application selection lists. The option to Remove administrative categories from retained applications ensures that only the current version appears in those lists, preventing outdated versions from being presented.
Important
The Remove administrative categories from retained applications checkbox is only available when the Retain up to X previously created applications setting is configured.
When checked, this option removes administrative categories from retained (older) application versions. Only the latest published application keeps the assigned administrative categories.
Delete applications even if they have a deployment
When you enable the Delete applications even if they have a deployment option, Publisher can delete retained application versions even if they have existing deployments. When disabled, applications with active deployments are preserved and are not removed during retention cleanup.
Important
The Delete applications even if they have a deployment checkbox is only available when the Retain up to X previously created applications setting is configured.
This option provides flexibility for environments where older application deployments are no longer required but may still exist, allowing retention cleanup to proceed without the need for manual intervention to remove a deployment(s).
Last updated
Was this helpful?