Nel post Configurazione di Windows Defender in Windows 8, 8.1 e 10 avevo discusso di alcuni approcci per la gestione di Windows Defender. In Windows 8.1/10 e Windows Server 2012R2/2016 sono disponibili anche alcuni cmdlets PowerShell descritti nella sezione Defender Cmdlets.
I cmdlets permettono di fatto di gestire tutti gli aspetti della gestione di Windows Defender come ad esempio avvio scansione (anche offline), rilevamento dello stato dei servizi, gestione delle esclusioni, configurazioni delle preferenze di scansione e aggiornamento, esame delle infezioni rilevate e rimozione e aggiornamento delle definizioni.
Di seguito un esempio di visualizzazione dello stato di Windows Defender e aggiornamento tramite i cmdlets Get-MpComputerStatus e Update-MpSignature :
Di seguito invece la visualizzazione delle infezioni rilevate tramite il cmdlet Get-MpThreatDetection
I cmdlet per gestione di Defender possono anche essere eseguiti su computer remoti tramite la creazione di sessioni CIM mediante i cmdlets New-CimSession e Get-CimSession.
Concludendo i Defender Cmdlets permettono di fatto di implementare una gestione centralizzata di Defender che potrebbe essere utile in scenari di piccole dimensioni in cui non abbia senso implementare System Center Configuration Manager.
Nel caso si voglia approfondire come realizzare un’applicazione .NET che esegue script PowerShell per realizzare ad esempio una console centralizzata per Defender sfruttando i cmdlets disponibili in Windows 8.1/10 e Windows Server 2012R2/2016 si vedano i seguenti:
Ciao Ermanno, ottimo articolo come sempre!
Però mi spieghi una cosa, mi imbarazza un pò chiederlo… Ma in quale scenario ha senso implementare System Center Configuration Manager?
Giusto per avere un ordine di grandezza, di cosa parliamo di 200 , 300, più di 500 computer?
Grazie!
Gigi
Direi che h a senso quando il costo della gestione del parco macchine supera il costo dell’Hardware/software/Knowout necessario per implementare Configuration Manager…
La logica di questo tipo di software comunque è quella di portare ad una razionalizzazione della gestione dell’infrastruttura quindi se l’infrastruttura è molto “ordinata” sicuramente darà overhead contenuti anche solo gestendola con WSUS e GPO se invece i deploy sono frequenti già anche a 100 client il costo della gestione senza SCCM potrebbe essere elevato