How do Proxies work with Kaseya Patch Management?
Note: This article specifically addresses the use of a proxy, but also contains information relevant to firewall, web filter, and other network infrastructure configuration.
Many environments use a proxy to manage web traffic. It is important that the proxy, the Kaseya environment, and the Kaseya endpoints are configured to properly traverse the proxy. For Patch Management, this may include adjustments to the proxy configuration, the DNS or DHCP options in the environment, the KServer, and/or the local endpoints. Patching through a proxy can be successful as long as the environment is properly configured.
Kaseya leverages the Microsoft utility Windows Update Agent (WUA) for all patch scans and for some or all patch installations. WUA cannot retrieve proxy information stored within Internet Explorer, so the proxy information must configured within the Operating System OR within the DHCP or DNS configuration options for the network. Additionally, WUA accesses the Microsoft patch websites (for both scans and installations) using the System account with NULL credentials. WUA does not support the use of credentialed access via proxy, firewall, or other network infrastructure. Therefore, your proxy, firewall, web filter, etc. must allow anonymous (or NULL) access to the following websites:
In addition to the above sites, your Kaseya server and all machines configured as a LAN Share for at least one other endpoint must have access to https://go.microsoft.com/fwlink/?LinkID=74689. This site is necessary as it hosts the wsusscn2.cab file used for offline patch scanning.
If you are restricting download of .exe files via any network infrastructure (including Web Filters), you will need to allow the download of the file kPmChk.exe from the following site:
Microsoft reports the following options for instructing WUA to recognize the proxy:
Option 1: Netsh or ProxyCfg
The correct command line utility will depend on the operating system of the endpoint. Generally speaking, netsh is used for Operating Systems starting with Vista; proxyCfg is used for older Operating Systems. Please refer to Microsoft documentation to determine the correct utility for your environment. Examples of the command-line entry are:
Netsh winhttp set proxy <proxy>:<port>
Proxycfg –p <proxy>:<port>
An agent procedure can be created to run the appropriate command. To do so, create the procedure using the Execute Shell Command option with the appropriate command line parameters (the netsh or proxycfg command). Kaseya recommends testing the procedure before deploying to production machines. Additional information regarding these Microsoft utilities can be found at the following locations:
Option 2: Configuring DNS or DHCP options to allow the use of Windows Proxy Auto-Detect (WPAD)
Please refer to Microsoft documentation on these options. References can be found here:
LAN Share as a File Source – Configuring the Proxy Settings
Note: This configuration is necessary for ANY endpoint that needs to download files from the internet where a proxy is managing file downloads. This is usually necessary for LAN share machines, but may be required for individual endpoints, as well.
If you are using a LAN share as a patch file source, the LAN share will need the ability to download .exe, .msu, and .msi files from the internet. Many proxies (and possibly other network infrastructure) may block the ability to download these files. You will need to ensure your network is allowing this level of access. Also, if the LAN share must traverse a proxy, you may need to configure the proxy information within Kaseya. With this setting configured, when the scripts are generated to download the files from Microsoft, Kaseya will pass the credentials within the script to the command line code that executes to download the file. The command line will include the appropriate proxy information.
The process by which Kaseya will download the distributable patch files is fully separate from the process by which Kaseya runs a patch scan and installs patches when leveraging Windows Update Agent. Therefore, proxy information configured for WUA to traverse the network might not be sufficient for this separate command line-based download process used when a LAN share is defined as a patch file source. The complexity of your environment will dictate which settings are necessary, and some trial-and-error may be necessary to fully configure the environment for successful patching.
To configure the proxy address and port to allow downloads of files through the proxy, you will need to access the hidden proxy configuration link within the VSA. This link is located on the Agent > Agent Status page, just to the right of the “Select Columns…” button. See the following screenshot for additional information.
Once on the proxy configuration page, select the endpoint(s) and set the appropriate proxy information.
Note that this page DOES support credentialed access through the proxy. If required, Kaseya will pass the necessary credential information through the command line execution to allow the LAN share to download files through the proxy. Again, these credentials cannot be passed to WUA as WUA does not support credentialed access. Requiring proxy credentials will impact patch scan results, which patches can be identified as missing from an endpoint, and may, depending on other variables, produce inaccurate patch status results including inaccurate failures.
Any time WUA cannot traverse a proxy to complete a patch scan, the scan will complete against the alternate datasource, an offline .cab file on the local endpoint (distributed on an as-needed basis).