Best Approach for Applying Patches in an Agentless Environment
Patch management can be tedious work. This topic is intended to help reduce the amount of deployments to machines to make your work more effective.
The best order of approach to maintaining patch levels on a machine is to start with product levels. Product levels are very involved. Vendors recommend installing product levels one at a time and most should be followed by a reboot before any other patches or product levels are applied. Ivanti enforces this recommendation programmatically in Security Controls by only allowing product levels to be installed one at a time.
Detailed Course of Action
The best course of action is typically as follows:
- Start with any operating system product levels.
Be sure to adequately test the product level before deploying it to your entire organization. After deploying the product level you should reboot the target machines and then perform a fresh scan. Rescanning will give you the new state of the machine so you can continue applying product levels. - Apply product levels to major products such as Office, Visio, and SQL.
Order does not matter here, but we do recommend rebooting in-between each of these major product levels. Though not as common, these product levels can also change the state of a machine considerably. - Deploy any remaining product levels to products such as MSXML, .Net, and MDAC.
These need to be pushed in separate deployments, but in this case you can do the deployments with no reboot and stagger them apart enough and then reboot after they have all been applied. - After all product levels have been deployed and the target machines have been rebooted, deploy any missing Microsoft operating system patches and perform a reboot.
- Deploy any other missing Microsoft patches such as Office, Internet Explorer, etc. and reboot as needed.
- Deploy any third party patches and reboot as needed.
- Rescan and confirm all has been applied.
Note: Operating system product levels change the state of a machine and may inhibit you from rolling back patches that were applied prior to the release of the new product level.
The steps above may span several maintenance windows. In the case that you cannot do all of the above in a single maintenance window, each step should be followed up by a patch deployment to ensure you are not open to security vulnerabilities between maintenance windows.
Tip: The steps above should be built into your machine build policy. This will ensure that machines go into the field as up to date as possible. Maintaining the machines is much easier than catching up on many months’ worth of product levels and patches.
Related Topics
- Console Software and Hardware Recommendations
- Port Requirements and Firewall Configuration
- Distributed Environment Management
- Agentless Patch Management
- Automating Patch Management in an Agentless Environment
- Agent-Based Patch Management
- Agent Rollout Options
- Installing and Supporting Agents on Internet-Based Machines
- Agent-Based Product Level and Patch Deployment Process
- Guide to Surviving Patch Tuesday
- Microsoft SQL Server Database Maintenance
- Performing Patching in a Disconnected Environment