Condividi tramite

Guida alla pianificazione di alto livello per passare agli endpoint nativi del cloud

  • Articolo

Consiglio

Durante la lettura degli endpoint nativi del cloud, vengono visualizzati i termini seguenti:

  • Endpoint: un endpoint è un dispositivo, ad esempio un telefono cellulare, un tablet, un portatile o un computer desktop. "Endpoint" e "dispositivi" vengono usati in modo intercambiabile.
  • Endpoint gestiti: endpoint che ricevono criteri dall'organizzazione usando una soluzione MDM o oggetti Criteri di gruppo. Questi dispositivi sono in genere di proprietà dell'organizzazione, ma possono anche essere byod o dispositivi di proprietà personale.
  • Endpoint nativi del cloud: endpoint aggiunti a Microsoft Entra. Non sono aggiunti ad ACTIVE Directory locale.
  • Carico di lavoro: qualsiasi programma, servizio o processo.

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:

  • Endpoint nativi del cloud di Windows

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.

Gestire i dispositivi usando un provider MDM nativo 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:

Esaminare i carichi di lavoro dell'endpoint e dell'utente

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:

  • Uso del fornitore del servizio
  • Aggiornamento a una nuova versione
  • Uso di un nuovo servizio
  • Implementazione di una soluzione alternativa per l'accesso e l'uso di tale servizio da un endpoint nativo del cloud
  • Convalida dei requisiti del servizio
  • Accettare che il servizio non sia compatibile con il cloud, il che può essere accettabile per gli utenti e l'organizzazione

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:

  • Accedere in modo sicuro ad app e dati da qualsiasi posizione degli utenti. L'accesso non richiede una connessione a una rete aziendale o interna.
  • Ospitato in, ospitato da o ospitato tramite un servizio cloud.
  • Non richiede o dipende da un dispositivo specifico.

Carichi di lavoro e soluzioni comuni

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.

    • Per gli endpoint nativi del cloud, l'aggiunta a Microsoft Entra è la scelta migliore per l'identità del dispositivo. Non richiede alcuna connettività a una rete, una risorsa o un servizio locale.
    • L'aggiunta ad AD locale e l'aggiunta ibrida di Microsoft Entra richiedono la connettività a un controller di dominio locale. È necessaria la connettività per l'accesso utente iniziale, per distribuire i criteri di gruppo e modificare le password. Queste opzioni non sono adatte per gli endpoint nativi del cloud.

    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.

  • 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.

  • Gestire i dati utente e le impostazioni

    I dati utente includono gli elementi seguenti:

    • Documenti utente
    • Configurazione dell'app di posta elettronica
    • Preferiti del Web browser
    • Dati specifici dell'applicazione Line of Business (LOB)
    • Impostazioni di configurazione specifiche dell'applicazione Line of Business (LOB)

    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:

    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:

    • Non viene usato nelle soluzioni native del cloud.
    • Non risolve problemi di connettività per le risorse che richiedono l'autenticazione tramite Microsoft Entra.
    • Non è la risposta o la soluzione alternativa per i requisiti di autenticazione del dominio tramite Microsoft Entra.
    • Non risolve i problemi di autenticazione del computer elencati in Problemi noti e informazioni importanti.

    Per una conoscenza più approfondita di Microsoft Entra Kerberos e degli scenari che può risolvere, vedere i blog seguenti:

Eseguire la transizione dei carichi di lavoro in fasi

La modernizzazione dei carichi di lavoro e l'adozione di endpoint nativi del cloud richiedono modifiche ai processi operativi e alle procedure. Ad esempio:

  • Gli amministratori devono comprendere in che modo le modifiche ai carichi di lavoro esistenti possono modificare i processi.
  • Il service desk deve comprendere i nuovi scenari che supporteranno.

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.

✅ Fase 1: Ottenere informazioni sui carichi di lavoro

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:

  1. 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:

    • Per supportare gli endpoint nativi del cloud
    • Per conoscere i servizi, i prodotti e le applicazioni usati da ogni carico di lavoro

    È 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.

  2. 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.

✅ Fase 2: Assegnare priorità a tutti i blocchi

Dopo aver identificato i carichi di lavoro chiave e i relativi blocchi dello stato finale, procedere come segue:

  1. 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.

  2. 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:

    • Team di vendita altamente mobile i cui requisiti principali sono gli strumenti di produttività e una soluzione di gestione delle relazioni con i clienti online
    • Knowledge Worker che accedono principalmente a contenuti già presenti nel cloud e si basano principalmente sulle app di Microsoft 365
    • Dispositivi front-line worker altamente mobili o in ambienti in cui non hanno accesso alla rete dell'organizzazione

    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.

✅ Fase 3: Eseguire la transizione dei carichi di lavoro

In questa fase si è pronti per implementare le modifiche.

  1. 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.

  2. Dopo il primo set di carichi di lavoro che supportano gli endpoint nativi del cloud, identificare altri carichi di lavoro e continuare il processo.

✅ Fase 4: Preparare gli utenti

Gli utenti hanno esperienze diverse per la ricezione, la distribuzione e il supporto nei propri dispositivi. Gli amministratori devono:

  • Esaminare i processi e la documentazione esistenti per identificare dove le modifiche sono visibili agli utenti.
  • Aggiornare la documentazione.
  • Creare una strategia di formazione per condividere le modifiche e i vantaggi che gli utenti potranno sperimentare.

Eseguire la transizione dell'organizzazione in fasi

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.

✅ Fase 1: Definire endpoint, dipendenze e attività cardine

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.

  1. Definire gli endpoint che richiedono un'identità cloud

    • Gli endpoint che usano l'accesso a Internet richiedono un'identità cloud. Questi endpoint verranno aggiunti a Microsoft Entra.
    • Gli endpoint che non usano Internet o che vengono usati solo in locale non devono avere un'identità cloud. Non eseguire la migrazione di questi scenari in modo che siano nativi del cloud.

  2. 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:

    • Processi aziendali e continuità
    • Standard di sicurezza
    • Leggi e normative locali
    • Conoscenza e uso del carico di lavoro da parte dell'utente
    • Capitale, costi operativi e budget

    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.

  3. 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.

  4. Pianificare la distribuzione di Windows Autopilot

    • Determinare come e quando i dispositivi verranno registrati nell'organizzazione.
    • Determinare e creare i tag di gruppo necessari per i criteri di Windows Autopilot.
    • Creare il profilo di Windows Autopilot con le relative impostazioni di configurazione e scegliere come destinazione i dispositivi che riceveranno il profilo.

    Per altre informazioni, vedere:

✅ Fase 2: abilitare l'identità ibrida del cloud degli endpoint (facoltativo)

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.

✅ Fase 3: Cloud attach Configuration Manager (facoltativo)

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.

✅ Fase 4: Creare un modello di verifica aggiunto a Microsoft Entra

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:

  1. Implementare una configurazione di base minima usando Intune

    Questo passaggio è importante. Non si vuole introdurre endpoint nella rete o nell'ambiente di produzione che:

    • Non seguire gli standard di sicurezza dell'organizzazione
    • Non sono configurati per consentire agli utenti di svolgere il proprio lavoro.

    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.

  2. 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.

  3. 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.

  4. 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.

✅ Fase 5: Microsoft Entra aggiunge gli endpoint di Windows esistenti

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:

    1. Eliminare il dispositivo in Intune.
    2. Eliminare la registrazione del dispositivo Windows Autopilot.
    3. Eliminare l'oggetto dispositivo Microsoft Entra esistente.

    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.

Passare da oggetti Criteri di gruppo (OGGETTI Criteri di gruppo)

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.

Gestire le impostazioni con Intune

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.

Funzionalità di Intune che è necessario conoscere

Intune include anche funzionalità predefinite che consentono di configurare gli endpoint nativi del cloud:

Usare Windows Autopilot per effettuare il provisioning di endpoint Windows nuovi o esistenti

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:

Seguire le indicazioni per gli endpoint nativi del cloud

  1. Panoramica: Che cosa sono gli endpoint nativi del cloud?
  2. Esercitazione: Introduzione agli endpoint windows nativi del cloud
  3. Concetto: microsoft entra a far parte di Microsoft Entra e ibrido Microsoft Entra aggiunto
  4. Concetto: endpoint nativi del cloud e risorse locali
  5. 🡺 Guida alla pianificazione di alto livello (Sei qui)
  6. Problemi noti e informazioni importanti