Agent-Based Patch Management
Rolling out agents takes a little more preparation work to configure the environment to get the first scans coming in from machines. An agent is a great way to automate the management of some hard to reach machines, so it can be worth the effort to rollout agents to machines.
To configure and install an agent, you must create agent policies to manage different groups of machines. The policies may be based on geographic location, role, or a combination. Each policy can be configured to execute multiple tasks on an hourly, daily, weekly, or monthly basis. Once agent policies are set up the agent can be installed on a machine. Once the agent is installed it will start to manage the machine as it was configured to do.
So, if agents require a longer rollout time, why would they be ideal in some cases? There are three general cases where agents are the preferred solution.
Laptop Users
Laptops come and go in environments today. With the agent loaded on a machine it will not matter if the laptop is not online during a maintenance window. The agent policy can be configured to fill in the gaps and supplement agentless coverage, providing a solid support model for these hard to reach road warriors.
Secure Environments
Demilitarized zones (DMZs) are a good example of an environment that may not allow file and print sharing regardless of the firewall rules and security measures that are in place. With the agent the target can be locked down and only require an outbound port to the console to update its policy. This port is 3121 (inbound port on the console). Internet connectivity may be required if you specify Vender over Internet as a source for data and patches. If internal distribution servers are to be utilized the servers will require ports 137 - 139, 445, or (if using http) whatever port IIS is configured on for the virtual directory.
Be sure to check the System Requirements for the latest port information.
Low Bandwidth Connections
The agent offsets the scans to the local machine. One of the advantages of agentless is that the bulk of the processing is done on the console. This involves network traffic and high CPU usage on the console, but the target is virtually unaware of any of this. If the agent runs the scan locally we reduce the WAN traffic from 2 - 4MB on average to 20 - 100KB on average to accurately scan and report the results to the database. An agent that also utilizes distribution servers for deployment purposes would do all of its major traffic on the local LAN and only a fraction of the WAN traffic would be required, reducing the impact on lower bandwidth connections.
Time to Implement
It typically will take 10 – 20 minutes to configure an agent policy. The rollout of the agents to the target machines may take several hours or several days depending on the number of machines and on the rollout option you choose. Rollout options are described in the next section.
Related Topics
- Console Software and Hardware Recommendations
- Port Requirements and Firewall Configuration
- Distributed Environment Management
- Agentless Patch Management
- Best Approach for Applying Patches in an Agentless Environment
- Automating Patch Management in an Agentless Environment
- 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