Deploy Sophos Fusion Server Protection on RDS terminal servers

RDS sessions require a Server Protection licence; a separate Endpoint Protection licence for each session is not required. The specific contract and EULA remain authoritative. Server policies are assigned to the host, not individually to signed-in users. This is a key planning boundary for RDS, terminal-server, and Citrix environments.

The safe sequence is therefore to check the platform and licence, pilot a representative session host, decide server-wide policies in advance, drain active sessions in a controlled way, install, and release further hosts only after technical and business acceptance. VDI image creation and user identification on the firewall are separate tasks.

Scope and support boundaries

No reliably accessible, current Sophos RDS-specific support matrix has been confirmed for this guide. Older lists of Windows and Citrix versions must not be treated as current approval for new installations. Before rollout, check the specific combination of Windows guest, Sophos server agent and build, RDS or Citrix release including CU, and virtualisation environment against the applicable support scope. For Citrix, also clarify lifecycle status and any contract-dependent extended support. If the combination remains unclear, obtain written confirmation from Sophos Support; do not infer approval from a platform’s age or name.

For the server agent on a virtualised RDS guest, neither blanket approval of particular hypervisors nor a general reasonable-efforts support scope has been established. Check the guest OS, host platform, and Citrix/RDS layer separately, and clarify the support and reproduction conditions applicable to the specific case with Sophos and the platform vendor. Approval of a virtual appliance or the hypervisor does not imply approval of the protected RDS guest.

This creates three clear boundaries:

RDS or Citrix multi-user host: After confirming support for the specific platform combination, install Server Protection on the Windows guest; the server policy applies to the host.
Cloned or non-persistent VDI machines: Follow the separate Sophos VDI gold-image workflow. Do not simply clone a normally installed agent.
User-based firewall rules: This server installation does not provide them. When sessions share one server IP, SATC for Remote Desktop Services covers the separate identity mapping on Sophos Firewall.

Decide features and policies before rollout

Check the intended protection feature by feature in the target tenant against the purchased licence, Windows guest, and installed agent components. A complete RDS-specific feature matrix for the individual server licence tiers has not been confirmed here. In particular, do not equate an XDR Sensor-only installation with a protective Server Protection installation. Check the licence and contractual terms against Sophos Fusion (formerly Sophos Central) licensing and the applicable EULA.

Pilot precaution, not an established RDS support restriction: For now, do not assign the session host an Update Cache or Message Relay host role, or enable either the older Server Lockdown feature or Unauthorized File Protection (UFP) as a new hardening measure. Sophos renamed Server Lockdown to Unauthorized File Protection; this does not establish RDS-specific approval or prohibition for either the older or newer feature. Before making changes, obtain separate RDS-specific confirmation of whether the host may run a cache or relay or use such a service, and of the prerequisites for Lockdown and UFP, including any migration. This cautious pilot choice is neither a general ban nor an approval, and is no reason to disable other protection modules across the board.

Server-wide rather than user-based policies

Server policies are assigned to the session host, not as separate server policies for each RDS user. Such a server policy cannot give user A different Web, Application, Peripheral, or DLP controls from user B on the same host. This does not make any claim about other, separately configured user or firewall products.

Before the pilot, agree the effects with application and business owners:

Which applications and scripts run in all sessions?
Which peripherals do individual roles need even though the decision is server-wide?
Which Web or DLP rule is acceptable for everyone on this host?
Which shares and user-profile paths must Real-Time Scanning cover?
Which exclusions are technically proven, narrowly scoped, and documented with an owner and expiry date?

If groups genuinely need different controls, place them on separate session-host collections with an appropriate server policy for each. A broadly relaxed shared policy is not a substitute for that separation.

Desktop messages across sessions

Desktop Messaging reports protection events and is enabled by default in the server Threat Protection policy. How a message is distributed across concurrent sessions on a particular terminal server has not been established here as universal RDS behaviour. Nor has a fixed list of exceptions when messaging is disabled been confirmed. In a multi-session pilot, check who sees which messages and what notifications the components actually deployed still generate after the setting changes.

Helpdesk staff and users should not attribute a visible message to a particular session without checking. Before rollout, define message wording, the support route, and correlation by time, server, Fusion alert, and affected process. Do not close an alert solely on one user’s report.

Plan the pilot and installation

Prerequisites

Before the first host, ensure that:

The Windows guest, RDS or Citrix version, and virtualisation platform are within the confirmed support scope.
A suitable server licence is available; plan the host as a server, not with a standard endpoint installer.
The host can reach Sophos Fusion over documented network paths, directly or through a proxy or relay architecture confirmed for this RDS guest. Check use of a cache or relay separately from running one on the host.
A representative pilot host, maintenance window, technical and business acceptance criteria, and rollback owner have been selected.
Active RDS sessions can be signed out cleanly and new sign-ins blocked during the change.
A backup, snapshot, or other return point follows the platform operator’s process and has been restore-tested outside this change.
The planned server policy is assigned to the pilot group; as a precaution, the cache/relay host role and Lockdown/UFP are not enabled during the pilot until RDS-specific prerequisites are clarified.

In the correct tenant in Sophos Fusion Admin, obtain the Windows Server Installer under My Environment > Installers > Server Protection > Full malware protection, not the XDR Sensor-only installer. For automated rollout, the same principles apply as in the controlled Windows rollout: protect the tenant-bound package, run it as local administrator or SYSTEM, capture the real exit status, and do not equate a successfully started process with complete protection. Product selection, destination group, and licensing must, however, be set for Server Protection.

Run the pilot

Block new sign-ins on the pilot host, notify users, and sign out active sessions cleanly. Do not force an agent change during production sessions.
Record the baseline: hostname, OS and RDS/Citrix version, Fusion group, assigned policies, installed security software, health, and return point.
Remove competing products and their filter drivers according to the approved migration plan, or implement confirmed coexistence. Do not run two real-time scanners in parallel without validation.
Run the current server installer from the target tenant with administrative rights. For software distribution, pass the installer exit code unchanged back to the deployment system.
Complete requested restarts in the maintenance window. Only then permit sign-ins for technical testing.
With a few test accounts, exercise typical applications, profiles, printers, shares, and Web and DLP workflows. Admit real pilot users only afterwards.
Observe the host under normal multi-user load for the agreed period. There is no universal Sophos figure for session counts or CPU/RAM reserves; use the local baseline and the platform team’s acceptance criteria.

Do not change several hosts at once. One successful sign-in proves neither application compatibility across the server nor behaviour under normal multi-user load.

Acceptance and operation

A pilot succeeds only when every layer passes:

Local: The server agent reports healthy; installation and required restarts are complete.
Fusion: The host appears exactly once as a server in the correct tenant and group, is current, and receives the expected server policies.
Protection: The agreed protection components are installed; the cache/relay host role and Lockdown/UFP, withheld as a precaution, have not been enabled.
Sessions: Several test users can sign in concurrently, start core applications, load profiles, and use required resources.
Policies: The Web, Application, Peripheral, and DLP controls actually available behave as agreed in test sessions; message visibility in other sessions has been checked.
Operations: Compare CPU, memory, sign-in duration, and application response with the pre-pilot platform baseline. Investigate deviations rather than hiding them with unsubstantiated exclusions.

Plan the next small host wave only after acceptance. Continue testing policy changes on a pilot group because one server policy affects many sessions at once.

Troubleshooting and safe rollback

A user receives the wrong policy

There are no user-specific server policies on an RDS host. Check the server’s Fusion group, policy assignment, and priority first. If groups need different controls, separate host collections are the dependable solution, not an exception for each signed-in user.

A message appears in several sessions

Document this observation in your own pilot; do not treat it as a general guarantee for all RDS installations. Correlate time and server with Fusion alerts and events, then identify the triggering process. Test the effective server policy’s Desktop Messaging setting and any remaining messages from individual components in the tenant. Do not interpret a visible notification as proof that every session displaying it was affected.

Applications or sign-ins become abnormal after the pilot

Stop further rollout waves. Capture Fusion events, agent health, Windows events, and the affected process first. Then restore the last changed pilot policy to its previously documented state and retest. Add exclusions only for a confirmed process or path and with narrow scope; do not introduce broad drive, profile, or process exclusions as supposed performance optimisation.

If the issue remains, remove the host from user service and collect logs and Sophos Diagnostic Utility data for support. If a fault occurs only under Citrix or another virtual platform, clarify the necessary reproduction steps and responsibilities with Sophos Support and the platform vendor.

Suspected SSPService fault on an unstable host

If service restarts, host instability, or SSPService messages occur, preserve the exact agent and component builds, operating system, timestamps, Windows events, and diagnostic logs before making changes. Even entries such as Process registration over the secure quota in sed.log are only diagnostic clues: an RDS-specific defect with a fixed version range, log sequence, and remedy has not been confirmed here. Do not conflate other symptoms involving a similarly named service.

Stop further rollout waves and remove the affected host from user service according to maintenance and incident procedures. Ask Sophos Support for an incident ID, expected service presence after a restart, affected builds, fix version, and a remedy approved for this host. Do not toggle Tamper Protection on the basis of this clue or present a restart as a confirmed fix.

Rollback

Define rollback before the pilot and apply it according to the failure class:

Stop further assignments and rollout waves; block new sign-ins on the affected host.
For a policy fault, restore the documented previous policy assignment and retest after Fusion synchronisation.
For a platform or agent fault, end sessions cleanly, preserve diagnostics, and return the host through the approved server-uninstall or platform-restore procedure. Deleting only the Fusion device record does not uninstall the agent.
Return the host to the broker pool only after applications, concurrent sessions, Fusion state, and protection or confirmed replacement protection have passed checks.

Do not blindly restore a snapshot over an active host registered in Fusion. Whether restore or rebuild is the safe route depends on the tested RDS/Citrix and virtualisation-platform procedure. After rollback, determine the cause and run a new pilot; do not simply resume the failed wave.