Mastering Patch Management: Partial Automation vs. Manual Control with ManageEngine Endpoint Central


In today’s fast-paced IT environment, patch management is critical to maintaining the security and stability of your server infrastructure. Whether you’re managing Windows or Linux servers, having an efficient and flexible patching strategy ensures that you can protect your systems without causing unnecessary disruptions to your business.

 

ManageEngine Endpoint Central’s Self-Service Portal offers two key approaches to patch management: a partial automation strategy that combines the benefits of automation with manual oversight, and a fully manual approach where IT administrators retain complete control over patching decisions. In this blog, we will walk through both approaches, exploring how each method can help you manage patches effectively.

 

Why Patching Matters

Before diving into the approaches, let’s quickly review why patching is essential:

Security: Patching addresses vulnerabilities that could be exploited by malicious actors, helping prevent breaches and attacks.

Compliance: Many industries require regular patching to comply with regulations like GDPR or HIPAA.

Stability: Patches often include bug fixes and performance improvements that keep your systems running smoothly.

 

With these goals in mind, you can select the right patching approach—whether fully manual or partially automated—that suits your organization’s needs.

 

Approach 1: Partial Automation with ManageEngine Endpoint Central 

Partial automation allows you to strike a balance between automation and manual oversight. You can automate large parts of the patching process while still maintaining control over critical decisions. ManageEngine Endpoint Central’s Self-Service Portal makes this hybrid approach possible by allowing IT administrators to test patches on non-critical systems before rolling them out to production servers.

 

Patching Strategy Using Partial Automation

 

This approach follows a clear workflow where patches are first tested in a controlled environment, and then, based on their performance, are either manually or automatically deployed across critical and non-critical servers.

 

Step-by-Step Workflow for Partial Automation

 

Step 1: Patch Released

 

When a vendor like Microsoft or Red Hat releases a patch (Day 1), Endpoint Central detects the available updates and prepares them for deployment.

 

Step 2: Deploy Patches to a Test Group

 

The patches are first deployed to a test group of servers. These servers simulate the production environment but aren’t critical to business operations, providing a safe place to evaluate the patch.

 

Step 3: Installation Success Check

 

After deployment, Endpoint Central checks the patch installation on the test group. If any issues arise:

 

If Installation Fails: Administrators will troubleshoot and resolve the issues before moving forward with further deployment.

If Installation Succeeds: The system waits for an observation period (typically 7 days) to ensure no adverse effects occur post-installation.

 

(You can configure an observation period ranging from one week to one month, depending on the risk tolerance and criticality of the environment. During this period, you can monitor how the patch performs, ensuring that it does not cause any unintended issues or performance degradation.)

 

Step 4: 7-Day Observation Period

 

During this time, the servers are monitored for any potential issues caused by the patches. If no problems arise, Endpoint Central automatically approves the patch for deployment. If problems are detected—whether internally or through news reports—the patch is manually declined to avoid wider rollout.

 

(You can choose to manually approve the patch after the observation period based on the test results. This approach gives you more control over patching decisions, ensuring that only thoroughly vetted patches are deployed to production.)

 

Step 5: Differentiated Patching for Critical and Less Critical Servers

 

Once the patches are approved, the patching process diverges based on the criticality of the servers:

 

Critical Servers: These systems are vital for business operations. Patches are published in the Self-Service Portal for manual installation by the server owners. The server owner can also manually schedule reboots at convenient times, such as during maintenance windows.

Less Critical Servers: Patches for these systems are automatically deployed, but reboots are not forced immediately. The server owners are notified to schedule reboots during non-peak hours.

 

Examples of Critical and Less Critical Servers

 

Critical Servers require careful manual installation and reboot scheduling to avoid disruptions. Examples include database servers, such as those running SQL Server or MySQL, where downtime can disrupt key operations like financial transactions. Web servers hosting critical applications like e-commerce platforms on Apache or Nginx can result in revenue loss or reputational damage if they go offline. Email servers running Microsoft Exchange are vital for communication across the organization. Application servers running backend services like Tomcat or JBoss that support mission-critical applications also fall into this category, as do financial transaction servers responsible for processing payments and financial transactions.

 

On the other hand, less critical servers can be patched with automated installations and manually scheduled reboots. This category includes development and testing servers running tools like Jenkins or GitLab, where short outages during non-business hours are tolerable. File servers hosting internal file-sharing services like Samba, print servers managing office printers via CUPS or Windows Print Server, and intranet or wiki servers running platforms like Confluence or MediaWiki also fall into this category. Additionally, non-critical backup servers used for periodic backups with tools like Veeam or Bacula can be patched during non-backup windows, making them less sensitive to immediate reboots.

 

Benefits of Partial Automation

 

Reduced Risk: By testing patches in a safe environment first, you reduce the risk of faulty patches disrupting your production servers.

Flexibility: You can manually approve critical patches for critical systems while automating the process for less critical ones.

Efficiency: Automating patch deployment for non-critical systems reduces manual intervention and keeps your patching efforts on schedule.

 

Approach 2: Full Manual Patch Management

 

While partial automation provides a balance, some organizations may prefer a fully manual approach to patch management. This approach is particularly valuable in environments where complete control over every patching decision is required, such as in highly regulated industries or environments with custom applications.

 

With a fully manual approach, the administrator makes every decision—from reviewing missing patches to selecting which ones to deploy and scheduling when they should be applied.

 

Manual Patching Workflow: Administrator-Driven Patch Management

 

Step 1: Review Patches Missing Report

 

Endpoint Central generates a Patches Missing Report after scanning your servers. This report details which patches are missing across your environment, including critical security patches, performance updates, and non-essential fixes. As the administrator, you carefully review this report to understand which patches are needed.

 

Step 2: Select Patches to Deploy

 

Once the report is reviewed, the administrator selects the patches for deployment based on factors like:

Priority: Security patches may be prioritized, while non-security updates can be delayed.

Compatibility: The administrator ensures that patches won’t cause conflicts with other software running on the servers.

 

Step 3: Publish Patches to the Self-Service Portal

 

After choosing the appropriate patches, the administrator publishes them to the Self-Service Portal. From here, server owners can manually install the patches.

 

(Alternatively, you can choose to directly deploy the patches from the Endpoint Central product console, bypassing the Self-Service Portal. Here you can configure the post-installation reboot actions—you can choose to schedule the reboot at a specified time or immediately after installation.)

 

Step 4: Monitor Patch Status

 

After patches are deployed, the administrator monitors the patch status and compliance using Endpoint Central’s reporting tools. This ensures that all patches are applied successfully and no issues arise post-installation.