Windows Defender on Windows Server

This page covers Windows Server hosts running SenseOn as endpoint antivirus and EDR, whether or not the server is separately onboarded to Microsoft Defender for Endpoint (MDE). It explains why Windows Security does not show SenseOn as an enabled antivirus product on these hosts, and the supported way to stop Windows Defender Antivirus running alongside SenseOn: passive mode for MDE-onboarded servers, or removing the feature entirely where it is not onboarded.

Installing SenseOn does not put Windows Defender Antivirus into passive mode or otherwise stand it down. Unless you act, both engines stay active and scanning. Microsoft's own guidance is that two active antivirus engines on a server "impact performance and is not supported" (Microsoft Defender Antivirus compatibility with other security products). This is not a protection gap. Both engines keep detecting. The cost is performance (every file open and process start scanned twice), duplicate or contradictory detections, and an unsupported configuration.

Scope: This applies to Windows Server 2016 and later, where Windows Defender Antivirus ships as the Windows-Defender feature. Windows Server 2012 R2 ships an older antimalware component under a different name and is not covered by the steps on this page. Contact SenseOn support if you need guidance for a 2012 R2 host.

Onboarded to Microsoft Defender for Endpoint? Do not remove the feature. The MDE sensor depends on the Windows-Defender feature being present, even when passive. Use Servers onboarded to Microsoft Defender for Endpoint below instead of the removal steps. Contact SenseOn support if you are unsure which applies to a given server.

Why Windows Security does not show SenseOn as enabled

On Windows 10/11, a third-party antivirus product registers itself with the Windows Security Center (WSC), and Windows Security then shows that product as the active antivirus, with Defender stepping into passive mode behind it.

Windows Server does not have this registration mechanism. There is no "security providers" list in Windows Security on Server editions, so no antivirus product, SenseOn included, can register itself there or ever show as enabled. This is expected behaviour and not a fault, it is true of any antivirus product on Windows Server, not just SenseOn.

To confirm protection status on a server, check the SenseOn console or the local agent's own status rather than Windows Security.

Check the current state

Before deciding what to do, check whether Defender Antivirus has already stood down, and whether the server is onboarded to Microsoft Defender for Endpoint:

Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled, RealTimeProtectionEnabled, IsTamperProtected
Get-Service Sense, WinDefend -ErrorAction SilentlyContinue | Select-Object Name, Status

Reading	Meaning
`AMRunningMode = Normal`	Defender Antivirus is active. Both engines are running. Action needed.
`AMRunningMode = Passive Mode` or `EDR Block Mode`	Defender has already stood down. SenseOn is the primary. Nothing to do.
Cmdlet fails, no `WinDefend` service, no `MsMpEng.exe` process	Defender Antivirus is already uninstalled. Nothing to do.
`Sense` service present and running	The server is onboarded to Microsoft Defender for Endpoint. Use Servers onboarded to Microsoft Defender for Endpoint below rather than removing the feature.

Servers onboarded to Microsoft Defender for Endpoint

Do not remove the Windows-Defender feature on these hosts, the MDE sensor depends on it being present, even when passive. Instead, force Defender Antivirus into passive mode with a policy registry key. Open PowerShell as an Administrator, writing to this registry path needs elevation:

New-Item 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection' -Force | Out-Null
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection' -Name ForceDefenderPassiveMode -Type DWord -Value 1
Restart-Service WinDefend
Get-MpComputerStatus | Select-Object AMRunningMode

Expect AMRunningMode to read Passive Mode. If it stays Normal and IsTamperProtected reads True, tamper protection must be turned off for the device in the Microsoft Defender portal first, then the steps above repeated. Keep the server onboarded to Microsoft Defender for Endpoint, that is fine alongside SenseOn.

Verify against your own tenant before relying on this. This changes Defender's behaviour through policy rather than removing a Windows feature. Confirm it against your tenant's tamper protection and Defender for Endpoint policy configuration before rolling it out, and contact SenseOn support if you hit unexpected results.

Servers not onboarded to Microsoft Defender for Endpoint

Manually disabling Windows Defender on a server, by changing its service start type via Group Policy or the registry, is not a supported configuration. Where a server has no Microsoft Defender for Endpoint onboarding, the supported approach is to remove the Windows-Defender Windows feature entirely.

Removing the feature

Copy and save the PowerShell script at this link to a location of your choosing.
Open PowerShell as an Administrator.
Navigate to the directory containing the script.
Run a dry run first to see what it would do without changing anything:

.\manage_windows_defender_feature.ps1 -Action Remove -WhatIf

Then run it for real:

.\manage_windows_defender_feature.ps1 -Action Remove

The script reports the server's OS version, the current Windows-Defender feature status, and the SenseOn agent's service status, before removing the feature. On Windows Server 2016 it also removes the separate Windows-Defender-Gui feature.

Restart: Removal needs a restart to complete. Until then, Windows Defender Antivirus may keep running: the feature is marked for removal but its service and files are not fully torn down until reboot, so both engines can still be active in that window. Add -Restart to let the script restart the server automatically, or ensure a reboot happens by other means (patching cadence, manual reboot). The script does not restart the server by default.

The script writes a timestamped log to %TEMP%\SenseOnDefenderFeature\DefenderFeature.log and exits with a status code, so a deployment tool can tell success from failure without parsing console output:

Exit code	Meaning
`0`	Success, or the feature was already in the requested state (nothing to do)
`2`	Not running with Administrator rights
`10`	The `Remove` action failed
`11`	The `Revert` action failed

Deploying via Group Policy

The script is safe to deploy as a Group Policy computer startup script: it does not prompt, does not restart unless -Restart is passed, and exits quickly without making changes on a host where the feature is already removed. This makes it safe to leave linked indefinitely, in the same way as the computer startup script pattern used for deploying SenseOn itself. Deployed without -Restart, the removal only completes at the server's next reboot, whenever that happens through your normal patching cycle.

powershell.exe -ExecutionPolicy Bypass -File manage_windows_defender_feature.ps1 -Action Remove

Startup scripts run as SYSTEM, which already has the Administrator rights the script needs.

Reverting

To undo a previous removal, run the script again with -Action Revert:

.\manage_windows_defender_feature.ps1 -Action Revert -WhatIf
.\manage_windows_defender_feature.ps1 -Action Revert

Revert needs internet access. By default this pulls the feature payload from Windows Update. On a server with no internet access, add -Source pointing at a Windows Server install image's sxs folder instead:
.\manage_windows_defender_feature.ps1 -Action Revert -Source D:\sources\sxs
Confirm this works in your own environment before relying on it, particularly on air-gapped or tightly firewalled servers.

Verifying

After remediating, confirm the change.

For a server where the feature was removed, after a restart:

Get-WindowsFeature -Name Windows-Defender

Installed should read False after removal, or True after a revert.

For an MDE-onboarded server put into passive mode:

Get-MpComputerStatus | Select-Object AMRunningMode

AMRunningMode should read Passive Mode or EDR Block Mode. Anything else means both engines are still active.

In both cases, also confirm the SenseOn agent is still reporting normally, either in the SenseOn console or via its local service status.

Finding affected hosts across your estate

To find hosts where Defender Antivirus is still active, open Hunt Lab, start a new query, and run the following. It looks for MsMpEng.exe in process telemetry over the last day, grouped by hostname:

SELECT
    lower(_hostname) AS hostname,
    count() AS occurrences
FROM
    endpoint_process
WHERE
    name = 'MsMpEng.exe'
    AND _time_observed >= toUnixTimestamp(subtractDays(now(), 1)) * 1000
GROUP BY
    lower(_hostname)
ORDER BY
    occurrences DESC

Wrap _hostname in lower() rather than comparing or grouping on it directly, casing varies by host.

MsMpEng.exe is the core Defender engine, so this also matches ordinary Windows 10/11 workstations where Defender is the sole antivirus by design, they need no action. Cross reference the hostnames returned against your server inventory before treating a host as affected.

Among the servers in the list, each one is either running both engines, or is already in passive mode by design. A server with no Microsoft Defender for Endpoint onboarding cannot be in passive mode, so for those hosts the list is conclusive. For MDE-onboarded hosts, confirm each one individually with the AMRunningMode check in Check the current state.