Disinstallare Windows Defender su Windows Server

Disinstallare Windows Defender su Windows Server: cosa si può fare davvero

Su Windows Server il punto non è tanto “rimuovere” Windows Defender, quanto capire se l’obiettivo è disattivare la protezione in tempo reale, trasformare Defender in un controllo passivo oppure sostituirlo con un prodotto terzo. La differenza conta, perché su molte versioni server Defender è parte integrante del sistema e non un componente da togliere con una semplice disinstallazione.

In pratica, la domanda corretta è: vuoi liberare risorse, evitare conflitti con un antivirus aziendale, o ridurre la superficie di controllo su un server con ruolo specifico? La risposta cambia in base alla versione di Windows Server, ai ruoli installati e alla policy di sicurezza dell’ambiente.

Se il server espone servizi verso Internet, il default da senior è non togliere protezione senza un sostituto già verificato. La rimozione “secca” è quasi sempre l’ultima opzione; prima si lavora su esclusioni mirate, disattivazione controllata e verifica dei log di impatto.

Il vincolo principale: versione del sistema operativo

Il comportamento di Defender cambia molto tra le versioni. Su Windows Server 2016, 2019, 2022 e successive, Defender Antivirus è normalmente integrato. In alcuni scenari può essere disabilitato, ma non sempre rimosso come fosse una normale applicazione. Su installazioni con Desktop Experience la gestione è più semplice, ma resta comunque un componente di sistema.

Prima di fare qualsiasi modifica, identifica la versione esatta e lo stato del motore di protezione. Senza questo dato si rischia di seguire una procedura non applicabile o, peggio, di credere di aver spento Defender quando in realtà è attivo come protezione passiva.

Comandi utili per partire:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
Get-MpComputerStatus | Select-Object AMServiceEnabled,AntivirusEnabled,RealTimeProtectionEnabled,BehaviorMonitorEnabled,IsTamperProtected

Se `Get-MpComputerStatus` non restituisce nulla o il modulo non è disponibile, il dato da chiudere è il supporto PowerShell/Defender su quella build. In quel caso verifica dal pannello Servizi o da Get-WindowsFeature se il componente è presente come feature installata.

Quando ha senso non disinstallare, ma disattivare in modo controllato

La strada più pulita, nella maggior parte dei casi, è mantenere Defender installato ma disattivare la protezione in tempo reale solo se esiste un motivo tecnico concreto: conflitto con un EDR, impatto su workload molto sensibili alla scansione, o obbligo di usare una suite di sicurezza centralizzata con policy già approvate.

Questa scelta riduce il blast radius. Se qualcosa va storto, puoi riattivare il motore senza dover ripristinare feature di sistema o rifare componenti. Inoltre mantieni la possibilità di usare Defender come scan manuale o come controllo di emergenza, se il prodotto principale fallisce.

Le esclusioni vanno preferite alla disattivazione totale quando il problema è localizzato: cartelle di build, repository, VM disk, directory di database, code di backup. Non è elegante spegnere il motore se basta escludere un path ad alta attività I/O.

Verifiche prima di toccare la configurazione

Prima di cambiare lo stato di Defender, raccogli tre evidenze minime: stato del servizio, eventuale protezione anti-manomissione e presenza di un altro antivirus. Se c’è già un prodotto terzo, Defender può passare in modalità passiva automaticamente o dopo una policy specifica.

Verifiche rapide:

Get-Service WinDefend | Select-Object Name,Status,StartType
Get-MpComputerStatus | Select-Object AntivirusEnabled,RealTimeProtectionEnabled,IsTamperProtected,AMRunningMode
wmic product get name | findstr /I "antivirus endpoint security defender"

Atteso: se il server deve restare protetto da Defender, WinDefend deve essere in esecuzione e la protezione in tempo reale deve risultare attiva. KO tipico: AMRunningMode in passive mode, servizio fermo, oppure policy che impedisce modifiche locali.

Se IsTamperProtected è True, non forzare modifiche a mano senza sapere chi gestisce la policy. Il dato da chiudere è la fonte del controllo: GPO locale, GPO di dominio, Intune, SCCM o altro sistema di gestione endpoint.

Disattivazione controllata con PowerShell

Se l’obiettivo è sospendere Defender per test o per migrazione verso un altro EDR, la prima opzione è agire in modo reversibile. Su molti server la protezione in tempo reale può essere disabilitata temporaneamente, ma la persistenza dipende dalle policy locali e di dominio.

Procedura minima, da eseguire in finestra di manutenzione:

Set-MpPreference -DisableRealtimeMonitoring $true
Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled,AntivirusEnabled

Se il comando viene rifiutato, il motivo più probabile è una policy di sicurezza superiore o la protezione anti-manomissione. In quel caso non insistere con workaround locali: serve intervenire sulla policy di gestione centrale o autorizzare il cambio nel sistema di controllo endpoint.

Per riattivare:

Set-MpPreference -DisableRealtimeMonitoring $false

Assunzione: hai privilegi amministrativi locali e il server non è bloccato da una policy centralizzata non documentata.

Disattivazione via Group Policy: più pulita in dominio

In ambiente domain-joined, la via corretta è quasi sempre la Group Policy. Così eviti drift tra server, mantieni audit e puoi tornare indietro in modo consistente. La modifica locale, invece, è fragile: alla prossima refresh policy può essere annullata.

Il percorso da controllare è:

Computer Configuration
  └─ Administrative Templates
      └─ Windows Components
          └─ Microsoft Defender Antivirus

La voce da cercare è quella che disattiva Microsoft Defender Antivirus. Il nome preciso può variare leggermente in base alla lingua e alla versione delle Administrative Templates, quindi conviene cercare direttamente nel catalogo dei criteri disponibili nel tuo ambiente.

Flusso operativo consigliato:

1. Apri gpmc.msc o l’Editor Criteri di gruppo locale.
2. Individua il criterio per disattivare Defender Antivirus.
3. Applica il criterio a un’OU di test, non al dominio intero.
4. Esegui gpupdate /force sul server campione.
5. Verifica lo stato con Get-MpComputerStatus.

Per verificare l’effettiva applicazione della policy:

gpresult /h C:	emp
sop.html
start C:	emp
sop.html

Se il criterio non compare nel Resultant Set of Policy, il problema non è Defender ma la catena di applicazione GPO: link, security filtering, WMI filter o precedenza delle policy.

Rimozione del ruolo o della feature: solo se la versione lo consente

Su alcune installazioni server puoi rimuovere la feature associata a Windows Defender Antivirus, ma non è un’operazione universale né sempre consigliata. Dipende dalla release e dallo stato del sistema. Prima di tentare una rimozione, verifica quali feature sono presenti e come sono nominate nella tua build.

Comandi di inventario:

Get-WindowsFeature *Defender*
Get-WindowsFeature *Antivirus*

Se compare una feature installabile/rimuovibile, il comando tipico è:

Remove-WindowsFeature Windows-Defender

Ma non dare per scontato che il nome della feature sia quello, perché cambia tra edizioni e versioni. Il dato da chiudere è il nome esatto restituito da Get-WindowsFeature. Se il server è gestito tramite SConfig o Server Manager, la stessa informazione si vede anche nella lista delle funzionalità installate.

Prima di rimuovere, fai un backup della configurazione e verifica che ci sia un antivirus sostitutivo già installato e aggiornato. Senza sostituto, la rimozione è un downgrade di sicurezza, non una manutenzione.

Conflitto con antivirus terzo: il caso più comune

Il motivo più frequente per “disinstallare Defender” è la presenza di un agente EDR o di un antivirus enterprise. In molti casi non serve rimuovere nulla: il prodotto terzo registra la propria presenza e Defender si spegne o passa in modalità passiva. Il problema nasce quando i due prodotti si contendono la protezione in tempo reale o generano doppie scansioni sullo stesso storage.

Qui la soluzione non è una disinstallazione cieca, ma una verifica di compatibilità:

1. Controlla se il vendor supporta la coesistenza con Defender.
2. Verifica la modalità operativa dell’agente: active, passive, sensor only.
3. Accertati che le esclusioni del vendor siano allineate ai carichi del server.
4. Controlla i log per rilevare scansioni duplicate o blocchi su file temporanei.

Un esempio tipico: un server SQL o un host di virtualizzazione con scansione in tempo reale su directory di data file può vedere un calo netto di performance. In quel caso conviene escludere i path sensibili, non spegnere tutto il motore senza una misura alternativa.

Esclusioni mirate: spesso bastano e riducono il rischio

Le esclusioni sono il compromesso più sano quando Defender crea attrito operativo. Si usano per directory con I/O elevato, file temporanei di build, cartelle di backup, database e cache applicative. Invece di togliere il controllo su tutto il sistema, lo limiti dove serve davvero.

Esempio di configurazione via PowerShell:

Set-MpPreference -ExclusionPath "D:ackups","D:uild"
Set-MpPreference -ExclusionProcess "sqlservr.exe","mysqld.exe"

Prima di applicare esclusioni, documenta l’impatto atteso e poi misura. La metrica minima da osservare è la latenza del servizio o il tempo di completamento del job che prima veniva rallentato. Se il problema era reale, dovresti vedere un miglioramento su TTFB, p95 o durata del task; se non cambia nulla, la causa è altrove.

Rollback e controllo post-modifica

Ogni modifica a Defender va trattata come change di sicurezza. Il rollback deve essere chiaro e rapido: riattivare la protezione, rimuovere il criterio applicato, o ripristinare la feature se è stata rimossa.

Checklist di controllo dopo il cambio:

1. Verifica lo stato con Get-MpComputerStatus.
2. Controlla che il servizio WinDefend sia nello stato previsto.
3. Rivedi Event Viewer in Applications and Services Logs per errori Defender.
4. Se usi GPO, conferma l’applicazione con gpresult /h.
5. Se hai un antivirus terzo, verifica che sia realmente operativo e aggiornato.

Per un rollback rapido della disattivazione in PowerShell:

Set-MpPreference -DisableRealtimeMonitoring $false
Update-MpSignature

Se hai rimosso una feature, il rollback dipende dalla stessa versione del sistema e dal nome esatto della feature. In quel caso il comando inverso è in genere Install-WindowsFeature o il ripristino tramite immagine/feature source, ma va validato prima sul server specifico.

Quando fermarsi e chiedere un dato in più

Ci sono tre casi in cui non conviene improvvisare: server in dominio con policy centralizzata non nota, presenza di tamper protection attiva, versione Windows Server non confermata. In questi scenari il dato mancante non è un dettaglio: è il vincolo che decide la procedura corretta.

Se devi chiudere il gap, raccogli almeno questi elementi: output di Get-MpComputerStatus, versione esatta del sistema con systeminfo, e l’eventuale GPO applicata con gpresult /h. Con quei tre artefatti capisci subito se stai lavorando su una disattivazione reversibile, su una policy di dominio o su una feature rimovibile.

Assunzione: il server è in produzione o comunque trattato come tale, quindi ogni modifica va fatta con backup, finestra di cambio e verifica di ripristino.