Ambiente IT distribuito con molti amministratori nello stesso tenant Microsoft Intune

Molte organizzazioni usano un ambiente IT distribuito in cui hanno un singolo tenant Microsoft Intune con più amministratori locali. Questo articolo descrive un modo per ridimensionare Microsoft Intune per supportare più amministratori locali che gestiscono i propri utenti, dispositivi e creano criteri personalizzati all'interno di un singolo tenant Microsoft Intune. Non esiste una risposta corretta o errata sul numero di amministratori che è possibile avere nel tenant. L'articolo è incentrato sui tenant con molti amministratori locali.

L'IT distribuito è necessario nei sistemi in cui un numero elevato di amministratori locali si connette a un singolo tenant di Intune. Ad esempio, alcuni sistemi scolastici sono organizzati in modo da avere un amministratore locale per ogni istituto di istruzione del sistema o dell'area geografica. In alcuni casi, questo ambiente distribuito può essere costituito da 15 o più amministratori locali diversi che esecedono allo stesso sistema centrale o Microsoft Intune tenant.

Ogni amministratore locale può configurare i gruppi in base alle proprie esigenze aziendali. L'amministratore locale crea in genere gruppi e organizza più utenti o dispositivi in base alla posizione geografica, al reparto o alle caratteristiche hardware. Gli amministratori locali usano anche questi gruppi per gestire le attività su larga scala. Ad esempio, gli amministratori locali possono impostare criteri per molti utenti o distribuire app in un set di dispositivi.

Ruoli che è necessario conoscere

  • Team centrale: il team o il gruppo centrale include gli amministratori globali o gli amministratori primari nel tenant. Questi amministratori possono supervisionare tutti gli amministratori locali e possono fornire indicazioni agli amministratori locali.

  • Amministratori locali: gli amministratori locali sono locali e si concentrano su criteri e profili per le posizioni specifiche; scuole, ospedali e così via.

Controllo degli accessi in base al ruolo

Questa sezione descrive brevemente i diversi modelli e propone linee guida in ogni modello per la gestione di criteri, profili e app tra il team centrale e gli amministratori locali. I modelli sono:

  • Modello di delega parziale
  • Modello di delega completa
  • Modello centrale
  • Modello devoluto
  • Modello ibrido

Modello di delega parziale

Il modello di delega parziale propone le linee guida seguenti per la gestione dei criteri tra il team centrale e gli amministratori locali.

✔️ Autorizzazioni

  • Le autorizzazioni di creazione, aggiornamento ed eliminazione per i criteri, i profili di registrazione e le app devono essere gestite dal team centrale.
  • Concedere solo autorizzazioni di lettura e assegnazione agli amministratori locali.

✔️ Riutilizzare

  • I criteri, i profili di registrazione e le app comunemente configurati devono essere resi disponibili agli amministratori locali per riutilizzare il più possibile.
  • Microsoft Intune usa molte configurazioni comuni che rientrano in alcune categorie. Esaminare le raccomandazioni elencate per i criteri di protezione delle app.
  • Quando gli amministratori locali eseguono l'onboarding, devono esaminare i criteri esistenti e riutilizzarli in base alle esigenze.

✔️ Eccezioni

  • Il team centrale può creare determinati nuovi criteri, profili di registrazione e app come eccezioni, se necessario, per conto degli amministratori locali. In genere, queste eccezioni includono qualsiasi tipo di profilo che richiede parametri univoci.

In queste due aree viene proposto un modello di delega parziale:

Linee guida per gruppi e assegnazioni per gli amministratori locali: quali sono alcune delle procedure consigliate per gli amministratori locali da adottare durante l'organizzazione dei gruppi per la gestione dei dispositivi tramite Microsoft Intune? Per scoprirlo, leggi l'articolo Raggruppamento, destinazione e filtro di Intune: Raccomandazioni per prestazioni ottimali - Microsoft Tech Community

Linee guida specifiche per le funzionalità: come vengono gestiti criteri/profili/app tra un'autorità centrale e gli amministratori locali con autorizzazioni specifiche per le diverse funzionalità. Per altre informazioni, vedere la sezione Linee guida specifiche per le funzionalità.

Modello di delega completa

Il modello di delega completa propone le linee guida seguenti per la gestione dei criteri tra il team centrale e gli amministratori locali.

  • Ogni amministratore locale deve avere il proprio tag di ambito per separare ogni oggetto che gestisce completamente.
  • Quando l'amministratore locale non deve creare, aggiornare o eliminare, concedere all'amministratore locale un ruolo con autorizzazioni di lettura e assegnazione ed evitare di assegnare altri ruoli con autorizzazioni complete. Con questo approccio, è possibile evitare di combinare le autorizzazioni tra i tag di ambito.
  • A volte gli amministratori locali potrebbero dover creare criteri, profili e app personalizzati durante la condivisione di alcuni criteri, profili e app comuni. In questi casi, creare un gruppo speciale e assegnare i criteri, i profili e le app comuni a questo gruppo. Questo gruppo non deve essere incluso nel gruppo di ambito per qualsiasi amministratore locale. Gruppo di ambito. Questo approccio impedisce che le autorizzazioni di creazione, aggiornamento ed eliminazione assegnate agli amministratori locali vengano applicate a questi criteri, profili e app comuni.

Modello centrale

Nel modello centrale, un singolo team di amministrazione locale (padre) gestisce più organizzazioni figlio. Fattori quali geografia, business unit o dimensioni possono mettere in relazione le organizzazioni figlio.

  • È disponibile un solo tag di ambito usato per coprire tutti gli amministratori locali gestiti.

  • Se possibile, il team di amministrazione locale deve standardizzare le assegnazioni tra gli amministratori locali e inserire tutti i dispositivi in un unico gruppo di Microsoft Entra per l'assegnazione. Quando non è possibile creare un singolo gruppo di Microsoft Entra, il team di amministrazione locale può creare gruppi di Microsoft Entra diversi per eseguire assegnazioni diverse.

  • Se un altro team di amministrazione locale gestisce o sposta un'organizzazione, è necessario seguire questa procedura:

    • Tutti i dispositivi e gli utenti dell'organizzazione devono essere estratti da gruppi di Microsoft Entra comuni nell'ambito del team di amministrazione locale originale.

    • Tutti i criteri/app/profili assegnati in modo univoco per l'organizzazione devono avere il tag di ambito aggiornato per il nuovo team di amministrazione locale.

Modello devoluto

Nel modello devolved, più amministratori locali (figli) vengono gestiti sia dall'amministratore locale dedicato che da un team di amministrazione locale intermedio. Gli amministratori padre e figlio hanno i propri tag di ambito per rappresentare i limiti di gestione.

  • Se sono presenti meno di 50 amministratori figlio, al team di amministrazione locale intermedio può essere concesso l'accesso assegnando tutti i tag di ambito figlio all'assegnazione del ruolo controllo degli accessi in base al ruolo dei team di amministrazione locale intermedi.
  • Se sono presenti più di 50 amministratori figlio, al team di amministrazione locale intermedio deve essere concesso il proprio tag di ambito per rappresentare l'intera raccolta di amministratori figlio che supervisionano.
  • I criteri appena creati nei tag di ambito dell'amministratore figlio devono avere il tag intermedio aggiunto da un ruolo di amministratore globale per evitare che il team di amministrazione locale intermedio perda la visibilità.

Modello ibrido

Nel modello ibrido, lo stesso amministratore padre viene usato contemporaneamente sia nel modello centrale che nel modello devolved. Non sono disponibili raccomandazioni speciali per questo modello.

Linee guida specifiche per le funzionalità

A seconda dei requisiti aziendali per ogni funzionalità, le linee guida fornite in questa sezione potrebbero consigliare di creare criteri per amministratore locale e/o delegare le autorizzazioni necessarie per la creazione di oggetti agli amministratori locali.

Nota

Le indicazioni fornite in questa sezione non riguardano tutte le funzionalità, ma riguardano solo le aree per le quali sono disponibili istruzioni speciali.

criteri di Protezione di app

i criteri di protezione App sono regole che garantiscono che i dati di un'organizzazione rimangano sicuri o contenuti in un'app gestita. Per altre informazioni, vedere criteri di Protezione di app.

Le linee guida per i criteri di Protezione di app sono suddivise tra il team centrale e gli amministratori locali come indicato di seguito:

Team centrale - Attività

  • Esaminare le esigenze aziendali e di sicurezza nell'organizzazione e generare un set di criteri di Protezione di app comuni per gli amministratori locali.
  • Esaminare le raccomandazioni elencate per identificare i controlli di sicurezza appropriati prima di creare eventuali criteri di Protezione di app.
  • Disporre di un metodo stabilito per gli amministratori locali per richiedere criteri di Protezione di app personalizzati, se necessario, per esigenze aziendali specifiche in cui i requisiti aziendali non possono essere raggiunti con i criteri comuni esistenti.
  • Per consigli specifici su ogni livello di configurazione e sulle app minime che devono essere protette, vedere Framework di protezione dei dati usando i criteri di Protezione di app, passare a criteri di Protezione di app

Amministratori locali - Autorizzazioni e attività

  • Fornire autorizzazioni di lettura e assegnazione, ma non creare, aggiornare ed eliminare le autorizzazioni per le app gestite, in modo che non siano in grado di creare criteri di Protezione di app personalizzati.
  • Fornire le autorizzazioni di lettura e assegnazione per l'assegnazione dei criteri di configurazione dell'applicazione alle app.
  • Fornire autorizzazioni di lettura e assegnazione solo quando sono presenti criteri di protezione diversi per i dispositivi gestiti e i dispositivi non gestiti. Se il team centrale sceglie di offrire un solo criterio per entrambi, i criteri di configurazione dell'applicazione non sono necessari.
  • Se vengono usati criteri di configurazione dell'applicazione, è consigliabile assegnare i criteri di configurazione dell'applicazione a tutte le istanze dell'app senza eccezioni.
  • Scegliere tra criteri di Protezione di app comuni. Gli amministratori locali possono richiedere al team centrale di creare criteri di protezione delle app personalizzati come eccezione e solo se necessario.
  • Per altre informazioni, vedere criteri di Protezione di app

Criteri di conformità

I criteri di conformità in Intune definiscono le regole e le impostazioni che gli utenti e i dispositivi devono soddisfare per essere conformi. Per altre informazioni sui criteri di conformità, vedere Criteri di conformità.

Team centrale

Il team centrale deve creare criteri di conformità comuni tra cui gli amministratori locali possono scegliere e solo, se necessario, creare criteri di eccezione. Per altre informazioni, vedere Criteri di conformità. La creazione di criteri include la creazione di script di criteri di conformità personalizzati perché sono soggetti alla stessa scala dei normali criteri di conformità.

Per altre informazioni su come creare criteri di conformità, vedere Criteri di conformità.

Amministratori locali

Fornire agli amministratori locali le autorizzazioni di lettura e assegnazione, ma non creare, aggiornare o eliminare le autorizzazioni per i criteri di conformità. Le autorizzazioni di lettura e assegnazione consentono loro di scegliere tra i criteri di conformità comuni creati dal team centrale e assegnarli agli utenti e ai dispositivi.

Configurazione delle periferiche

Contenuto della sezione:

  • Restrizioni dei dispositivi e configurazione generale
  • Accesso alle risorse
  • Anelli di Windows Update
  • Aggiornamenti delle funzionalità
  • Aggiornamenti della qualità

Restrizioni dei dispositivi e configurazione generale

  • Concedere agli amministratori locali l'autorizzazione per creare, aggiornare ed eliminare all'interno del proprio ambito.

  • Usare il Catalogo impostazioni e le baseline di sicurezza nella misura massima possibile, anziché i profili creati nell'elenco Profili di configurazione, per ridurre la scalabilità nell'interfaccia di amministrazione Microsoft Intune.

  • In generale, il team centrale deve provare a monitorare centralmente il contenuto delle configurazioni e sostituire molti profili duplicati, ove possibile, con un profilo condiviso.

Accesso alle risorse

È consigliabile usare il modello di delega completa .

Anelli di Windows Update

  • È consigliabile gestire gli anelli di aggiornamento di Windows in modo centralizzato. Il team centrale deve creare tutti i criteri anello di Windows update comuni necessari per supportare la varianza degli amministratori locali.
  • Gli amministratori locali non devono creare anelli di aggiornamento di Windows personalizzati. Quando si delega a un numero elevato di amministratori, il numero totale di oggetti può diventare di grandi dimensioni e difficile da gestire. Le procedure consigliate variano per ogni funzionalità. Per altre informazioni, vedere Anelli di windows update.

Aggiornamenti delle funzionalità

È consigliabile usare il modello di delega completa .

Aggiornamenti della qualità

È consigliabile usare il modello di delega completa .

Certificati

  • È consigliabile usare le autorizzazioni tramite il team centrale per eseguire l'onboarding/offboard dei connettori in base alle esigenze. Eseguire l'onboarding dei connettori per ogni amministratore locale per supportare il rilascio di certificati.

  • Non concedere agli amministratori locali l'autorizzazione per i connettori UPDATE o DELETE.

Applicazioni

Concedere agli amministratori locali le autorizzazioni complete per gestire le app nella misura dell'ambito.

Contenuto della sezione:

  • Apple Volume Purchase Program

  • Windows

  • Android

Per altre informazioni, vedere Gestire le app.

Apple Volume Purchase Program

Attualmente, non esistono problemi di scalabilità per il numero supportato di token volume purchase program. Per altre informazioni, vedere Il numero di token che è possibile caricare.

Windows

Android

  • Gli amministratori locali devono scegliere tra app dello Store esistenti o chiedere al team centrale di aggiungere nuove app di Android Store. Gli amministratori locali non devono creare nuove app per Android Store. Il numero totale di oggetti può diventare grande e difficile da gestire.

  • Gli amministratori locali possono creare app line-of-business Android, se necessario, entro il limite multipiattaforma, line-of-business e collegamento Web.

  • Il team centrale deve aggiungere app Google Play gestite.

    • Il team centrale può visualizzare solo le app Google Play gestite disponibili nel paese/area geografica del tenant. Se il team centrale ha bisogno di un'app Google Play gestita disponibile solo in alcuni paesi o aree geografiche, potrebbe essere necessario collaborare con lo sviluppatore dell'app per visualizzarla correttamente.
    • Il team centrale deve gestire tutti i contenuti correlati alle app Google Play gestite, tra cui app private, app Web e raccolte. Ad esempio, se un cliente prevede di usare l'iframe Google Play gestito per pubblicare app private, deve farlo con un singolo account per sviluppatore di proprietà del team centrale.
    • Il team centrale può selezionare un singolo tag di ambito come tag di ambito Google Play gestito. Ha un elenco a discesa speciale nella pagina del connettore Google Play gestito. Il tag di ambito si applica a tutte le app Google Play gestite dopo che il team centrale le aggiunge alla console, ma non si applica retroattivamente alle app che sono già state aggiunte. È consigliabile che il team centrale imposti il tag di ambito prima di aggiungere app e quindi assegnare a ogni team di area il tag di ambito. In caso contrario, gli amministratori regionali potrebbero non essere in grado di visualizzare le app Google Play gestite.
  • Per ogni dispositivo è supportato un solo criterio OEMConfig, ad eccezione dei dispositivi Zebra. Con i dispositivi Zebra, è consigliabile avere il minor numero di criteri possibile perché il tempo necessario per applicare i criteri è aggiuntivo. Ad esempio, se si assegnano sei criteri con il presupposto che si sovrappongano l'uno all'altro, è necessario circa 6 volte più tempo per iniziare a lavorare sul dispositivo rispetto a un singolo criterio.

Nota

Prestare estrema attenzione e cautela quando si imposta la modalità di aggiornamento con priorità elevata in molte app e gruppi diversi. Questo è per diversi motivi:

  • Anche se molte app possono essere impostate sulla modalità ad alta priorità, è possibile installare un solo aggiornamento dell'app alla volta. Un aggiornamento di app di grandi dimensioni potrebbe potenzialmente bloccare molti aggiornamenti più piccoli fino a quando l'installazione dell'app di grandi dimensioni non viene completata.
  • A seconda di quando le app rilasciano nuovi aggiornamenti, potrebbe verificarsi un picco improvviso nell'utilizzo della rete se le versioni dell'app coincidono. Se Wi-Fi non è disponibile in alcuni dispositivi, potrebbe verificarsi anche un picco nell'utilizzo della rete cellulare.
  • Anche se le esperienze utente con interruzioni sono già state menzionate, il problema aumenta man mano che un numero maggiore di app è impostato sulla modalità di aggiornamento ad alta priorità.

Per altre informazioni sui problemi di scalabilità relativi agli aggiornamenti delle app Google Play gestite tramite la modalità di aggiornamento ad alta priorità, vedere questo articolo Techcommunity.

Profili di registrazione

Contenuto della sezione:

  • Autopilot
  • Pagina dello stato della registrazione (ESP)
  • Apple Business Manager (ABM)
  • Profili Android Enterprise
  • Restrizioni di registrazione
  • Categorie di dispositivi

Autopilot

  • Concedere agli amministratori locali le autorizzazioni per leggere i dispositivi Autopilot e caricare nuovi dispositivi Autopilot.
  • Gli amministratori locali non devono creare profili Autopilot. Quando si delega a un numero elevato di amministratori, il numero totale di oggetti può diventare di grandi dimensioni e difficile da gestire. La procedura consigliata varia in base all'area di funzionalità. Per altre informazioni su Autopilot, vedere Usare Autopilot per registrare i dispositivi Windows in Intune.

Pagina di stato della registrazione

  • Gli amministratori locali devono selezionare i profili della pagina stato di registrazione esistenti da assegnare oppure devono richiedere al team centrale di creare un profilo di eccezione, solo se necessario.
  • Gli amministratori locali non devono creare profili di pagina di stato della registrazione. Quando si delega a un numero elevato di amministratori, il numero totale di oggetti può diventare di grandi dimensioni e difficile da gestire. La procedura consigliata varia in base all'area di funzionalità. Per informazioni sulla pagina Stato registrazione, vedere Configurare la pagina Stato registrazione.

Apple Business Manager

Se possibile, agli amministratori locali non devono essere concesse autorizzazioni di creazione, aggiornamento o eliminazione per i profili di registrazione. Se agli amministratori locali vengono concesse le autorizzazioni per creare profili Apple Business Manager, vengono concesse anche autorizzazioni per la creazione, l'aggiornamento e l'eliminazione in Autopilot. Tuttavia, gli amministratori locali non devono creare profili Autopilot.

Quando si delega a un numero elevato di amministratori, il numero totale di oggetti può diventare di grandi dimensioni e difficile da gestire. La procedura consigliata varia in base all'area di funzionalità. Per altre informazioni, vedere Usare Apple Business Manager per registrare i dispositivi Apple in Intune.

Profili Android Enterprise

  • Il team centrale deve creare profili di registrazione dei dispositivi dedicati di proprietà dell'azienda Android Enterprise per ogni amministratore locale per il raggruppamento dei dispositivi.
  • Se possibile, agli amministratori locali non devono essere concesse autorizzazioni di creazione, aggiornamento o eliminazione nei dispositivi Android Enterprise. Queste restrizioni impediscono agli amministratori locali di modificare le impostazioni Android Enterprise a livello di tenant e il profilo di registrazione globale completamente gestito.

Restrizioni di registrazione

  • Lo stesso set di autorizzazioni regola sia la configurazione del dispositivo che le restrizioni di registrazione. Quando si concedono le autorizzazioni per la creazione per la configurazione del dispositivo, si concedono anche le autorizzazioni per la creazione per le restrizioni di registrazione. Tuttavia, agli amministratori locali non deve essere concessa l'autorizzazione per creare profili di restrizione della registrazione. È quindi necessario che venga loro richiesto di non creare nuovi profili di restrizioni di registrazione.

  • Le restrizioni relative ai limiti dei dispositivi di registrazione definiscono il numero di dispositivi che ogni utente può registrare. Le restrizioni sui limiti dei dispositivi di registrazione devono coprire tutti i possibili limiti dei dispositivi per gli amministratori locali da condividere. Per altre informazioni, vedere Limitazioni della registrazione.

  • Il team centrale deve standardizzare il più possibile le restrizioni relative al tipo di dispositivo e aggiungere nuove restrizioni, ma solo come eccezioni speciali dopo che un amministratore locale ha esaminato le restrizioni esistenti.

Categorie di dispositivi

La funzionalità Categorie di dispositivi(categorie dispositivi>) non ha una famiglia di autorizzazioni specifica. Le relative autorizzazioni sono invece regolate dalle autorizzazioni impostate in Organizzazione. Passare a Ruoli di amministrazione > tenant. Selezionare un ruolo personalizzato o predefinito e selezionare Proprietà. Qui è possibile assegnare le autorizzazioni, una delle quali è Organizzazione. Quindi, se sono necessarie autorizzazioni di lettura per le categorie di dispositivi, impostare le autorizzazioni di lettura in Organizzazione.

I team centrali possono creare categorie di dispositivi. Tuttavia, agli amministratori locali non dovrebbe essere consentito creare, aggiornare o eliminare categorie di dispositivi, in quanto richiederebbe la concessione delle autorizzazioni per l'organizzazione, concedendole l'accesso ad altre funzionalità a livello di tenant regolate dalle autorizzazioni dell'organizzazione.

Per altre informazioni, vedere Categorie di dispositivi.

Analisi degli endpoint

  • Il team centrale deve creare il numero di baseline comuni di Endpoint Analytics necessarie per supportare la varianza degli amministratori locali.
  • Se possibile, gli amministratori locali non devono creare baseline di Endpoint Analytics personalizzate. Quando si delega a un numero elevato di amministratori, il numero totale di oggetti può diventare di grandi dimensioni e difficile da gestire. La procedura consigliata varia in base all'area di funzionalità.
  • Per altre informazioni, vedere Configurazione delle impostazioni in Endpoint Analytics.