Pianificare la riattivazione dei client in Configuration Manager
Si applica a: Configuration Manager (Current Branch)
Configuration Manager supporta i pacchetti di riattivazione tradizionali per riattivare i computer in modalità sospensione quando si vuole installare il software necessario, ad esempio aggiornamenti software e applicazioni.
Nota
Questo articolo descrive come funziona una versione precedente di Riattivazione lan. Questa funzionalità esiste ancora in Configuration Manager versione 1810, che include anche una versione più recente di Riattivazione lan. Entrambe le versioni di Riattivazione LAN possono, e in molti casi, essere abilitate contemporaneamente. Per altre informazioni sul funzionamento della nuova versione di Riattivazione LAN a partire dal 1810 e sull'abilitazione di una o entrambe le versioni, vedere Come configurare la riattivazione lan.
Come riattivare i client in Configuration Manager
Configuration Manager supporta i pacchetti di riattivazione tradizionali per riattivare i computer in modalità sospensione quando si vuole installare il software necessario, ad esempio aggiornamenti software e applicazioni.
È possibile integrare il metodo tradizionale dei pacchetti di riattivazione usando le impostazioni del client proxy di riattivazione. Il proxy di riattivazione usa un protocollo peer-to-peer e i computer eletti per verificare se altri computer nella subnet sono attivi e riattivarli, se necessario. Quando il sito è configurato per riattivazione LAN e i client sono configurati per il proxy di riattivazione, il processo funziona come segue:
I computer con il client Configuration Manager installato e che non sono in stato di sospensione nella subnet controllano se gli altri computer della subnet sono attivi. Eseguono questo controllo inviando a vicenda un comando ping TCP/IP ogni cinque secondi.
Se non c'è risposta da altri computer, si presuppone che siano in stato di sospensione. I computer attivi diventano computer di gestione per la subnet.
Poiché è possibile che un computer non risponda a causa di un motivo diverso da quello in sospensione (ad esempio, è disattivato, rimosso dalla rete o l'impostazione del client di riattivazione proxy non è più applicata), ai computer viene inviato un pacchetto di riattivazione ogni giorno alle 14:00 ora locale. I computer che non rispondono non verranno più considerati in stato di sospensione e non verranno svegliati dal proxy di riattivazione.
Per supportare il proxy di riattivazione, è necessario che almeno tre computer siano attivi per ogni subnet. Per soddisfare questo requisito, tre computer vengono scelti in modo non deterministico come computer di sorveglianza per la subnet. Questo stato significa che rimangono svegli, nonostante i criteri di alimentazione configurati per la sospensione o il ibernazione dopo un periodo di inattività. I computer di sorveglianza rispettano i comandi di arresto o riavvio, ad esempio a seguito di attività di manutenzione. Se si verifica questa azione, i computer di sorveglianza rimanenti riattivano un altro computer nella subnet in modo che la subnet continui ad avere tre computer di sorveglianza.
I computer di gestione chiedono al commutatore di rete di reindirizzare il traffico di rete per i computer in sospensione a se stessi.
Il reindirizzamento viene ottenuto dal computer di gestione che trasmette un frame Ethernet che usa l'indirizzo MAC del computer in sospensione come indirizzo di origine. Questo comportamento fa in modo che il commutatore di rete si comporti come se il computer in sospensione si fosse spostato sulla stessa porta in cui si trova il computer di gestione. Il computer manager invia anche pacchetti ARP per i computer in sospensione per mantenere la voce aggiornata nella cache ARP. Il computer manager risponde anche alle richieste ARP per conto del computer in sospensione e risponde con l'indirizzo MAC del computer in sospensione.
Avviso
Durante questo processo, il mapping da IP a MAC per il computer in sospensione rimane invariato. Il proxy di riattivazione funziona informando il commutatore di rete che una scheda di rete diversa usa la porta registrata da un'altra scheda di rete. Tuttavia, questo comportamento è noto come flap MAC ed è insolito per le operazioni di rete standard. Alcuni strumenti di monitoraggio di rete cercano questo comportamento e possono presumere che qualcosa non sia corretto. Di conseguenza, questi strumenti di monitoraggio possono generare avvisi o arrestare le porte quando si usa il proxy di riattivazione.
Non usare il proxy di riattivazione se gli strumenti e i servizi di monitoraggio di rete non consentono i flap MAC.
Quando un computer di gestione visualizza una nuova richiesta di connessione TCP per un computer in sospensione e la richiesta riguarda una porta su cui il computer in sospensione era in ascolto prima di andare in sospensione, il computer di gestione invia un pacchetto di riattivazione al computer in sospensione e quindi interrompe il reindirizzamento del traffico per il computer.
Il computer in sospensione riceve il pacchetto di riattivazione e si riattiva. Il computer di invio ritenta automaticamente la connessione e questa volta, il computer è attivo e può rispondere.
Il proxy di riattivazione presenta i prerequisiti e le limitazioni seguenti:
Importante
Se si dispone di un team separato responsabile dell'infrastruttura di rete e dei servizi di rete, inviare una notifica e includere il team durante il periodo di valutazione e test. Ad esempio, in una rete che usa il controllo di accesso alla rete 802.1X, il proxy di riattivazione non funzionerà e può interrompere il servizio di rete. Inoltre, il proxy di riattivazione potrebbe causare la generazione di avvisi da parte di alcuni strumenti di monitoraggio di rete quando gli strumenti rilevano il traffico per riattivare altri computer.
Tutti i sistemi operativi Windows elencati come client supportati in Sistemi operativi supportati per client e dispositivi sono supportati per riattivazione LAN.
I sistemi operativi guest eseguiti in una macchina virtuale non sono supportati.
I client devono essere abilitati per il proxy di riattivazione usando le impostazioni client. Anche se l'operazione proxy di riattivazione non dipende dall'inventario hardware, i client non segnalano l'installazione del servizio proxy di riattivazione, a meno che non siano abilitati per l'inventario hardware e non abbiano inviato almeno un inventario hardware.
Le schede di rete (e possibilmente il BIOS) devono essere abilitate e configurate per i pacchetti di riattivazione. Se la scheda di rete non è configurata per i pacchetti di riattivazione o questa impostazione è disabilitata, Configuration Manager lo configurerà e lo abiliterà automaticamente per un computer quando riceve l'impostazione client per abilitare il proxy di riattivazione.
Se un computer ha più schede di rete, non è possibile configurare la scheda da usare per il proxy di riattivazione; la scelta non è deterministica. Tuttavia, l'adattatore scelto viene registrato nel file SleepAgent_<DOMAIN>@SYSTEM_0.log.
La rete deve consentire richieste echo ICMP (almeno all'interno della subnet). Non è possibile configurare l'intervallo di cinque secondi usato per inviare i comandi ping ICMP.
La comunicazione non è crittografata e non autenticata e IPsec non è supportato.
Le configurazioni di rete seguenti non sono supportate:
802.1X con autenticazione della porta
Reti wireless
Commutatori di rete che associano indirizzi MAC a porte specifiche
Reti solo IPv6
Durate del lease DHCP inferiori a 24 ore
Se si desidera riattivare i computer per l'installazione software pianificata, è necessario configurare ogni sito primario per l'uso di pacchetti di riattivazione.
Per usare il proxy di riattivazione, è necessario distribuire le impostazioni client del proxy di riattivazione di Power Management oltre a configurare il sito primario.
Decidere se usare pacchetti di trasmissione indirizzati alla subnet o pacchetti unicast e il numero di porta UDP da usare. Per impostazione predefinita, i pacchetti di riattivazione tradizionali vengono trasmessi tramite la porta UDP 9, ma per migliorare la sicurezza, è possibile selezionare una porta alternativa per il sito se questa porta alternativa è supportata da router e firewall intermedi.
Scegliere tra Unicast e Subnet-Directed Broadcast per wake-on-LAN
Se si sceglie di riattivare i computer inviando pacchetti di riattivazione tradizionali, è necessario decidere se trasmettere pacchetti unicast o pacchetti subnet-direct broadcast. Se si usa il proxy di riattivazione, è necessario usare pacchetti unicast. In caso contrario, utilizzare la tabella seguente per determinare quale metodo di trasmissione scegliere.
| Metodo di trasmissione | Vantaggio | Svantaggio |
|---|---|---|
| Unicast | Soluzione più sicura rispetto alle trasmissioni dirette tramite subnet perché il pacchetto viene inviato direttamente a un computer anziché a tutti i computer in una subnet. Potrebbe non essere necessaria la riconfigurazione dei router (potrebbe essere necessario configurare la cache ARP). Utilizza meno larghezza di banda di rete rispetto alle trasmissioni broadcast dirette alla subnet. Supportato con IPv4 e IPv6. |
I pacchetti di riattivazione non trovano i computer di destinazione che hanno modificato l'indirizzo della subnet dopo l'ultima pianificazione dell'inventario hardware. I commutatori potrebbero dover essere configurati per inoltrare i pacchetti UDP. Alcune schede di rete potrebbero non rispondere ai pacchetti di riattivazione in tutti gli stati di sospensione quando usano unicast come metodo di trasmissione. |
| Subnet-Directed Broadcast | Frequenza di esito positivo superiore rispetto a unicast se si dispone di computer che modificano spesso il proprio indirizzo IP nella stessa subnet. Non è necessaria alcuna riconfigurazione del commutatore. Velocità di compatibilità elevata con le schede computer per tutti gli stati di sospensione, perché le trasmissioni dirette alla subnet erano il metodo di trasmissione originale per l'invio di pacchetti di riattivazione. |
Soluzione meno sicura rispetto all'uso di unicast perché un utente malintenzionato potrebbe inviare flussi continui di richieste echo ICMP da un indirizzo di origine falsificato all'indirizzo di trasmissione diretto. In questo modo tutti gli host rispondono a tale indirizzo di origine. Se i router sono configurati per consentire le trasmissioni dirette alla subnet, la configurazione aggiuntiva è consigliata per motivi di sicurezza:If routers are configured to allow subnet-directed broadcasts, the additional configuration is recommended for security reasons: - Configurare i router per consentire solo le trasmissioni dirette tramite IP dal server del sito Configuration Manager, usando un numero di porta UDP specificato. - Configurare Configuration Manager per l'uso del numero di porta non predefinito specificato. Potrebbe essere necessaria la riconfigurazione di tutti i router intermedi per abilitare le trasmissioni dirette alla subnet. Usa più larghezza di banda di rete rispetto alle trasmissioni unicast. Supportato solo con IPv4; IPv6 non è supportato. |
Avviso
Esistono rischi per la sicurezza associati alle trasmissioni dirette tramite subnet: un utente malintenzionato potrebbe inviare flussi continui di richieste echo ICMP (Internet Control Message Protocol) da un indirizzo di origine falsificato all'indirizzo di trasmissione diretto, il che causa la risposta di tutti gli host a tale indirizzo di origine. Questo tipo di attacco Denial of Service è comunemente definito attacco di puffo e viene in genere attenuato non abilitando le trasmissioni dirette tramite subnet.