Skip to content
Avanet

Install and deploy Sophos Server Protection on Windows

Windows Server is managed as Server Protection in Sophos Fusion (formerly Sophos Central). This guide takes you from selecting the correct tenant-bound installer through a representative pilot to controlled software deployment. It is deliberately not a renamed Endpoint rollout: Server licensing, Server policies, the Servers list, and acceptance criteria remain separate product boundaries.

For one server, download the Windows Server Installer from My Environment > Installers > Server Protection and run it with administrator rights. For multiple servers, deploy the same tenant-bound SophosSetup.exe through protected software distribution, initially to a pilot group. Start the next wave only after checking the protection mode, Fusion registration, group, policies, and workload.

Decide before downloading

Record these items before the first pilot:

  • Platform approval: The Sophos Windows Server system requirements (KBA-000003024, dated May 7, 2026) list Windows Server 2016, 2019, 2022 and 2025 as fully supported platforms; 2008 R2 and 2012/2012 R2 are legacy platforms requiring an Extended Support license. Sensor Mode is not supported on legacy platforms. The KBA specifies at least 8 GB free disk space, 8 GB RAM and two cores for Endpoint – Server, and at least 10 GB free disk space, 8 GB RAM and two cores for EDR/XDR/MDR – Server; an SSD boot drive is strongly recommended. Before the pilot, verify the exact edition, build, architecture, license, protection mode and server role against the current KBA and Server Core Agent release notes; test resource needs and performance under your own workload. Sophos Server Protection: platform approval explains the fuller approval and lifecycle check. If the specific combination cannot be substantiated, defer installation and ask Sophos Support to clarify.
  • License: Before installation, confirm that the correct tenant has the Server Protection entitlements required for the selected protection mode and components. A requested product without an entitlement is not installed; Sophos Fusion licensing explains the principles.
  • Protection mode: Decide whether Sophos provides full malware protection or only XDR Sensor. The sensor does not protect against threats and requires active third-party protection.
  • Network: The server must reach Sophos Fusion during installation and operation. Test DNS, HTTPS, proxy, TLS inspection, and any Message Relay from every affected server network against the current Sophos Domains and ports to allow list.
  • Rights and maintenance window: Interactive installation and the deployment job require local administrator or system rights. Plan a prompt restart after the initial installation, followed by an application function test; on business-critical systems, do this only in the approved maintenance window. Sophos recommends restarting as soon as possible after initial installation, especially after removing a competing product and so that protection features load when processes start.
  • Existing protection: For full Sophos protection, test removal, self-protection, residual drivers, and the recovery path for the previous product in advance. --nocompetitorremoval prevents the automatic removal attempt only when installing Sophos Anti-Virus; it is not a coexistence guarantee.
  • Rollout contract: Know the target servers, pilot group, intended products, Fusion group, owner, stop criteria, and recovery path before starting.

Choose the correct Server installer

In Sophos Fusion, go to My Environment > Installers, then Server Protection. There are two materially different routes.

Full malware protection

Under Full malware protection, you can use:

  • Download Windows Server Installer: downloads an installer containing all products covered by the license.
  • Choose Components…: creates an installer with deliberately selected components.

If you select XDR Sensor in Choose Components…, Sophos does not install malware protection. Do not confuse that selection with “XDR plus full protection.”

XDR Sensor with third-party protection

For the sensor-only mode, click Download XDR Sensor Windows Server Installer. A license that includes XDR is required. Move a server to this mode only when the intended third-party protection is demonstrably active and monitored after restarts.

SophosSetup.exe is bound to the tenant from which it was downloaded. Someone with a copy does not gain portal access, but can register devices in that tenant. Keep it only in an access-controlled package source. Do not attach it to tickets, commit it to a public script repository, or leave it in temporary storage after deployment.

Install one Windows Server as a pilot

  1. Select a non-critical but technically representative server. Its operating system, site, proxy route, roles, and existing security software should represent the later wave.
  2. In My Environment > Installers > Server Protection, freshly download the Windows Server installer for the intended protection mode.
  3. Transfer it to the server through a controlled channel and run it with local administrator rights.
  4. For an interactive pilot, read the prechecks and displayed product scope. Do not ignore warnings about platform, patch level, restart, or competing software; with --quiet, no interface is shown.
  5. Complete the installation and restart promptly after the initial installation in the approved maintenance window, even if no immediate restart is enforced.
  6. Validate the server locally and in Sophos Fusion using the criteria below. A finished setup process alone is not success.

The thin installer performs prechecks, registers the device through MCS, and then downloads licensed components. A setup file that starts successfully therefore proves neither Fusion connectivity nor complete protection.

Deploy multiple servers in a controlled way

Sophos documents the same thin installer and Windows command-line options for computers and servers. This does not mean Sophos certifies the surrounding RMM tool, script, or software distribution system. As a local rollout requirement, it must run in machine context, capture the actual process status and output, limit retries, and protect the installer and arguments from unauthorized access. With --quiet, no prechecks are displayed to an operator; the unattended job needs a recorded status followed by checks of the local product, Fusion registration, and policies.

An unattended pilot for full protection with XDR can be started as follows, only with the Windows Server installer for Full malware protection and confirmed Server XDR entitlement. Do not assume a sensor-only package provides full protection simply because --products=xdr was passed; check the components actually installed on the pilot:

.\SophosSetup.exe --quiet --products=xdr `
  --devicegroup="Windows Servers\Pilot" `
  --tag=Rollout:wave-0

Windows Servers\Pilot is an example and must be replaced with your Server group structure. The backslash expresses the hierarchy; group names containing spaces require quotes. If a group does not exist, it is created. A typo can therefore create the wrong group instead of producing an error.

Choose product values deliberately:

  • --products=endpoint installs malware protection without XDR features.
  • --products=xdr installs XDR plus the full protection provided by endpoint.
  • --products=xdrsensor installs XDR features without malware protection; third-party protection is mandatory.
  • --products=all is a generic Windows CLI option for licensed products, not a Server rollout recommendation: the CLI also lists products without demonstrated applicability to Windows Server. Explicitly define the approved mode and applicable components for servers, then check what was actually installed.
  • --products=none installs only the Core Agents and is suitable at most for an explicitly planned staged compatibility test. The host is not protected by Sophos in this state and must not be released for rollout until the intended protection has subsequently been installed and accepted.

In every case, a requested but unlicensed product is not installed. The command is therefore only the intended state; verify the actual products in Fusion afterward.

Add network options only when needed

An explicit installation proxy applies only during installation:

.\SophosSetup.exe --quiet --products=xdr `
  --proxyaddress=proxy.example.net:8080

Alternatively, --pacurl=<URL> specifies a PAC file. For an authenticated proxy, --proxyusername=<user> and --proxypassword=<pw> are available; the Windows CLI documents Digest Authentication for authenticated Windows endpoints, not every server/proxy combination. Validate the actual server proxy route in the pilot. Passwords can be exposed in process lists, deployment logs, or inventory systems, so never store them statically in a generally readable script.

Specify Message Relays as a comma-separated list of host and port. The documented default port is 8190:

.\SophosSetup.exe --quiet --products=xdr `
  --messagerelays=relay01.example.net:8190,192.0.2.20:8190

192.0.2.20 is a documentation address and must be replaced. There is no Windows command-line assignment for Update Caches; the installer automatically evaluates caches configured in the tenant. --localinstallsource=<path> can reduce downloads but does not replace internet access.

--registeronly, --goldimage, --notificationmode, and --nonpersistent do not belong in a normal Server rollout. They cover tenant re-registration or VDI/gold-image processes with additional prerequisites. Do not “move” an already registered server with a reinstall job or clone a normal installation.

Accept the pilot and release waves

Exactly the expected server must appear in the correct tenant under My Products > Server > Servers. Check that:

  1. Health, last activity, and open alerts are plausible.
  2. The group and Server policies and settings actually applied on this host match the rollout contract; merely assigning the default policy in Fusion is not enough. Sophos initially applies the relevant default policies when a server is protected, but the intended production policies still need checking.
  3. Installed products match the selected mode. With xdrsensor, third-party protection remains active; with full protection, Sophos malware protection is present.
  4. The promptly planned restart after initial installation (especially after removal of previous protection) is complete. Afterward, recheck agent status, removal of the old AV, components actually installed, effective policies, and any remaining restart requirements.
  5. The business role still works after the restart: compare service startup, application access, backup, monitoring, and a representative transaction test with the pre-installation state.

Agent mode differs from the plan? Check Account Health Check > Fix Server agent mode and use the Agent mode status filter under My Environment > Computers & Servers to find Product unassigned or Upgrade available. Compare the intended mode, contractual Server entitlement, installed products, and active third-party protection for each server: an intentional sensor host is not automatically a failed full-protection host. Make changes only after their effects have been approved; if needed, edit only individually approved servers through Manage Software and review the software shown there before saving. Sophos notes that even the manual workflow may show installation of all licensed software. Fix automatically installs all licensed software on affected servers and is not a blanket repair step for mixed sensor/full-protection fleets. After the next connection and update, recheck Health, agent mode, installed components, third-party protection, and applied Server policies. If entitlement is unclear or protection is missing, stop the wave and escalate to the responsible product/licensing owner or Sophos Support; do not run the installer again without testing as a mode correction.

Only after the agreed observation period and successful post-restart acceptance should a small representative wave follow. Include different Windows Server builds, sites, proxy routes, roles, and existing security products before broadening the assignment. The unchanged process code remains a deployment signal, but does not replace the local functional check or Fusion acceptance.

Route installation failures correctly

The shared Sophos source for the Windows installation process explicitly covers Endpoint and Server. The following first-line investigation is therefore evidenced for Windows Server:

  1. Preserve the time and timezone, visible message, full invocation, and unchanged process status.
  2. In C:\ProgramData\Sophos\CloudInstaller\Logs, first look for the documented SophosCloudInstaller.log. Preserve any actual attempt-specific or rotated files along with their time and timezone; do not assume a timestamped filename.
  3. Identify whether failure occurs during precheck, MCS registration, component download, or a specific component installation.
  4. Against that phase, check platform support, patch and restart state, administrator rights, system time, DNS/HTTPS, proxy/TLS inspection, and existing protection software.
  5. Only after an evidenced correction, retry once with a fresh installer from the same tenant.

Avanet’s existing Endpoint installation troubleshooting runbook is Endpoint-owned and is deliberately not linked as a Server procedure. Do not transfer its Endpoint-specific component tables, Fusion paths, or repair steps without Server evidence. If the Server failure persists after one controlled attempt, securely provide Sophos Support with the CloudInstaller log, Windows edition and build, server role, tenant/region, non-secret arguments, network route, existing security software, and an SDU collection if Support requests one.

Do not invent a numeric exit-code table or delete Sophos services, drivers, registry keys, or directories speculatively. --traillogging records message content exchanged between the server and Fusion and must only be used under current Support instructions; restrict access to these sensitive records, turn it off after installation according to the MCS instructions linked by Sophos, and confirm it is off. If those instructions cannot be read or deactivation cannot be assured, do not enable this diagnostic option.

Stop the rollout and bound rollback

Stop the next wave if servers fail to appear in Fusion, expected protection is absent, Health remains red, restarts remain pending, or a server role is impaired. First stop new assignments and automatic deployment-job retries. Keep affected servers as a clearly bounded wave so that retry loops do not overwrite logs and state.

Rolling back distribution is not the same as uninstalling. Stopping the job prevents new installations but does not remove an installed agent. Uninstallation does not restore third-party protection removed by the installer and does not automatically remove Fusion objects or policy effects. Decide per affected server whether to retain a functioning Sophos state, plan a Sophos-supported removal, or restore the previous protection through the prepared recovery path.

Tamper Protection, Unauthorized File Protection (formerly Server Lockdown), Uninstall, Gold Images, and deletion of Server objects are separate changes. For legacy servers already locked down, migration is a separate change requiring approval; no unlock, conversion, or rollback commands are taken here from an unreadable support KBA. This installation workflow does not pre-empt those changes with unverified Endpoint commands. Only after the pilot wave is stable locally and in Fusion should old package copies and previous protection be permanently cleaned up according to the approved plan.