Eventi
19 nov, 23 - 21 nov, 23
Acquisire competenze su richiesta con sessioni online progettate per soddisfare le sfide del settore in Microsoft Ignite.
Iscriviti subitoQuesto browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Suggerimento
Durante la lettura degli endpoint nativi del cloud, vengono visualizzati i termini seguenti:
Questa guida di pianificazione di alto livello include idee e suggerimenti che è necessario prendere in considerazione per l'adozione e la migrazione agli endpoint nativi del cloud. Viene illustrata la gestione dei dispositivi, la revisione & la transizione dei carichi di lavoro esistenti, l'applicazione di modifiche all'organizzazione, l'uso di Windows Autopilot e altro ancora.
Questa funzionalità si applica a:
Lo spostamento degli endpoint windows in nativo del cloud presenta molti vantaggi, inclusi i vantaggi a lungo termine. Non si tratta di un processo notturno e deve essere pianificato per evitare problemi, interruzioni e impatto negativo sull'utente.
Per altre informazioni sui vantaggi per l'organizzazione e gli utenti, vedere Che cosa sono gli endpoint nativi del cloud.
Per avere successo, considerare le aree chiave descritte in questo articolo per la pianificazione e la distribuzione. Con la pianificazione, le comunicazioni e gli aggiornamenti dei processi appropriati, l'organizzazione può essere nativa del cloud.
La gestione degli endpoint, inclusi gli endpoint nativi del cloud, è un'attività importante per tutte le organizzazioni. Con gli endpoint nativi del cloud, gli strumenti di gestione usati devono gestire gli endpoint ovunque si trovino.
Se attualmente non si usa una soluzione di gestione dei dispositivi mobili (MDM) o si vuole passare a una soluzione Microsoft, gli articoli seguenti sono risorse valide:
Con la famiglia di prodotti e servizi di Microsoft Intune, sono disponibili le opzioni di gestione degli endpoint seguenti:
Microsoft Intune: Intune è basato al 100% sul cloud e usa l'interfaccia di amministrazione di Intune per gestire i dispositivi, gestire le app nei dispositivi, creare & distribuire criteri, esaminare i dati dei report e altro ancora.
Per altre informazioni sull'uso di Intune per gestire gli endpoint, vedere:
Microsoft Configuration Manager: Configuration Manager usa un'infrastruttura locale e può gestire i server. Quando si usa la co-gestione, alcuni carichi di lavoro usano Configuration Manager (locale) e alcuni carichi di lavoro usano Microsoft Intune (cloud).
Per gli endpoint nativi del cloud, le soluzioni di Configuration Manager devono usare un gateway di gestione cloud euna co-gestione.
A livello generale, la distribuzione di endpoint nativi del cloud richiede strategie moderne per identità, distribuzione software, gestione dei dispositivi, aggiornamenti del sistema operativo e gestione dei dati utente & configurazione. Microsoft offre soluzioni che supportano queste aree per gli endpoint nativi del cloud.
Per iniziare, esaminare ogni carico di lavoro e determinare come può o supporterà gli endpoint nativi del cloud. Alcuni carichi di lavoro potrebbero già supportare endpoint nativi del cloud. Il supporto nativo dipende dal carico di lavoro specifico, dal modo in cui l'organizzazione implementa i servizi del carico di lavoro e dal modo in cui gli utenti usano i servizi.
Per determinare se i carichi di lavoro supportano gli endpoint nativi del cloud, è necessario analizzare e convalidare questi servizi.
Se un servizio o una soluzione non supporta gli endpoint nativi del cloud, determinarne l'impatto e la criticità sugli utenti e sull'organizzazione. Quando si dispone di queste informazioni, è possibile determinare i passaggi successivi, che possono includere:
In entrambi i casi, è consigliabile pianificare l'aggiornamento dei carichi di lavoro per supportare gli endpoint nativi del cloud.
I carichi di lavoro devono avere le caratteristiche seguenti:
Gli endpoint nativi del cloud includono anche i servizi e i carichi di lavoro che supportano gli endpoint.
I carichi di lavoro seguenti sono configurazione, strumenti, processi e servizi per abilitare la produttività degli utenti e la gestione degli endpoint.
I carichi di lavoro, i dettagli esatti e come aggiornare i carichi di lavoro per gli endpoint nativi del cloud potrebbero essere diversi. Inoltre, non è necessario eseguire la transizione di ogni carico di lavoro. Tuttavia, è necessario considerare ogni carico di lavoro, il relativo impatto sulla produttività degli utenti e le capacità di gestione dei dispositivi. La conversione di alcuni carichi di lavoro per l'uso di endpoint nativi del cloud potrebbe richiedere più tempo rispetto ad altri. I carichi di lavoro possono anche avere interdipendenze tra loro.
Identità del dispositivo
L'identità di un dispositivo è determinata dai provider di identità (IdP) che hanno conoscenza del dispositivo e un trust di sicurezza con il dispositivo. Per gli endpoint di Windows, gli IdP più comuni sono Active Directory locale (AD) e Microsoft Entra ID. Gli endpoint con identità di uno di questi IdP vengono in genere aggiunti a uno o aggiunti a entrambi.
Nota
La registrazione di Microsoft Entra, talvolta definita aggiunta all'area di lavoro, è solo per scenari BYOD (Bring Your Own Device). Non deve essere usato per gli endpoint Windows di proprietà dell'organizzazione. Alcune funzionalità potrebbero non essere supportate o funzionare come previsto negli endpoint di Windows registrati in Microsoft Entra.
Effettuare il provisioning degli endpoint
Per gli endpoint di aggiunta a Microsoft Entra appena distribuiti, usare Windows Autopilot per preconfigurare i dispositivi. L'aggiunta a Microsoft Entra è in genere un'attività guidata dall'utente e Windows Autopilot è progettato tenendo presente gli utenti. Windows Autopilot consente il provisioning tramite il cloud da qualsiasi posizione su Internet e da qualsiasi utente.
Per altre informazioni, vedere:
Distribuire software e applicazioni
La maggior parte degli utenti ha bisogno e usa software e applicazioni non inclusi nel sistema operativo di base. In molti casi, l'IT non conosce o comprende i requisiti specifici dell'app. Tuttavia, la distribuzione e la gestione di queste applicazioni sono ancora responsabilità del team IT. Gli utenti devono essere in grado di richiedere e installare le applicazioni necessarie per eseguire il proprio lavoro, indipendentemente dall'endpoint in uso o da dove lo usano.
Per distribuire software e applicazioni, usare un sistema basato sul cloud, ad esempio Intune o Configuration Manager (con cmg e co-gestione).
Creare una baseline di app che gli endpoint devono avere, ad esempio Microsoft Outlook e Teams. Per altre app, consentire agli utenti di installare le proprie app.
Negli endpoint è possibile usare l'app Portale aziendale come repository di app. In alternativa, usare un portale rivolto all'utente che elenca le app che possono essere installate. Questa opzione self-service riduce il tempo di provisioning dei dispositivi nuovi ed esistenti. Riduce anche l'onere per l'IT e non è necessario distribuire app di cui gli utenti non hanno bisogno.
Per altre informazioni, vedere:
Configurare le impostazioni del dispositivo usando i criteri
La gestione dei criteri e della sicurezza è fondamentale nella gestione degli endpoint. I criteri degli endpoint consentono all'organizzazione di applicare una baseline di sicurezza specifica e una configurazione standard agli endpoint gestiti. Sono disponibili molte impostazioni che è possibile gestire e controllare sugli endpoint. Creare criteri che configurano solo gli elementi necessari nella baseline. NON creare criteri che controllano le preferenze utente comuni.
L'imposizione tradizionale dei criteri tramite criteri di gruppo non è possibile con gli endpoint nativi del cloud. È invece possibile usare Intune per creare criteri per configurare molte impostazioni, incluse le funzionalità predefinite, ad esempio il Catalogo impostazioni e i modelli amministrativi.
L'analisi di Criteri di gruppo in Intune può analizzare gli oggetti Criteri di gruppo locali, verificare se tali impostazioni sono supportate nel cloud e creare criteri usando tali impostazioni.
Se sono presenti criteri che emettono certificati, gestiscono BitLocker e forniscono endpoint protection, è necessario creare nuovi criteri in Intune o Configuration Manager (con un cmg e una co-gestione).
Per altre informazioni, vedere:
Distribuire gli aggiornamenti di sicurezza, funzionalità e app
Molte soluzioni locali non possono distribuire gli aggiornamenti agli endpoint nativi del cloud o distribuirli in modo efficiente. Dal punto di vista della sicurezza, questo carico di lavoro può essere il più importante. Dovrebbe essere il primo carico di lavoro di cui si esegue la transizione per supportare gli endpoint windows nativi del cloud.
Distribuire gli aggiornamenti di Windows usando un sistema basato sul cloud, ad esempio Windows Update per le aziende. Usando Intune o Configuration Manager (con un cmg e la co-gestione), è possibile usare Windows Update for Business per distribuire gli aggiornamenti della sicurezza e delle funzionalità.
Per altre informazioni, vedere:
Distribuire gli aggiornamenti delle app di Microsoft 365 usando le opzioni seguenti:
Per altre informazioni, vedere:
Gestire i dati utente e le impostazioni
I dati utente includono gli elementi seguenti:
Gli utenti devono creare e accedere ai propri dati da qualsiasi endpoint. Anche questi dati devono essere protetti e potrebbero dover essere condivisi con altri utenti.
Archiviare i dati utente e le impostazioni in un provider di archiviazione cloud, ad esempio Microsoft OneDrive. I provider di archiviazione cloud possono gestire la sincronizzazione dei dati, la condivisione, l'accesso offline, la risoluzione dei conflitti e altro ancora.
Per altre informazioni, vedere La guida di OneDrive per le aziende.
Importante
Alcune impostazioni utente, ad esempio le preferenze del sistema operativo o le impostazioni specifiche dell'applicazione, vengono archiviate nel Registro di sistema. L'accesso a queste impostazioni da qualsiasi posizione potrebbe non essere realistico e potrebbe essere vietato la sincronizzazione con endpoint diversi.
È possibile che queste impostazioni possano essere esportate e quindi importate in un altro dispositivo. Ad esempio, è possibile esportare le impostazioni utente da Outlook, Word e altre app di Office.
Accedere alle risorse locali
Alcune organizzazioni non possono eseguire la transizione di alcuni carichi di lavoro a soluzioni native del cloud. L'unica opzione può essere l'accesso a risorse o servizi locali esistenti da un endpoint nativo del cloud. Per questi scenari, gli utenti devono accedere.
Per questi servizi, risorse e applicazioni locali, considerare le attività seguenti:
Autenticazione e autorizzazione: per accedere alle risorse locali dagli endpoint nativi del cloud, gli utenti devono autenticare e verificare chi sono. Per informazioni più specifiche, vedere Autenticazione e accesso alle risorse locali con endpoint nativo del cloud.
Connettività: esaminare e valutare le app & risorse che risiedono solo in locale. La connettività e l'accesso a queste risorse devono essere disponibili in locale e senza alcuna connettività diretta, ad esempio una VPN. Questa attività può includere il passaggio a versioni SaaS delle app, usando Microsoft Entra Application Proxy, Desktop virtuale Azure, Windows 365, SharePoint, OneDrive o Microsoft Teams.
Nota
Microsoft Entra non supporta il protocollo di autenticazione Kerberos. Active Directory locale supporta il protocollo di autenticazione Kerberos. Nella pianificazione è possibile ottenere altre informazioni su Microsoft Entra Kerberos. Se configurati, gli utenti accedono a un endpoint nativo del cloud usando il proprio account Microsoft Entra e possono accedere ad app o servizi locali che usano l'autenticazione Kerberos.
Microsoft Entra Kerberos:
Per una conoscenza più approfondita di Microsoft Entra Kerberos e degli scenari che può risolvere, vedere i blog seguenti:
La modernizzazione dei carichi di lavoro e l'adozione di endpoint nativi del cloud richiedono modifiche ai processi operativi e alle procedure. Ad esempio:
Quando si esaminano gli endpoint e i carichi di lavoro, suddividere la transizione in fasi. Questa sezione offre una panoramica di alcune fasi consigliate che l'organizzazione può usare. Queste fasi possono essere ripetute tutte le volte necessarie.
Questa fase è la fase di raccolta delle informazioni. Consente di stabilire l'ambito di ciò che è necessario considerare per la transizione dell'organizzazione al cloud nativo. Implica la definizione esatta di servizi, prodotti e applicazioni coinvolti in ogni carico di lavoro nell'ambiente.
In questa fase:
Inventariare le informazioni e i dettagli correnti del carico di lavoro. Ad esempio, conoscere lo stato corrente, cosa forniscono, chi servono, chi li gestisce, se sono critici per i nativi del cloud e come sono ospitati.
Quando si dispone di queste informazioni, è possibile comprendere e definire l'obiettivo finale, ovvero:
È necessario coordinarsi con i proprietari dei diversi servizi, prodotti e applicazioni. Si vuole assicurarsi che gli endpoint nativi del cloud supportano la produttività degli utenti senza vincoli di connettività o posizione.
Esempi di servizi e applicazioni comuni includono applicazioni line-of-business (LOB), siti Web interni, condivisioni file, requisiti di autenticazione, meccanismi di aggiornamento delle applicazioni e del sistema operativo e configurazione dell'applicazione. Fondamentalmente, includono qualsiasi cosa e tutto ciò di cui gli utenti hanno bisogno per svolgere completamente il proprio lavoro.
Verificare lo stato finale per ogni carico di lavoro. Identificare i blocchi noti che impediscono di raggiungere questo stato finale o di supportare gli endpoint nativi del cloud.
Alcuni carichi di lavoro e i relativi servizi & applicazioni potrebbero essere già compatibili con il cloud o abilitati. Alcuni potrebbero non essere. Il passaggio allo stato finale per ogni carico di lavoro può richiedere investimenti dell'organizzazione & impegno. Può includere l'aggiornamento del software, il "sollevamento e lo spostamento" in una nuova piattaforma, la migrazione a una nuova soluzione o l'applicazione di modifiche alla configurazione.
I passaggi necessari per ogni carico di lavoro sono diversi per ogni organizzazione. Dipendono dal modo in cui il servizio o l'applicazione è ospitato e accessibile dagli utenti. Questo stato finale deve affrontare la sfida principale di consentire agli utenti di svolgere il proprio lavoro su un endpoint nativo del cloud, indipendentemente dalla posizione o dalla connettività alla rete interna.
In base a ogni stato finale definito, è possibile individuare o definire che l'abilitazione del cloud di un servizio o di un'applicazione è difficile o bloccata. Questa situazione può verificarsi per motivi diversi, incluse le limitazioni tecniche o finanziarie. Queste limitazioni devono essere chiare e comprensibili. È necessario esaminarne l'impatto e determinare come spostare ogni carico di lavoro in modo che sia compatibile con il cloud.
Dopo aver identificato i carichi di lavoro chiave e i relativi blocchi dello stato finale, procedere come segue:
Assegnare priorità a ogni blocco e valutare ogni blocco per la risoluzione.
Potrebbe non essere necessario o necessario risolvere tutti i blocchi. Ad esempio, l'organizzazione potrebbe avere carichi di lavoro o parte di carichi di lavoro che non supportano gli endpoint nativi del cloud. Questa mancanza di supporto può essere o meno significativa per l'organizzazione o gli utenti. L'utente e l'organizzazione possono prendere questa decisione.
Per supportare il test e il modello di verifica (POC), iniziare con un set minimo di carichi di lavoro. L'obiettivo è testare e convalidare un esempio dei carichi di lavoro.
Come parte del poc, identificare un set di utenti e dispositivi in un progetto pilota per eseguire uno scenario di produzione reale. Questo passaggio consente di dimostrare se lo stato finale consente la produttività degli utenti.
In molte organizzazioni è presente un ruolo o un gruppo aziendale più facile da migrare. Ad esempio, è possibile scegliere come destinazione gli scenari seguenti nel poc:
Per questi gruppi, esaminare i carichi di lavoro. Determinare in che modo questi carichi di lavoro possono passare alla gestione moderna, tra cui identità, distribuzione software, gestione dei dispositivi e altro ancora.
Per ognuna delle aree del progetto pilota, il numero di elementi o attività deve essere basso. Questo progetto pilota iniziale consente di creare i processi e le procedure necessari per altri gruppi. Consente anche di creare una strategia a lungo termine.
Per altre indicazioni e suggerimenti, vedere la guida alla pianificazione di Microsoft Intune. Si applica a Intune, ma include anche alcune linee guida per l'uso di gruppi pilota e la creazione di piani di implementazione.
In questa fase si è pronti per implementare le modifiche.
Spostare carichi di lavoro sbloccati nelle soluzioni native del cloud pianificate o nello stato finale. Idealmente, questo passaggio è suddiviso in elementi di lavoro più piccoli. L'obiettivo è quello di continuare le operazioni aziendali con interruzioni minime.
Dopo il primo set di carichi di lavoro che supportano gli endpoint nativi del cloud, identificare altri carichi di lavoro e continuare il processo.
Gli utenti hanno esperienze diverse per la ricezione, la distribuzione e il supporto nei propri dispositivi. Gli amministratori devono:
Le fasi seguenti sono un approccio di alto livello per le organizzazioni per spostare l'ambiente per supportare gli endpoint Windows nativi del cloud. Queste fasi sono parallele agli endpoint di transizione e ai carichi di lavoro degli utenti. Possono dipendere dalla transizione parziale o completa di determinati carichi di lavoro per supportare gli endpoint windows nativi del cloud.
Questa fase è il primo passaggio per rendere la migrazione dell'organizzazione completamente nativa del cloud. Esaminare gli elementi attualmente disponibili, definire i criteri di riuscita e iniziare a pianificare il modo in cui i dispositivi verranno aggiunti a Microsoft Entra.
Definire gli endpoint che richiedono un'identità cloud
Definire le dipendenze
Carichi di lavoro, utenti e dispositivi hanno dipendenze tecniche e non tecniche. Per eseguire la transizione con un impatto minimo per gli utenti e l'organizzazione, è necessario tenere conto di queste dipendenze.
Ad esempio, una dipendenza può essere:
Per ogni carico di lavoro, chiedere "Cosa influisce se si modificano i servizi forniti da questo carico di lavoro?". È necessario tenere conto degli effetti di questa modifica.
Definire le attività cardine e i criteri di riuscita per ogni carico di lavoro
Ogni carico di lavoro ha le proprie attività cardine e i propri criteri di successo. Possono essere basati sull'uso del carico di lavoro da parte dell'organizzazione e sulla sua applicabilità a endpoint e utenti specifici.
Per comprendere e definire lo stato di avanzamento della transizione, tenere traccia e monitorare queste informazioni.
Pianificare la distribuzione di Windows Autopilot
Per altre informazioni, vedere:
Per essere completamente nativo del cloud, Microsoft consiglia di reimpostare gli endpoint di Windows esistenti come parte di un ciclo di aggiornamento hardware. Quando si reimposta, l'endpoint viene ripristinato alle impostazioni factory. Tutte le app, le impostazioni e i dati personali nel dispositivo vengono eliminati.
Se non si è pronti per reimpostare gli endpoint, è possibile abilitare l'aggiunta ibrida a Microsoft Entra. Viene creata un'identità cloud per gli endpoint di aggiunta di Microsoft Entra ibridi. Tenere presente che l'aggiunta ibrida a Microsoft Entra richiede ancora la connettività locale.
Tenere presente che l'aggiunta ibrida di Microsoft Entra è un passaggio transizione verso il cloud nativo e non è l'obiettivo finale. L'obiettivo finale è che tutti gli endpoint esistenti siano completamente nativi del cloud.
Quando gli endpoint sono completamente nativi del cloud, i dati utente vengono archiviati in un provider di archiviazione cloud, ad esempio OneDrive. Pertanto, quando un endpoint viene reimpostato, le applicazioni utente, la configurazione e i dati sono ancora accessibili e possono essere replicati in un endpoint di cui è stato appena effettuato il provisioning.
Per altre informazioni, vedere:
Nota
Microsoft non dispone di un'utilità di migrazione per convertire gli endpoint esistenti dall'aggiunta al dominio locale o dall'aggiunta di Microsoft Entra ibrido a Microsoft Entra. Microsoft consiglia di reimpostare e ridistribuire questi dispositivi come parte di un aggiornamento hardware.
Se si usa Configuration Manager, collegare l'ambiente al cloud a Microsoft Intune. Se non si usa Configuration Manager, ignorare questo passaggio.
Quando si collega il cloud, è possibile gestire in remoto gli endpoint client, co-gestire gli endpoint con Intune (cloud) e Configuration Manager (locale) e accedere all'interfaccia di amministrazione di Intune.
Per informazioni più specifiche, passare a Collegamento cloud all'ambiente di Configuration Manager ed Esaminare l'interfaccia di amministrazione di Microsoft Intune.
Questa fase critica può iniziare in qualsiasi momento. Consente di identificare potenziali problemi, problemi sconosciuti e convalida le funzionalità generali e le soluzioni a tali problemi. Come per tutti i PC, l'obiettivo è dimostrare e convalidare le funzionalità in un ambiente aziendale effettivo anziché in un ambiente lab.
I passaggi importanti per questa fase includono:
Implementare una configurazione di base minima usando Intune
Questo passaggio è importante. Non si vuole introdurre endpoint nella rete o nell'ambiente di produzione che:
Questa configurazione minima non ha e non deve avere tutte le configurazioni possibili applicate. Tenere presente che lo scopo è individuare altre configurazioni necessarie per il corretto funzionamento degli utenti.
Configurare Windows Autopilot per gli endpoint aggiunti a Microsoft Entra
L'uso di Windows Autopilot per effettuare il provisioning di nuovi endpoint e ripetere il provisioning degli endpoint esistenti è il modo più rapido per introdurre i sistemi aggiunti a Microsoft Entra all'organizzazione. Si tratta di una parte importante del poc.
Distribuire un poc per i sistemi aggiunti a Microsoft Entra
Usare una combinazione di endpoint che rappresentano configurazioni e utenti diversi. Si vuole ottenere la maggiore convalida possibile di questo nuovo stato del sistema.
Solo l'uso di produzione reale da parte di utenti di produzione reali convalida completamente i carichi di lavoro e le relative funzionalità. Grazie all'uso naturale quotidiano degli endpoint POC Microsoft Entra, gli utenti testano e convalidano i carichi di lavoro in modo organico.
Creare elenchi di controllo delle funzionalità e degli scenari business critical e fornire questi elenchi agli utenti poc. Gli elenchi di controllo sono specifici per ogni organizzazione e possono cambiare man mano che i carichi di lavoro vengono convertiti in carichi di lavoro compatibili con il cloud.
Convalidare la funzionalità
La convalida è un processo ripetitivo. Si basa sui carichi di lavoro e sulla relativa configurazione all'interno dell'organizzazione.
Raccogliere commenti e suggerimenti degli utenti sugli endpoint POC, sui carichi di lavoro e sulle relative funzionalità. Questo feedback deve essere da parte degli utenti che hanno usato gli endpoint nativi del cloud.
È possibile individuare altri blocchi e in precedenza sconosciuti o non considerati per i carichi di lavoro o gli scenari.
Usare le attività cardine e i criteri di riuscita stabiliti in precedenza per ogni carico di lavoro. Consentono di determinare lo stato di avanzamento e l'ambito del poc.
In questa fase viene eseguito il passaggio del nuovo provisioning degli endpoint windows a Microsoft Entra aggiunto. Dopo aver risolto tutti i blocchi e i problemi, è possibile spostare i dispositivi esistenti in modo che siano completamente nativi del cloud. Sono disponibili le opzioni seguenti:
Opzione 1: sostituire i dispositivi. Se i dispositivi sono alla fine del ciclo di vita o non supportano la sicurezza moderna, sostituirli è la scelta migliore. I dispositivi moderni supportano funzionalità di sicurezza nuove e avanzate, inclusa la tecnologia TPM (Trusted Platform Module).
Opzione 2: Reimpostare i dispositivi Windows. Se i dispositivi esistenti supportano le funzionalità di sicurezza più recenti, è possibile reimpostare i dispositivi. Durante l'esperienza predefinita (Configurazione guidata) o quando gli utenti accedono, possono aggiungere i dispositivi a Microsoft Entra.
Prima di reimpostare un endpoint di Windows esistente, assicurarsi di:
Reimpostare quindi il dispositivo e ripetere il provisioning dell'endpoint.
Quando i dispositivi sono pronti, aggiungere questi dispositivi a Microsoft Entra usando l'opzione più adatta per l'organizzazione. Per informazioni più specifiche, vedere Dispositivi aggiunti a Microsoft Entra e Procedura: Pianificare l'implementazione dell'aggiunta a Microsoft Entra.
Molte organizzazioni usano oggetti Criteri di gruppo per configurare e gestire gli endpoint Di Windows.
Nel corso del tempo, diventa complicato a causa della mancanza di documentazione, della mancanza di chiarezza nello scopo o nei requisiti dei criteri, dell'uso di criteri legacy o non funzionali e dell'uso di funzionalità complesse. Ad esempio, potrebbero essere presenti criteri che includono filtri WMI, strutture di unità organizzative complesse e usano il blocco dell'ereditarietà, il loopback o il filtro di sicurezza.
Microsoft Intune include molte impostazioni predefinite che possono essere configurate e distribuite negli endpoint nativi del cloud. Quando si passa a Intune per la gestione dei criteri, sono disponibili alcune opzioni.
Queste opzioni non si escludono necessariamente a vicenda. È possibile eseguire la migrazione di un subset di criteri e avviarne uno nuovo per altri utenti.
Opzione 1: Avvia nuovo (scelta consigliata): Intune ha molte impostazioni per configurare e gestire gli endpoint. È possibile creare un criterio, aggiungere e configurare le impostazioni nei criteri e quindi distribuire il criterio.
Molti criteri di gruppo esistenti includono criteri che potrebbero non essere applicabili agli endpoint nativi del cloud. L'avvio aggiornato consente a un'organizzazione di convalidare e semplificare i criteri applicati esistenti, eliminando al contempo i criteri legacy, dimenticati o persino dannosi. Intune include modelli predefiniti che raggruppano le impostazioni comuni, ad esempio VPN, Wi-Fi, endpoint protection e altro ancora.
Opzione 2: Eseguire la migrazione: questa opzione prevede il sollevamento dei criteri esistenti e il loro passaggio al motore dei criteri di Intune. Può essere complesso e dispendioso in termini di tempo. Ad esempio, è possibile che siano presenti molti criteri di gruppo esistenti e che si verifichino differenze con le impostazioni locali e nel cloud.
Se si sceglie questa opzione, è necessario esaminare e analizzare i criteri di gruppo esistenti e determinare se sono ancora necessari o validi negli endpoint nativi del cloud. Si vogliono eliminare i criteri non necessari, inclusi i criteri che possono causare sovraccarichi o ridurre le prestazioni del sistema o l'esperienza utente. Non spostare i criteri di gruppo in Intune finché non si sa cosa fanno.
Intune include anche funzionalità predefinite che consentono di configurare gli endpoint nativi del cloud:
Analisi di Criteri di gruppo: è possibile importare gli oggetti Criteri di gruppo nell'interfaccia di amministrazione di Microsoft Intune ed eseguire un'analisi dei criteri. È possibile visualizzare i criteri esistenti in Intune e visualizzare i criteri deprecati.
Se si usano oggetti Criteri di gruppo, l'uso di questo strumento è un primo passaggio utile.
Per altre informazioni, vedere Analisi di Criteri di gruppo in Intune.
Catalogo delle impostazioni: vedere tutte le impostazioni disponibili in Intune e creare, configurare & distribuire un criterio usando queste impostazioni. Anche le attività che è possibile completare usando il Catalogo impostazioni in Intune possono essere una risorsa valida. Se si creano oggetti Criteri di gruppo, il catalogo delle impostazioni è una transizione naturale alla configurazione dell'endpoint nativo del cloud.
In combinazione con l'analisi di Criteri di gruppo, è possibile distribuire i criteri usati in locale negli endpoint nativi del cloud.
Per altre informazioni, vedere Catalogo impostazioni in Intune.
Modelli amministrativi: questi modelli sono simili ai modelli ADMX usati in locale e sono incorporati in Intune. Non è possibile scaricarli. Questi modelli includono molte impostazioni che controllano le funzionalità in Microsoft Edge, Internet Explorer, app di Microsoft Office, desktop remoto, OneDrive, password, PIN e altro ancora.
Se si usano modelli amministrativi in locale, usarli in Intune è una transizione naturale.
Per altre informazioni, vedere Modelli amministrativi in Intune.
È anche possibile inserire un set esistente di criteri ADMX per le app Win32 e Desktop Bridge. Per altre informazioni, vedere:
Nota
A partire da Windows 10 versione 1703, il supporto della configurazione dei criteri di gestione dei dispositivi mobili (MDM) è stato espanso per consentire l'accesso a un set selezionato di modelli amministrativi di Criteri di gruppo (criteri ADMX) per PC Windows usando il provider di servizi di configurazione dei criteri (CSP). La configurazione dei criteri ADMX in Policy CSP è diversa dal modo tipico di configurare un criterio MDM tradizionale.
Baseline di sicurezza: una baseline di sicurezza è un gruppo di impostazioni di Windows preconfigurate. Consentono di applicare e applicare impostazioni di sicurezza granulari consigliate dai team di sicurezza. Quando si crea una baseline di sicurezza, è anche possibile personalizzare ogni baseline per applicare solo le impostazioni desiderate.
È possibile creare una baseline di sicurezza per Windows, Microsoft Edge e altro ancora. Se non si è certi di dove iniziare o se si desidera che le impostazioni di sicurezza siano consigliate dagli esperti di sicurezza, esaminare le baseline di sicurezza.
Per altre informazioni, vedere Baseline di sicurezza in Intune.
Se acquisti endpoint da un OEM o un partner, dovresti usare Windows Autopilot.
Alcuni dei vantaggi includono:
Processo di installazione predefinita di Windows: presenta un'esperienza utente finale personalizzata, guidata e semplificata.
Endpoint drop-ship direttamente agli utenti finali: fornitori e OEM possono inviare gli endpoint direttamente agli utenti. Gli utenti ricevono gli endpoint, accedono con l'account dell'organizzazione (user@contoso.com
) e Windows Autopilot effettua automaticamente il provisioning dell'endpoint.
Questa funzionalità consente di limitare il sovraccarico e i costi associati ai processi IT interni e alla spedizione ad alto livello.
Per ottenere risultati ottimali, preregistrare gli endpoint con gli OEM o i fornitori. La preregistrazione consente di evitare eventuali ritardi che possono verificarsi durante la registrazione manuale degli endpoint.
Gli utenti possono reimpostare gli endpoint esistenti: se gli utenti hanno endpoint Windows esistenti, possono reimpostare i dispositivi stessi. Quando vengono reimpostati, gli endpoint vengono ripristinati allo stato minimo di base e gestito. Non richiede un intervento IT a costi elevati o l'accesso fisico all'endpoint.
Nota
Non è consigliabile usare Windows Autopilot per l'aggiunta ibrida di Microsoft Entra agli endpoint di cui è stato effettuato il provisioning. Funziona, ma ci sono alcune sfide. Nei nuovi endpoint di cui è stato effettuato il provisioning usare Windows Autopilot per l'aggiunta a Microsoft Entra (non l'aggiunta ibrida a Microsoft Entra).
Per determinare il metodo di join appropriato per l'organizzazione, passare a Microsoft Entra aggiunto e a Microsoft Entra ibrido.
Per altre informazioni su Windows Autopilot, vedere:
Eventi
19 nov, 23 - 21 nov, 23
Acquisire competenze su richiesta con sessioni online progettate per soddisfare le sfide del settore in Microsoft Ignite.
Iscriviti subito