Patch Manager Infrastructure and Installation Requirements

System Requirements for Middle Agent Windows

System Requirements for Agent Windows

System Requirements for Middle Agent Linux

System Requirements for Agent Linux

Linux Agent and SSH Connection Requirements

Linux systems are managed through SSH connections.

The Linux agent can be configured using either of the following deployment methods:

1. One Linux agent or probe per subnet to manage multiple Linux machines within that subnet.

2. A dedicated SSH connection configured for each individual Linux machine.

The configured SSH port must be accessible from the Ceburu Patch Manager middle agent to the target Linux machines. Port 22 is used by default unless the customer has configured a custom SSH port.

SSH authentication can be configured using approved Linux credentials or SSH keys, based on the customer’s security policy.

SSH connectivity must be validated before patch deployment, software installation, system validation, or remote command execution can be performed on Linux machines.

Network and Firewall Requirements

To ensure successful installation and proper operation of Ceburu Patch Manager, the following network ports and application endpoints must be allowed within the customer infrastructure.

Application and URL Whitelisting Requirements

Application patch download URLs must be whitelisted to allow Ceburu Patch Manager to download and deploy application updates successfully.

This includes vendor download URLs, content delivery network URLs, package repository URLs, and redirect URLs used by the applications being patched.

Because application vendors may use different or dynamically changing download locations, the required URLs should be reviewed whenever a new application is added to Patch Manager.

The following domains and URLs must also be whitelisted to allow Windows updates, integrations, dependencies, and portal access:

Whitelisting must be applied at the firewall, proxy, web filtering, and endpoint security levels.

SSL inspection must not block or modify traffic to the required domains and download URLs.

Internet access is required from the Patch Manager host, probe, and applicable client machines for patch retrieval.

Redirected URLs used by application vendors must also be permitted. Blocking a redirected download URL may cause an application patch download or deployment to fail.

WinRM Requirements and Configuration:

WinRM must be enabled on Windows target machines to allow Ceburu Patch Manager to perform remote validation, software installation, patch deployment, and remote command execution.

Enable WinRM on Windows Target Machines

Run PowerShell as Administrator on each Windows target machine.

1. Enable WinRM:

winrm quickconfig -quiet

2. Enable PowerShell Remoting:

Enable-PSRemoting -Force

3. Set the WinRM Service to Start Automatically:

Set-Service WinRM -StartupType Automatic Start-Service WinRM

4. Allow WinRM Through Windows Firewall: 

Enable-NetFirewallRule -DisplayGroup "Windows Remote Management"

5. When the firewall rule is unavailable, create it manually:

New-NetFirewallRule `  -Name "WinRM_HTTP" `  -DisplayName "WinRM HTTP" `  -Protocol TCP `  -LocalPort 5985 `  -Action Allow

6. For WinRM over HTTPS, allow port 5986:

New-NetFirewallRule `  -Name "WinRM_HTTPS" `  -DisplayName "WinRM HTTPS" `  -Protocol TCP `  -LocalPort 5986 `  -Action Allow

Configure TrustedHosts:

TrustedHosts is required when the probe or distribution server connects to machines in a workgroup, another domain, or an environment where Kerberos authentication is unavailable.

Run the following commands on the probe or distribution server.

Add One Target Machine:

Set-Item WSMan:\localhost\Client\TrustedHosts `  -Value "192.168.1.149" `  -Force

Add Multiple Target Machines:
Set-Item WSMan:\localhost\Client\TrustedHosts `  -Value "192.168.1.149,192.168.1.150,192.168.1.151" `  -Force

Allow All Internal Targets:

Use this option only within a trusted internal network:

Set-Item WSMan:\localhost\Client\TrustedHosts `  -Value "*" `  -Force

Check TrustedHosts:

Get-Item WSMan:\localhost\Client\TrustedHosts

Clear TrustedHosts:

Clear-Item WSMan:\localhost\Client\TrustedHosts -Force

Allow Local Administrator Remote Access:

When the target machine is in a workgroup and local administrator credentials are used, run the following command on the target machine:

New-ItemProperty `  -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `  -Name "LocalAccountTokenFilterPolicy" `  -Value 1 `  -PropertyType DWord `  -Force

Restart WinRM:

Restart-Service WinRM

Test WinRM Connectivity:

Run the following commands from the probe or distribution server.

Test Port 5985

Test-NetConnection 192.168.1.149 -Port 5985

Expected result: TcpTestSucceeded : True

Test the WinRM Response

example: Test-WSMan 192.168.1.149

Test a Remote PowerShell Session:

$cred = Get-Credential
$session = New-PSSession ` -ComputerName 192.168.1.149 ` -Credential $cred
Invoke-Command ` -Session $session ` -ScriptBlock { hostname }
Remove-PSSession $session

For domain credentials, use:

DOMAIN\username

For workgroup or local credentials, use:

WORKGROUP\username

or:

.\username

WinRM connectivity must be validated before remote patch deployment, software installation, system validation, or remote command execution can be performed.

Prerequisites (for a successful Active directory deployment):

• Middle Agent is installed, online, and assigned.
• Domain account has local admin (or equivalent) rights on target PCs.
• Target Windows machines are reachable from the Middle Agent (same network/VPN as appropriate).
• WinRM is enabled and allowed between Middle Agent and targets.
• Firewall rules allow WinRM from the Middle Agent.
  
  

1. Middle Agent is online
   The Middle Agent must be connected and assigned (visible under Host / Middle Agent Assigned).
2. Save Active Directory (WinRM) credentials on the Middle Agent
   From the Middle Agent row, open WinRM / SSH credentials, choose Windows, and enter:
   • Domain name
   • Username
   • Password
3. Optional: verify connectivity
   Use Test / Verify so the Middle Agent tries WinRM to a known host IP with the saved credentials. This confirms domain login and WinRM before a bulk deploy.
4. Discover devices
   Scan or open the subnet device list for that Middle Agent. Select the Windows machines where the agent should be installed.
5. Deploy Agent
   Open Deploy Agent. Choose credentials:
   • Existing — use the Active Directory / WinRM account already saved on the Middle Agent (typical AD workflow).
   • New — enter domain, username, and password for this deploy only (one-off).
6. Server queues the job
   Patch Manager sends a deploy request to the Middle Agent for each selected IP (with resolved credentials and Windows as the OS).
7. Middle Agent installs remotely
   For each Windows target, the Middle Agent:
   • Authenticates with Domain\username via WinRM
   • Copies the client agent package
   • Runs silent install
   • Reports progress/status back to the UI
8. Agent comes online
   After install, the client agent registers and appears as a managed agent under that Middle Agent. Patching and inventory can then run normally.