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:
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 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.
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.
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.
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.
Declining a patch results in the following:
Follow the steps mentioned below to decline know the steps involved in declining patches, applications, or a family of patches:
You have successfully declined patches for a group of systems. You can now see that Patches that are declined will not be counted when calculating system health or be calculated as missing patches.
Manage and secure client endpoints effortlessly. Discover the benefits of choosing us.
Know more