Decline sensitive patches for your enterprise needs

Patch Manager Plus provides admins the feasibility to perform selective deployment of sensitive patches in a way that it meets the enterprise's patch compliance needs. In simple terms, admins will find this useful when:

  • Declining patches to specific group of computers.
  • Decline updates to certain applications. For eg, legacy applications.
  • Declining the deployment of patches found 'problematic' during pre-testing process.
  • Delaying the deployment of less critical patches by declining them initially.

Exclude problematic patches by declining them

Every administrator fears applying updates or patches that break something. After rolling out patches to test groups, if a patch is found to result in an application or operating system failure, these patches can be declined to all systems until the respective application vendor can supply a corresponding fix. There are also scenarios where some applications work only with a specific java version, updating Java might cause critical applications to break, which might necessitate a complete application reinstall. Thus decline option helps in avoiding the deployment of patches that might caught unprecedented issues in client systems.

Decline patches to legacy applications

Decline patches to legacy applications i.e. these are applications for use by an earlier operating system or hardware platform and they no longer require any security updates/version updates. For example, mainframe applications were legacy apps when the world embraced client/server networks. Windows 7 applications running in Windows 8 are called legacy apps.
Sometimes patches that are deployed to install the latest version of an application might seem unwanted to enterprise networks. For example, consider an IT team of an organization that feels that the latest version of Java if deployed to their systems might break down certain applications due to java incompatibility issues. In order to meet the enterprise requirements, it is recommended to stop an application from getting updated by declining them to the required custom groups.

Delay the deployment of less critical patches by declining them initially

Every environment is different. Some environments only install critical and security updates, some install all updates. In such cases, when we automate patch management, all missing patches are deployed to target computers, irrespective of their level of vulnerability. This results in deploying patches without prioritizing which vulnerable patches need to go first and which patches of less vulnerability can be delayed for deployment. In such cases, admins have the ability to prioritize the deployment of highly critical patches by delaying the deployment of less critical patches which can be declined temporarily.

Decline patches to critical systems such as Server OS(Sql, Exchange server)

Patching server systems is fundamentally different from patching workstations in terms of the scope of patches involved. One of the tougher jobs that server administrators have to deal with is figuring out the priority of patches for servers. They not only deal with the server, but also with the applications running on it  and a host of other things. If you have a mess of patches to be deployed to server systems, this might cause havoc. Business-critical computers and servers may have specific times at which changes and computer restarts are permitted. Hence, it is always recommended to prioritize what patch goes in first and what patches need to be declined so that critical systems are not slowed down due to abrupt disruptions or reboots.

Ability to roll-back declined patches for deployment

The declined patches can be moved back from the decline list and later can be added for deployment. Hence, the declined patches are not removed once and for all but can be revoked for deployment.