Patch Management and Software Deployment

1. What is Patch Management?

Patch Management is the systematic process of identifying, acquiring, testing, deploying, and verifying software updates (called "patches") across an organization's IT infrastructure — including operating systems, applications, and firmware.

A patch is a set of code changes provided by a software vendor to:

• Fix security vulnerabilities
• Resolve software bugs
• Improve performance or stability
• Add new features or compliance updates

A Patch Management Agent is a lightweight software client installed on each endpoint (workstation, server, laptop) that communicates with a central management console to automate and control the entire patching lifecycle.

2. Why Use Patch Management?

5. Patch Categories

Patches are organized into the following categories for better management and filtering:

6. Deployment Policies

The Patch Management Agent supports 5 deployment policies, each designed for a different level of user interaction and deployment timing.

📋 Policy 1 — Interactive (User-Visible Pop-Up Prompt)

Overview: This policy allows full user intervention. When patches are ready to be installed, a pop-up notification is displayed to the end user on their screen asking them to initiate or approve the patch installation.

How It Works:

1. Admin pushes patch deployment with Policy 1 assigned
2. Agent detects the patch and triggers a pop-up dialog on the user's screen
3. The dialog displays:
   • Patch name and description
   • Severity level (e.g., Critical, High)
   • Available action buttons: [ Install Now ] | [ Remind Me Later ] | [ Skip ]
4. User clicks Install Now → patch installation begins immediately
5. If user clicks Remind Me Later → pop-up re-appears after a configured snooze interval
6. If user clicks Skip → installation is deferred (admin can enforce a deadline after N skips)

Use Case:

• End-user workstations where user awareness and consent is important
• Environments with flexible working hours
• Non-critical patches where user control is acceptable

Configuration Options:

📋 Policy 2 — Custom Schedule with User Intervention (User-Triggered Schedule)

Overview: This policy allows user intervention with schedule awareness. It asks the user to install patches, but the trigger point is determined by a user-defined or admin-defined schedule. The patch installation prompt is shown based on a time condition — either before 6:00 AM or after 6:00 AM.

How It Works:

1. Admin deploys patch with Policy 2 and sets a time-based trigger
2. Agent monitors the system clock continuously
3. When the time condition is met:
   • Trigger: After 6:00 AM → Pop-up appears during the user's working hours
   • Trigger: Before 6:00 AM → Pop-up appears during early morning / off-hours
4. User is prompted to confirm or schedule the installation
5. User acknowledges → installation begins as per user response

Time-Based Trigger Logic:

IF current_time > 06:00 AM → Trigger Policy 2 (show prompt to user) IF current_time < 06:00 AM → Trigger Policy 3 (silent background install)

Use Case:

• Organizations where some users start early and others start late
• Controlled patch windows with user consent during specific hours
• Flexible deployments where time-of-day determines interaction level

Configuration Options:

📋 Policy 3 — Silent Installation (System Idle Detection)

Overview: This policy performs a completely silent patch installation — no user pop-up, no notification, no interaction required. The patch is installed automatically in the background when the system is detected as idle / free.

How It Works:

1. Admin deploys patch with Policy 3 assigned
2. Agent continuously monitors system resource usage:
   • CPU usage
   • RAM usage
   • Active user sessions
   • Disk I/O activity
3. When the system meets the "idle" threshold (e.g., CPU < 10%, no active user input for X minutes):
   • Agent silently downloads and installs the patch in the background
   • User sees no interruption or notification
4. Installation logs are reported back to the central console silently
5. If a restart is required, it can be deferred to Policy 4 behavior

System Idle Conditions Checked:

Use Case:

• Servers and background workstations
• High-security environments with zero user disruption policy
• Patches that must not interrupt active user sessions
• Critical infrastructure patching during off-hours

📋 Policy 4 — Silent Installation on Service/System Restart

Overview: This policy also performs a silent, non-interactive patch installation, but the installation is triggered specifically when the system or a service restarts. This ensures patches are applied at the natural restart lifecycle of the machine without forcing reboots.

How It Works:

1. Admin deploys patch with Policy 4 assigned
2. Agent queues the patch and waits — no immediate installation
3. Agent monitors for a restart event:
   • System Restart — When the user or admin shuts down/reboots the machine
   • Service Restart — When a related Windows/Linux service is restarted
4. On detecting the restart event → Agent silently installs the patch during the boot sequence or service startup
5. Installation is completed before the system comes back fully online
6. Patch status is reported to the console after system resumes

Restart Trigger Types:

Use Case:

• Patches that inherently require a restart to apply
• Minimal disruption — piggybacks on planned maintenance restarts
• Server environments with scheduled restart windows
• Avoiding forced reboots mid-workday

📋 Policy 5 — Immediate Silent Deployment (Direct Deploy on Request)

Overview: This is the most aggressive deployment policy — a fully silent, immediate patch installation triggered the moment a deployment request is received. No waiting, no idle check, no restart trigger — the patch is installed right now, transparently in the background.

How It Works:

1. Admin issues a direct deploy command from the console for a specific patch or patch group
2. The deploy request is pushed to the agent in real time
3. Agent receives the request and immediately begins downloading and installing the patch
4. Installation happens silently with no user notification or interruption
5. Post-installation status (success / failure / reboot required) is reported instantly to the console

Execution Flow:

Admin Console → Deploy Command → Agent Receives Request ↓ Agent Downloads Patch → Silent Installation Begins → Patch Applied ↓ Status Reported to Console → Dashboard Updated in Real Time

Use Case:

• Emergency / Zero-Day vulnerability response — immediate patching required
• Critical security patches that cannot wait for idle state or restart events
• Admin-controlled urgent deployments across multiple endpoints simultaneously
• Compliance-driven mandates with tight deadlines

7. Severity-Based Installation

After syncing patch data, patches are classified by severity level to allow priority-based deployment and filtering.

Severity Levels

Severity-Based Auto-Deployment Rules

Admins can configure auto-approval rules based on severity:

IF severity == CRITICAL → Auto-approve + Deploy with Policy 5 IF severity == HIGH → Auto-approve + Deploy with Policy 3 IF severity == MEDIUM → Queue for review, Deploy with Policy 1 or 2 IF severity == LOW → Hold for admin approval, Deploy with Policy 1 IF severity == INFO → Manual deployment only

Post-Sync Patch Dashboard View

After syncing, the admin dashboard displays patch inventory organized by:

• Per User — Which patches are pending/installed on each user's device
• Per Category — OS, Software,Hardware.
• Per Severity — Critical → Informational
• Per Department/Group — IT, Finance, HR, etc.
• Installation Status — Installed ✅ | Pending ⏳ | Failed ❌ | Excluded ⛔

8. Time-Based Installation

Administrators can define maintenance windows to ensure patches are deployed only during approved time periods.

Time Window Configuration

Example Time-Based Policy Matrix

9. User-Based vs Admin-Based Deployment

The portal supports role-based access control for patch deployment operations.

👨‍💼 Admin-Only Mode

👤 User Mode

Admin-Only Deployment: Admins can restrict certain critical patch deployments to be admin-initiated only, preventing users from triggering or canceling them.

User-Only Deployment: For self-service scenarios, specific patches (e.g., non-critical app updates) can be made available to users to install on-demand through their self-service portal.

10. Software Deployment Add-On

Beyond OS and security patches, the Patch Management Portal includes a Software Deployment Add-On for complete application lifecycle management.

📦 Features

🔄 Software Deployment Workflow

Admin uploads package to portal ↓ Package added to Software Library ↓ Admin selects target devices / user groups ↓ Selects Deployment Policy (1–5) ↓ Agent receives deployment request ↓ Application installed / uninstalled silently or with user prompt ↓ Status reported to console dashboard

📋 Supported Package Types

11. Sync & Dashboard Overview

🔄 Patch Sync Process

When the admin triggers a Sync, the system:

1. Connects to vendor patch repositories (Microsoft WSUS, third-party feeds, CVE databases)
2. Downloads latest patch metadata (ID, name, severity, category, release date, affected versions)
3. Cross-references installed software on each endpoint
4. Calculates compliance gap — patches available but not yet installed
5. Updates the dashboard with the latest patch inventory and device compliance status

📊 Dashboard Views

📌 Quick Reference Card

Policy 1 → User Pop-Up → Manual user install Policy 2 → Scheduled Pop-Up → Time-triggered user install (before/after 6 AM) Policy 3 → Silent + System Idle → Background install when system is free Policy 4 → Silent + Restart Event → Install triggered on reboot/service restart Policy 5 → Silent + Immediate → Instant install on deploy request (emergency) Severity: Critical > High > Medium > Low > Informational Roles: Admin (full control) | User (self-device only) Add-On: Software Deploy → Install / Uninstall apps via portal

Documentation Version: 1.0 | Patch Management Agent — Internal Reference