Condividi tramite

Pianificazione dell'implementazione di Power BI: amministrazione del tenant

  • Articolo

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sull'esperienza Power BI in Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo presenta considerazioni chiave per l'amministrazione di un tenant di Fabric. Questo articolo è destinato a:

  • Amministratori Fabric: amministratori responsabili della supervisione Fabric nell'organizzazione.
  • Amministratori IT e di sistema: altri amministratori che collaborano con gli amministratori dell'infrastruttura per supervisionare e integrare i sistemi all'interno dell'organizzazione.
  • Centro di eccellenza (COE) e team di BI: i team responsabili della supervisione di Power BI e del supporto degli utenti di Power BI nell'organizzazione. Questi team prendono decisioni chiave e collaborano con gli amministratori di Fabric.

La gestione del servizio Power BI è un aspetto fondamentale della supervisione del sistema. Per altre informazioni, vedere Supervisione del sistema. Le attività di routine associate alla supervisione del sistema sono comunemente note come amministrazione del sistema. Le attività di amministrazione del sistema sono fondamentali per garantire che i consumer di contenuti e gli autori di contenuti abbiano costantemente un'esperienza ottimale con Power BI.

Come descritto nell'articolo Livelli di maturità per l'adozione dell'infrastruttura, l'adozione dell'organizzazione si riferisce all'efficacia delle procedure di governance e gestione dei dati per supportare e abilitare business intelligence aziendale e business intelligence self-service gestita. Pertanto, gli amministratori che gestiscono analisi e piattaforme di business intelligence possono avere un'influenza diretta e ridimensionabile sul successo delle attività di adozione analitica.

Nota

L'amministrazione della capacità dell'infrastruttura (o capacità Premium) e la gestione del servizio Power BI sono concetti diversi. Sebbene la maggior parte delle organizzazioni disponga di un solo tenant di Power BI, un'organizzazione può effettuare il provisioning di più capacità per carichi di lavoro o business unit diversi.

Importante

A volte questo articolo si riferisce a Power BI Premium o alle relative sottoscrizioni di capacità (SKU P). Tenere presente che Microsoft sta attualmente consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti devono invece prendere in considerazione l'acquisto di sottoscrizioni con capacità Fabric (SKU F).

Per altre informazioni, vedere Aggiornamento importante disponibile per le licenze Power BI Premium e Domande frequenti su Power BI Premium.

Definire l'ambito delle responsabilità

Non esiste una singola definizione del ruolo di amministratore dell'infrastruttura, ovvero il ruolo e le responsabilità di routine di un amministratore di Fabric possono variare tra organizzazioni diverse. Ciò che non dovrebbe variare è che il ruolo può e dovrebbe evolversi nel tempo man mano che cambiano priorità e obiettivi dell'organizzazione.

Dal punto di vista strategico, un amministratore dell'infrastruttura deve concentrarsi su:

  • Governance: applicazione di linee guida e criteri di governance per supportare business intelligence aziendale e business intelligence self-service gestita.
  • Responsabilizzazione degli utenti: facilitare e supportare i processi e i sistemi interni che consentono alla community degli utenti interni laddove possibile, rispettando al tempo stesso le normative e i requisiti dell'organizzazione.
  • Adozione: consentire un'adozione più ampia di Fabric da parte dell'organizzazione con procedure efficaci di governance e gestione dei dati.

Il tentativo di bilanciare la governance, la responsabilizzazione degli utenti e gli obiettivi di adozione comportano intrinsecamente priorità concorrenti. Idealmente, questo conduce a dibattiti produttivi sulle priorità. Chiarire e comunicare le aspettative per vari ruoli e responsabilità può aiutare a evitare livelli inaccettabili di attrito e conflitto.

Si considerino i tre esempi seguenti di amministratori dell'infrastruttura.

  • Alta attenzione all'abilitazione degli utenti: Riley è un amministratore dell'infrastruttura che lavora per un'organizzazione globale di grandi dimensioni che ha effettuato investimenti significativi in business intelligence self-service gestita. Per abilitare le funzionalità di business intelligence self-service per gli utenti in tutta l'organizzazione, Riley dedica molto tempo a coordinare decisioni e azioni con il Center of Excellence (COE) e altri amministratori. Quando necessario, Riley esegue i passaggi per supportare le soluzioni BI esistenti.
  • Alta attenzione alla governance e alla conformità: Parker è un amministratore dell'infrastruttura che lavora per un'organizzazione altamente regolamentata. In questa organizzazione la maggior parte dello sviluppo bi viene gestita dagli sviluppatori di business intelligence all'interno di un team di business intelligence aziendale centralizzato. Le responsabilità amministrative di Parker sono principalmente incentrate su aree come il controllo, la protezione delle informazioni e la sicurezza.
  • Coinvolgimento elevato nella creazione di contenuti: Morgan è un amministratore dell'infrastruttura che lavora per una piccola organizzazione che inizia a creare la propria cultura dei dati. Attualmente, l'organizzazione ha solo pochi creatori di contenuti. Oltre alle responsabilità di supervisione del sistema, Morgan è uno sviluppatore di business intelligence che crea e pubblica regolarmente contenuti. In alcuni casi, Morgan viene coinvolto in un progetto di co-sviluppo per fungere da mentore di un collega, aiutando a sviluppare le competenze di business intelligence nell'organizzazione.

Elenco di controllo: quando si pianifica l'ambito delle responsabilità, le decisioni chiave e le azioni includono:

  • Decidere l'obiettivo strategico: determinare quale deve essere l'obiettivo strategico per gli amministratori dell'infrastruttura. Ottenere chiarezza sugli obiettivi e sulle priorità da usare quando è necessario prendere decisioni (e compromessi).
  • Identificare ruoli e responsabilità specifici: determinare quali sono le aspettative specifiche per gli amministratori di Fabric. Documentare chiaramente i ruoli e le responsabilità e aggiornare le descrizioni dei processi con le risorse umane, se appropriato.

Nominare amministratori

Le azioni di un amministratore dell'infrastruttura hanno un impatto significativo sull'esperienza utente, sulle attività di cultura dei dati, sulle attività di governance, sui proprietari e sulla gestione dei contenuti e sulle attività di adozione dell'organizzazione. Quindi, è fondamentale nominare le persone giuste per i ruoli di amministratore.

Ecco alcuni punti chiave da considerare quando si selezionano gli amministratori.

  • Rimanere consapevoli della natura altamente privilegiata del ruolo. Un ruolo di amministratore è un ruolo con privilegi elevati perché è autorizzato a gestire un'ampia gamma di impostazioni del tenant, l'accesso all'area di lavoro, l'accesso all'area di lavoro personale e può visualizzare tutti i metadati del tenant. Per altre informazioni, vedere Amministrazione di Power BI.
  • Selezionare attentamente chi è adatto per essere un amministratore. Un amministratore deve spesso collaborare con gli utenti e il COE. Per questo motivo, devono comprendere i concetti di Business Intelligence e gli obiettivi che gli utenti vogliono eseguire. Qualcuno che ha una personalità eccessiva o che ha la tendenza a limitare rigorosamente ciò che gli utenti sono autorizzati a fare probabilmente non è adatto per gestire una piattaforma DI BI self-service.
  • Scegliere da 2 a 4 amministratori. Poiché si tratta di un ruolo con privilegi elevati, nominare solo alcuni amministratori. Trovare il giusto equilibrio: la presenza di troppi amministratori aumenta il rischio di modifiche non approvati, mentre la presenza di troppi amministratori aumenta il rischio che il sistema non sia sufficientemente supportato.
  • Consentire amministratori occasionali. Se si hanno utenti che occasionalmente necessitano dei diritti di amministratore di Fabric, è consigliabile implementare Privileged Identity Management (PIM). PIM consente di assegnare autorizzazioni di ruolo just-in-time che scadono dopo alcune ore. Questo processo offre un modo utile per bilanciare il rischio (di avere troppi amministratori a tempo pieno) rispetto all'usabilità (consentendo lo stato di avanzamento). Questo è particolarmente vero nelle organizzazioni più grandi e decentralizzate. Quando si usa PIM, la delega del ruolo di amministratore viene registrata e può facoltativamente coinvolgere un flusso di lavoro di approvazione per concedere i diritti.
  • Rendere l'amministrazione dell'infrastruttura una priorità. Spesso, l'amministrazione di una piattaforma BI è solo una delle molte responsabilità. Valutare come assicurarsi che gli utenti siano ben supportati e che il sistema sia sufficientemente gestito.
  • Esaminare regolarmente chi è assegnato a tutti i ruoli correlati. Sono disponibili tre ruoli autorizzati a gestire il servizio Power BI: amministratore di Fabric e amministratore di Power Platform. È importante controllare regolarmente l'appartenenza a questi ruoli.

Per ulteriori informazioni, vedi Informazioni sui ruoli amministratore nell'interfaccia di amministrazione di Microsoft 365.

Elenco di controllo: quando si nominano amministratori, le decisioni chiave e le azioni includono:

  • Identificare gli amministratori correnti dell'infrastruttura: verificare chi è attualmente assegnato al ruolo di amministratore di Fabric. Considerare anche i ruoli di amministratore di Power Platform e amministratore globale in questa revisione.
  • Nomina amministratori infrastruttura: per ridurre i rischi, nominare 2-4 persone al ruolo di amministratore dell'infrastruttura. Se sono attualmente assegnate più di quattro persone, ridurre il numero di persone assegnate al ruolo di amministratore dell'infrastruttura.
  • Usare PIM per amministratori occasionali: identificare se si dispone di persone che sono legittime, ma occasionalmente, hanno bisogno dei diritti di amministratore di Fabric. Implementare PIM per assegnare autorizzazioni di ruolo JUST-In-Time che scadono dopo alcune ore. Documentare e comunicare il funzionamento del processo, che può includere un flusso di lavoro di approvazione.
  • Assegnare i backup ed eseguire il training incrociato: controllare lo stato del training incrociato e della documentazione che è disponibile per la gestione delle responsabilità di amministrazione dell'infrastruttura. Assicurarsi che venga eseguito il training di una persona di backup in modo che gli utenti con priorità possano essere soddisfatti in modo tempestivo e coerente.
  • Controllare regolarmente gli amministratori: verificare gli utenti assegnati al ruolo di amministratore dell'infrastruttura a intervalli regolari.

Collaborare con altri amministratori

Anche se l'amministratore di Fabric è un ruolo con privilegi elevati, è limitato alla gestione di Fabric. Pertanto, a volte sarà necessario collaborare con altri amministratori.

Ecco alcuni motivi comuni per cui un amministratore di Fabric collabora con altri amministratori di sistema.

  • Installazione e installazioni dei dispositivi: potrebbe essere necessario collaborare con l'IT, un team di infrastruttura o un team di supporto desktop per installare, aggiornare o gestire i dispositivi utente.
  • Abbonamenti e acquisti di licenze: il ruolo di amministratore fatturazione in Microsoft 365 è necessario per gestire le sottoscrizioni e le licenze di acquisto. Un amministratore della fatturazione potrebbe anche essere responsabile dell'analisi e della gestione dei costi. Per altre informazioni sui modi centralizzati e decentralizzati (self-service) per gestire le licenze, vedere Licenze utente.
  • Assegnazione di licenze e gestione utenti: il ruolo di amministratore della licenza in Microsoft 365 è necessario per assegnare licenze (acquistate) a utenti specifici. Il ruolo di amministratore utente è necessario per gestire le proprietà di un utente. È utile collaborare con un amministratore utente quando si prevede di implementare l'automazione in base alle proprietà utente, ad esempio l'assegnazione automatica delle licenze o l'assegnazione automatica dei gruppi. Per altre informazioni, vedere Ruoli dell'interfaccia di amministrazione di Microsoft 365 comunemente usati.
  • Amministratori di Microsoft Entra: esistono diversi motivi per cui è necessario collaborare con gli amministratori di Microsoft Entra. Spesso, i motivi includono la necessità di configurare o gestire utenti, gruppi ed entità servizio. Per altre informazioni, vedere Pianificazione della sicurezza a livello di tenant.
  • Accesso ai dati di origine: potrebbe essere necessario collaborare con un amministratore di sistema o un amministratore del database per ottenere l'accesso ai dati per conto degli autori di contenuti. In alcuni casi, potrebbe anche essere necessario richiedere l'accesso per conto dei consumer di contenuti quando i modelli semantici applicano la sicurezza dei dati in base all'identità dei consumer di contenuti.
  • Prevenzione della perdita dei dati e classificazione dei dati: potrebbe essere necessario collaborare con l'amministratore di Microsoft Purview per la governance e la protezione delle informazioni.
  • Integrazione di Teams: quando si integra Power BI con Microsoft Teams, potrebbe essere necessario collaborare con un amministratore di Teams.
  • Integrazione di OneDrive e SharePoint: quando si integra Power BI con OneDrive o SharePoint, potrebbe essere necessario collaborare con altri amministratori.
  • Amministrazione dell'area di lavoro: potrebbe essere necessario collaborare con un amministratore dell'area di lavoro Fabric per pianificare, organizzare o proteggere il contenuto all'interno di aree di lavoro specifiche.
  • Gestione del ciclo di vita: quando si distribuiscono e si gestiscono le modifiche al contenuto, potrebbe essere necessario collaborare con un amministratore della pipeline di distribuzione o un amministratore di Azure DevOps.
  • Gestione della capacità Premium: potrebbe essere necessario collaborare con un amministratore della capacità quando si gestisce una capacità Premium.
  • Gestione del gateway dati: potrebbe essere necessario collaborare con un amministratore del gateway per gestire e proteggere un gateway dati locale. Per altre informazioni, vedere Gestire i gateway.
  • Amministrazione di Power Platform: potrebbe essere necessario integrare soluzioni tra Power BI e altre app power platform, ad esempio Power Automate o Power Apps.
  • Amministrazione di Azure: potrebbe essere necessario collaborare con un amministratore di Azure per configurare, accedere e proteggere altri servizi di Azure da integrare con Power BI.
  • Amministrazione e controllo della sicurezza: l'organizzazione potrebbe avere requisiti specifici di conformità, sicurezza o privacy. In questo caso, potrebbe essere necessario collaborare con il team di sicurezza per identificare e mitigare i rischi.
  • Rete: quando ci si connette a origini dati e sistemi diversi, potrebbe essere necessario collaborare con gli amministratori di rete per motivi di prestazioni e sicurezza.
  • Amministrazione dei dispositivi mobili: potrebbe essere necessario collaborare con un amministratore di Intune per gestire i criteri e la sicurezza dei dispositivi mobili.

Importante

Un amministratore dell'infrastruttura non deve prendere decisioni o intervenire autonomamente, ad esempio modificando le impostazioni del tenant. Tutte le decisioni chiave devono essere discusse, pianificate e documentate. Oltre a collaborare con altri amministratori, assicurarsi di coinvolgere completamente il COE e il team di lavoro della strategia BI. Potrebbe anche essere opportuno coinvolgere lo sponsor esecutivo per le decisioni strategiche.

Elenco di controllo: quando si collabora con altri amministratori, le decisioni chiave e le azioni includono:

  • Determinare chi gestirà la configurazione e le installazioni dei dispositivi: assicurarsi di conoscere chi gestisce i dispositivi per l'organizzazione. Acquisire familiarità con i relativi processi e requisiti. Essere pronti a utilizzarli in base alle esigenze.
  • Identificare chi gestirà le sottoscrizioni e le licenze: assicurarsi di conoscere chi gestisce le sottoscrizioni e le licenze per l'organizzazione. Acquisire familiarità con i relativi processi e requisiti. Essere pronti a utilizzarli in base alle esigenze.
  • Identificare chi assegnerà licenze e gestirà utenti, gruppi e entità servizio: assicurarsi di conoscere gli utenti, i gruppi e le entità servizio per l'organizzazione. Acquisire familiarità con i relativi processi e requisiti. Essere pronti a utilizzarli in base alle esigenze.
  • Determinare eventuali altri amministratori da consultare: durante il processo di pianificazione dell'implementazione, identificare altri amministratori pertinenti. Invitarli a riunioni pertinenti e coinvolgerli nei processi decisionali pertinenti. Aggiornare la documentazione e i processi in base alle esigenze.

Gestire il servizio Power BI

La governance e la gestione del servizio Power BI è una delle principali responsabilità di un amministratore di Fabric. Questa sezione descrive come gestire e gestire molte impostazioni e funzionalità comuni nel portale di amministrazione di Fabric.

Gestire le impostazioni del tenant

Le impostazioni del tenant sono il modo principale per controllare quali funzionalità e funzionalità di Power BI sono abilitate e per quali utenti dell'organizzazione. La gestione delle impostazioni del tenant è una delle responsabilità più importanti per un amministratore dell'infrastruttura.

Poiché gli autori di contenuti e i consumer di contenuti possono facilmente ottenere informazioni sulle funzionalità disponibili in Power BI (dalla documentazione), può comportare frustrazioni quando non possono eseguire operazioni previste. Può anche causare insoddisfazioni degli utenti e un'adozione meno efficace da parte dell'organizzazione, da parte degli utenti e l'adozione di soluzioni.

Ecco alcune domande comuni poste dagli utenti confusi e frustrati.

  • Perché non è possibile creare un'area di lavoro?
  • Perché non è possibile esportare i dati?
  • Perché l'oggetto visivo personalizzato non funziona?
  • Perché non è possibile certificare un modello semantico?
  • Perché non è possibile assegnare un'etichetta di riservatezza?
  • Perché non è possibile eseguire il push di un'app a utenti finali specifici?

Importante

Ogni impostazione del tenant deve essere allineata alle linee guida e ai criteri di governance dell'organizzazione. Quando un amministratore di Fabric decide autonomamente di abilitare o disabilitare le impostazioni, in genere è un indicatore chiaro che è necessario migliorare e perfezionare i processi di governance.

Nella parte restante di questa sezione viene descritto il processo seguente per gestire le impostazioni del tenant.

  1. Esaminare le impostazioni del tenant
  2. Decidere le impostazioni del tenant
  3. Aggiornare le impostazioni del tenant
  4. Impostazioni del tenant del documento
  5. Gestire impostazioni tenant
  6. Controllare le impostazioni del tenant

Passaggio 1: Esaminare le impostazioni del tenant

È importante esaminare ogni impostazione del tenant per comprendere chiaramente lo stato corrente del tenant. Anche se è consigliabile esaminare tutte le impostazioni del tenant, è possibile classificare in ordine di priorità impostazioni critiche specifiche da esaminare prima in base a una valutazione dei rischi.

Ecco alcuni fattori da considerare durante il processo di revisione.

  • Impostazione: l'impostazione del tenant specifica è attualmente abilitata o disabilitata?
  • Autorizzazioni: l'impostazione del tenant specifica è applicabile all'intera organizzazione? Oppure è disponibile o negato a gruppi di sicurezza specifici?

Nota

Alcune impostazioni del tenant sono abilitate per impostazione predefinita, mentre altre sono disabilitate per impostazione predefinita.

È possibile compilare lo stato corrente delle impostazioni del tenant in uno dei due modi seguenti.

La tabella seguente illustra come registrare lo stato corrente delle impostazioni del tenant.

Data ultima revisione Impostazione del tenant Valore corrente Gruppi di sicurezza consentiti Gruppi di sicurezza non consentiti Impostazione del tenant delegata ad altri amministratori
15 ottobre 2023 Creare aree di lavoro Abilitato per gruppi di sicurezza specifici Autori di aree di lavoro di Power BI, amministratori di Power BI, COE di Power BI, supporto di Power BI N/D N/D
15 ottobre 2023 Esporta in Excel Abilitato per l'intera organizzazione, ad eccezione di gruppi di sicurezza specifici N/D Sales Team Europa N/D
1° novembre 2023 Usare modelli semantici tra aree di lavoro Abilitata per l'intera organizzazione N/D N/D N/D
1° novembre 2023 Certification Abilitato per gruppi di sicurezza specifici PMI di certificazione di Power BI N/D Gli amministratori di dominio possono abilitare/disabilitare
5 novembre 2023 Consenti a utenti specifici di attivare la condivisione dei dati esterni Abilitato per gruppi di sicurezza specifici Condivisione di dati esterni di Power BI N/D N/D

Per altre considerazioni sui gruppi di sicurezza, vedere Pianificazione dei gruppi di Power BI.

Per altre informazioni sugli stati di impostazione del tenant consentiti, vedere Come usare le impostazioni del tenant.

Attenzione

A volte quando un amministratore monitora il tenant, individua una situazione che non è ideale. Ad esempio, potrebbero visualizzare troppe esportazioni di dati nei dati dell'attività utente. In questo caso, l'amministratore potrebbe essere tentato di disabilitare l'impostazione del tenant correlata. Tuttavia, prima di disabilitare completamente una funzionalità, è importante comprendere innanzitutto perché gli utenti si basano su determinate tecniche. Ciò è dovuto al fatto che la proibizione delle funzionalità può causare frustrazioni degli utenti che possono tentare agli utenti di creare soluzioni alternative. Considerare invece che una soluzione potrebbe dover essere riprogettata o forse un'ulteriore formazione e training degli utenti potrebbe attenuare le preoccupazioni.

Passaggio 2: Decidere le impostazioni del tenant

Dopo aver esaminato le impostazioni correnti del tenant, è possibile esaminare il processo decisionale. Per ogni impostazione del tenant, usare workshop per discutere attivamente e determinare quali funzionalità e funzionalità devono essere consentite o non consentite e per quali utenti.

Tenere presente che ogni impostazione del tenant rappresenta una decisione di governance. Pertanto, prevedere di collaborare con altri per arrivare alla decisione giusta. A seconda delle circostanze, il processo decisionale potrebbe comportare la collaborazione con COE, sponsor esecutivo, team di sicurezza, team di BI o altri (ad esempio stakeholder o promotori).

Suggerimento

Una delle principali sfide consiste nel decidere cosa fare quando si verificano incoerenze tra un'impostazione del tenant esistente e gli obiettivi e le decisioni intenzionali. Prepararsi a risolvere questi conflitti quando emergono.

Ecco alcuni fattori da considerare durante il processo decisionale.

  • Quali decisioni di governance sono già in essere? Quando possibile, fare riferimento alle decisioni esistenti prese. Mirare sempre a essere coerenti ed efficienti. Inoltre, è necessario essere consapevoli dei requisiti di conformità interni o esterni. Se applicabile, le impostazioni del tenant devono essere allineate ai criteri di governance più ampi. Ad esempio, potrebbe esserci un criterio di governance corrente che specifica quando, chi e come condividere i dati all'esterno dell'organizzazione.
  • Chi prende nuove decisioni di governance? Quando è necessario prendere una decisione sull'impostazione di un tenant, coinvolgere tutte le parti pertinenti nella conversazione. In genere, gli amministratori di Infrastruttura da soli non sono nella posizione migliore per prendere decisioni sulle impostazioni del tenant. Per informazioni sull'assemblaggio di un team di lavoro e sull'esecuzione di workshop, vedere Pianificazione di business intelligence strategica.
  • La decisione è temporanea? In alcuni casi, un'impostazione del tenant viene impostata solo per un breve periodo di tempo. In genere, questa operazione viene eseguita per consentire ai team IT, BI e COE di acquisire familiarità con una nuova funzionalità prima che venga rilasciata in modo più ampio in tutta l'organizzazione. In questo modo, è possibile verificare l'allineamento con le linee guida di governance e la community degli utenti sarà ben supportata.
  • Le business unit o i team diversi verranno gestiti in modo diverso? Nelle organizzazioni di grandi dimensioni, un unico approccio funziona raramente. Per soddisfare le esigenze e le competenze di team diversi, a volte potrebbe essere necessario configurare le impostazioni del tenant in modo diverso per gruppi di destinatari diversi. Mirare sempre a consentire ai team capaci di operare con la massima flessibilità possibile, entro le linee guida per la governance.
  • Esiste un processo di approvazione? A seconda dell'oggetto specifico, potrebbe essere necessaria l'approvazione. Ciò vale soprattutto quando un'impostazione del tenant è correlata alla sicurezza o alla conformità.
  • Qual è la pianificazione per rivalutare ogni decisione? Pianificare regolarmente una verifica di ogni decisione dell'impostazione del tenant. Due volte all'anno è un buon programma per questo scopo.

La tabella seguente illustra come registrare le decisioni.

Data della decisione Decisione presa Responsabili delle decisioni coinvolti Decisione approvata da Impostazione del tenant interessata Azione in sospeso
15 ottobre 2023 Il COE eseguirà il training degli autori di contenuti approvati sulle procedure consigliate per la creazione e la gestione delle aree di lavoro. Gli autori approvati possono appartenere a qualsiasi business unit. COE e stakeholder Ellis Turner (sponsor esecutivo) e Taylor Phillips (COE lead) Creare aree di lavoro Esaminare i membri esistenti del gruppo creatori di aree di lavoro di Power BI
15 ottobre 2023 L'esportazione in Excel sarà consentita. Il COE monitorerà l'azione nel log attività e contatterà gli utenti che lo tengono in uso. Esiste una limitazione temporanea per sales team-Europe a causa di un problema attualmente sottoposto a indagine. COE e sicurezza Ellis Turner (sponsor esecutivo) e Jessie Irwin (Chief Technology Officer) Esporta in Excel Completare il problema dell'Europa in 60 giorni
1° novembre 2023 È consigliabile usare modelli semantici condivisi per incoraggiare il riutilizzo dei dati, ridurre al minimo i silo di dati e ridurre la duplicazione dei dati. COE Ellis Turner (sponsor esecutivo) Usare modelli semantici tra aree di lavoro N/D
1° novembre 2023 Il COE eseguirà il training degli autori di contenuti approvati sul processo e sui requisiti per la certificazione di report e asset di dati. Gli autori approvati possono appartenere a qualsiasi business unit. COE e stakeholder Ellis Turner (sponsor esecutivo) e Taylor Phillips (COE lead) Certification Esaminare i membri esistenti del gruppo PMI di certificazione Power BI
5 novembre 2023 I criteri di condivisione dei dati dell'organizzazione illustrano come i dati possono essere condivisi all'esterno dell'organizzazione. Tutti gli utenti devono esaminare e confermare questo criterio ogni anno. Il training del COE consentirà agli utenti di conformarsi durante l'uso in Power BI. COE, sicurezza e conformità Jessie Irwin (Chief Technology Officer) Consenti a utenti specifici di attivare la condivisione dei dati esterni Esaminare i membri esistenti del gruppo di condivisione dati esterni di Power BI

Prendere in considerazione l'inclusione di altre informazioni contestuali che spiegano il motivo per cui è stata presa una decisione. Includere anche collegamenti alla posizione di documenti o criteri correlati esistenti.

Nota

Gli esempi presentati nella tabella illustrano intenzionalmente come bilanciare la responsabilizzazione, la conformità e i requisiti interni degli utenti. Per altre considerazioni, vedere Governance.

Passaggio 3: Aggiornare le impostazioni del tenant

Ora che sono disponibili le impostazioni del tenant e le decisioni intenzionali esistenti, è possibile aggiornare le impostazioni del tenant.

Le considerazioni durante il processo di aggiornamento includono:

  • Chi gestirà l'aggiornamento? Se si dispone di più amministratori di Fabric, è consigliabile che uno o due amministratori di Fabric siano principalmente responsabili dell'aggiornamento delle impostazioni del tenant. L'obiettivo è garantire che il processo sia coerente, ben compreso e ben controllato.
  • Qual è il processo di test? A seconda dell'impostazione del tenant, potrebbero verificarsi altri effetti quando viene modificato. Eseguire test prima di apportare modifiche diffuse. Per un esempio, vedere Controllare l'uso di modelli semantici tra aree di lavoro.
  • Esiste un processodi gestione delle modifiche? Valutare come evitare discrepanze tra decisioni, documentazione e aggiornamenti risultanti. La comunicazione tra i team è un fattore chiave di successo nella gestione dei cambiamenti. A seconda dei requisiti di controllo, è possibile scegliere di gestire un log delle modifiche interno per tenere traccia di chi ha apportato la modifica, quando e perché (per registrare altri dettagli oltre a quanto acquisito nel log attività).
  • Come verranno gestite le comunicazioni con gli utenti? Quando si apporta una modifica che influisce sulle operazioni che gli utenti possono eseguire, assicurarsi di comunicarla. Mirare sempre a evitare la frustrazione dell'utente e le richieste di supporto non necessarie.

Passaggio 4: Documentare le impostazioni del tenant

A questo punto, assicurarsi di disporre di un metodo ripetibile per documentare i valori delle impostazioni del tenant. Per un esempio semplificato, vedere la tabella descritta nel passaggio 1 precedente, che riguarda la revisione delle impostazioni del tenant.

Ecco alcuni aspetti da considerare per la documentazione.

  • Estrarre i dati dello snapshot: quando si documentano i valori delle impostazioni del tenant, è consigliabile creare regolarmente un nuovo snapshot temporizzato. A questo scopo, la creazione di uno snapshot una volta alla settimana è una buona frequenza. Usare l'API REST Get Tenant Settings per automatizzare il processo.
  • Fornire l'accesso amministratore ai dati degli snapshot: gli amministratori, il COE e i revisori interni devono avere accesso a tutti i dati dello snapshot. Per identificare le impostazioni del tenant modificate, confrontare due snapshot, ad esempio questa settimana rispetto all'ultima settimana. I dati del log attività integrano i dati dello snapshot per fornire una comprensione completa delle modifiche apportate, quando e da chi. Per altre informazioni, vedere il passaggio 6 seguente, che riguarda il controllo delle impostazioni del tenant.
  • Fornire un riepilogo delle impostazioni correnti agli utenti: i valori delle impostazioni del tenant sono un tipo di documentazione che può essere resa disponibile per la community degli utenti nel portale centralizzato. È un riferimento utile per un utente che, ad esempio, non capisce perché una funzionalità non è disponibile. La documentazione può anche aiutare gli utenti a conoscere il gruppo di sicurezza da richiedere di partecipare a se vogliono usare una funzionalità. Per ridurre il livello di lavoro manuale, i risultati più recenti dello snapshot dell'API REST possono essere distribuiti agli utenti come report di Power BI. A seconda delle esigenze, potrebbe essere necessario unire lo snapshot dei dati con altri dati gestiti manualmente, ad esempio la descrizione dell'impostazione del tenant, la giustificazione per l'impostazione, i collegamenti a informazioni aggiuntive o il collegamento a un modulo per richiedere l'accesso.

Nota

Come descritto in precedenza nel passaggio 2, si avrà anche la documentazione relativa al processo decisionale. In genere, questo tipo di documentazione è disponibile solo per il COE e gli amministratori, anziché per tutti gli utenti di Power BI. Per un esempio semplificato, vedere il Passaggio 2.

Passaggio 5: Gestire le impostazioni del tenant

Le impostazioni del tenant richiedono attenzione su base continuativa. Ecco alcuni aspetti da considerare.

  • Nuove impostazioni del tenant: come si saprà quando è disponibile una nuova impostazione del tenant? Poiché Fabric è un servizio cloud che continua a evolversi, è possibile prevedere che vengano introdotte regolarmente nuove impostazioni del tenant. Un modo per conoscere le nuove impostazioni del tenant consiste nel visualizzare i messaggi annunciati nella parte superiore della pagina delle impostazioni del tenant nel portale di amministrazione. Un altro modo consiste nel confrontare i dati estratti dallo snapshot corrente con lo snapshot precedente (descritto in precedenza nel passaggio 4).
  • Modifiche alle impostazioni del tenant esistenti: come si saprà quando è cambiato il comportamento di un'impostazione del tenant esistente? Le modifiche alle impostazioni del tenant vengono in genere annunciate nel blog di Power BI o nel blog di Fabric. Assicurarsi di seguire questi blog per conoscere eventuali notifiche.
  • Richieste utente in corso: come gestire le richieste utente? Ad esempio, un utente che vuole certificare il contenuto sa inviare una richiesta per diventare membro di un gruppo di sicurezza specifico che lo consente. Si tratta di un flusso di lavoro efficace reso possibile pubblicando la documentazione delle impostazioni del tenant a cui gli utenti possono fare riferimento (come descritto nel passaggio 4 precedente). È possibile scegliere di usare un modulo per raccogliere questi tipi di richieste. In alternativa, è possibile instradare le richieste tramite l'help desk.
  • Nuovi gruppi di sicurezza: se un'impostazione del tenant deve essere limitata a gruppi di sicurezza specifici, esiste già un gruppo di sicurezza appropriato? È necessario creare un nuovo gruppo di sicurezza? Come si coordina la creazione di un nuovo gruppo di sicurezza quando necessario? Per altre informazioni, vedere Strategia per l'uso di gruppi.

Passaggio 6: Controllare le impostazioni del tenant

Infine, è importante avere un processo per controllare regolarmente le impostazioni del tenant. Ecco alcune azioni da identificare quando si controllano le impostazioni del tenant.

  • È stata modificata un'impostazione del tenant: cercare i valori modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Questa attività indica solo che è stato aggiornato un elemento (se è abilitato o disabilitato o sono stati assegnati gruppi di sicurezza diversi). Per comprendere le modifiche apportate, è necessario confrontare lo snapshot corrente con lo snapshot precedente (descritto in precedenza nel passaggio 4).
  • È stata introdotta una nuova impostazione del tenant: cercare i messaggi nel portale di amministrazione o confrontare i dati estratti dallo snapshot corrente con lo snapshot precedente (descritto in precedenza nel passaggio 4).
  • L'appartenenza a un gruppo è cambiata: in alcune situazioni, potrebbe non essere sufficiente sapere quale gruppo di sicurezza è assegnato. Potrebbe essere necessario determinare l'appartenenza al gruppo di sicurezza, che può includere singoli utenti ed entità servizio. È possibile usare Microsoft Graph per i dati di appartenenza ai gruppi di origine. Per altre informazioni, vedere Utenti e gruppi di dati.

È anche possibile ricevere notifiche di avviso quando un'impostazione del tenant è stata aggiornata. È possibile usare le funzionalità di avviso del log di controllo di Microsoft 365 o Microsoft Defender for Cloud Apps per ricevere una notifica quando un'impostazione del tenant è cambiata e da chi, usando l'evento del log di controllo UpdatedAdminFeatureSwitch. Per altre informazioni sull'abilitazione degli avvisi, vedere Controllo a livello di tenant.

Elenco di controllo: quando si pianificano e gestiscono le impostazioni del tenant, le decisioni chiave e le azioni includono:

  • Eseguire una verifica di tutte le impostazioni del tenant correnti: determinare lo stato corrente esaminando tutte le impostazioni del tenant. Identificare i gruppi di sicurezza assegnati a ogni impostazione.
  • Identificare i criteri e le decisioni esistenti: compilare i criteri di governance esistenti o le decisioni precedenti in modo che siano prontamente disponibili.
  • Discutere e decidere: pianificare workshop da considerare e determinare quali elementi devono essere consentiti o non consentiti e per quali utenti. Assicurarsi che tutte le decisioni siano allineate agli obiettivi della cultura dei dati, alle linee guida per la governance e ai criteri interni. Assicurarsi di coinvolgere tutti i responsabili decisionali e gli stakeholder pertinenti per ogni argomento. Ottenere un'approvazione aggiuntiva quando appropriato.
  • Creare una pianificazione per rivalutare le decisioni: configurare una pianificazione per rivalutare le decisioni e le impostazioni del tenant a intervalli regolari,ad esempio due volte all'anno.
  • Apportare aggiornamenti: aggiornare le impostazioni del tenant in base alle decisioni prese nei workshop.
  • Estrarre i dati degli snapshot con l'API: usare l'API REST Get Tenant Settings per rendere il processo più efficiente, automatizzando potenzialmente la creazione di snapshot in base a una pianificazione.
  • Creare la documentazione per gli utenti: creare la documentazione delle impostazioni del tenant per la community degli utenti. Pubblicare la documentazione nel portale centralizzato. Includere i gruppi di sicurezza a cui un utente deve appartenere per accedere a una funzionalità o a una funzionalità.
  • Creare un processo per gestire le richieste utente: configurare un processo per il modo in cui gli utenti possono richiedere l'accesso a una funzionalità o a una funzionalità.
  • Configurare un processo per la gestione di routine delle impostazioni del tenant: creare una pianificazione in modo da poter identificare le nuove impostazioni del tenant il prima possibile.
  • Configurare il controllo: creare un processo di controllo per tenere traccia di quando un'impostazione del tenant è cambiata e da chi.

Gestire i domini

I domini vengono usati in Fabric per raggruppare due o più aree di lavoro con caratteristiche simili. Ad esempio, è possibile creare un dominio per raggruppare tutte le aree di lavoro di vendita e un altro dominio per le aree di lavoro finanziarie. Un dominio rappresenta un singolo limite di gestione. L'utilizzo dei domini può anche facilitare le responsabilità di proprietà e gestione dell'area di lavoro distribuite nell'organizzazione.

Per altre informazioni sulla pianificazione dei domini, vedere Domini dell'area di lavoro.

Suggerimento

I domini fabric descritti in questa sezione sono un concetto diverso rispetto ai domini in Microsoft 365.

Passaggio 1: Esaminare i domini

Il primo passaggio consiste nell'esaminare i domini e l'ambiente tenant esistenti in modo da poter comprendere lo stato corrente. Ecco alcuni fattori da considerare durante il processo di revisione.

  • Domini: quali domini, se presenti, esistono? Il nome e la descrizione di ogni dominio indicano chiaramente lo scopo?
  • Autorizzazioni: chi sono gli amministratori di dominio per ogni dominio? Chi sono i collaboratori del dominio per ogni dominio? Tutti gli amministratori e i collaboratori assegnati sono allineati allo scopo previsto del dominio?
  • Aree di lavoro assegnate: quali aree di lavoro vengono assegnate a ogni dominio? Tutte le aree di lavoro assegnate sono allineate allo scopo previsto del dominio?
  • Impostazioni del tenant delegate: quali impostazioni del tenant sono state delegate a un amministratore di dominio (o a un amministratore della capacità) in modo che possano eseguire l'override dell'impostazione predefinita?

Passaggio 2: Decidere i domini

Dopo aver esaminato i domini, è possibile esaminare il processo decisionale.

Per le aree di lavoro esistenti, considerare come possono essere raggruppati per formare un singolo limite di gestione. Per altre informazioni e modi in cui è possibile organizzare le aree di lavoro correlate, vedere Domini dell'area di lavoro.

Ecco alcuni fattori da considerare durante il processo decisionale.

  • Quali decisioni di governance sono già in essere? Quando possibile, fare riferimento alle decisioni esistenti. Mirare all'area di lavoro e alla configurazione del dominio coerente ed efficiente.
  • Quanto decentralizzata è la proprietà e la gestione del contenuto? Valutare il modo in cui la proprietà e la gestione del contenuto si verificano attualmente in tutta l'organizzazione. A volte gli approcci decentralizzati vengono definiti architettura distribuita, federata o mesh di dati. Tenere conto di tali informazioni quando si analizzano le esigenze per organizzare le aree di lavoro in domini.
  • Quali raggruppamenti di domini funzioneranno correttamente? Esistono molti modi per raggruppare le aree di lavoro in un singolo limite di gestione. Ad esempio, è possibile scegliere di organizzare i domini in base all'area dell'oggetto, al team, alla business unit o al progetto. Tenere presente che un'area di lavoro può essere assegnata solo a un dominio. Per altre informazioni, vedere Domini dell'area di lavoro.
  • Chi deve essere autorizzato ad amministrare ogni dominio? Idealmente, gli amministratori di dominio sono utenti che possiedono e gestiscono direttamente il contenuto per il dominio. Inoltre, gli amministratori di dominio devono avere familiarità con le normative interne, regionali e governative per l'area di interesse. Devono anche avere familiarità con tutti i requisiti di governance e sicurezza interni.
  • Chi potrà assegnare aree di lavoro a un dominio? Il ruolo collaboratore dominio include gli utenti autorizzati ad assegnare un'area di lavoro a un dominio. I collaboratori dominio devono anche essere un amministratore dell'area di lavoro per assegnare l'area di lavoro al dominio. Valutare quanto controllo si vuole delegare agli utenti self-service dell'organizzazione.
  • I domini diversi verranno gestiti in modo diverso? Nelle organizzazioni di grandi dimensioni, alcuni domini potrebbero avere criteri diversi. Prepararsi ad adattare le decisioni in base alle esigenze e alle competenze di team diversi. Per altre informazioni, vedere Eseguire l'override delle impostazioni a livello di tenant.

Passaggio 3: Aggiornare i domini

A questo punto, sono disponibili le impostazioni di dominio esistenti e le decisioni intenzionali. È ora possibile aggiungere, modificare o rimuovere domini (se necessario).

Assicurarsi di seguire le procedure di gestione delle modifiche esistenti e di informare tutti gli utenti che saranno interessati da eventuali modifiche.

Passaggio 4: Domini documento

A seconda del numero di domini disponibili, è possibile creare la documentazione per aumentare le informazioni disponibili nel portale di amministrazione. La documentazione potrebbe includere quanto segue:

  • Più contesto o dettagli, ad esempio lo scopo del dominio, e perché un dominio separato è utile.
  • Chi ha approvato il dominio e quando.
  • Chi è il proprietario o l'amministratore del dominio: se è diverso dagli amministratori di dominio impostati nel portale di amministrazione.
  • Eventuali altri requisiti normativi o di conformità correlati al dominio.

Passaggio 5: Gestire i domini

I domini devono essere esaminati regolarmente nel portale di amministrazione. Ogni trimestre, o due volte all'anno, dovrebbe funzionare bene a questo scopo.

Considerare anche come gestire le richieste degli utenti che vogliono creare un nuovo dominio, modificare un dominio esistente o aggiungere aree di lavoro a un dominio.

Passaggio 6: Controllare i domini

È necessario disporre di un processo per controllare regolarmente i domini e le relative impostazioni. Ecco alcune azioni da identificare quando si controllano i domini usando il log attività.

  • È stato creato un nuovo dominio: cercare l'attività InsertDataDomainAsAdmin.
  • Un dominio esistente è stato modificato: cercare l'attività UpdateDataDomainAsAdmin.
  • Un'area di lavoro è stata assegnata a un dominio: cercare l'attività UpdateDataDomainFoldersRelationsAsAdmin.
  • Gli amministratori di dominio o i collaboratori di dominio sono stati modificati: cercare l'attività UpdateDataDomainAccessAsAdmin.

Elenco di controllo: quando si pianificano e gestiscono domini, le decisioni chiave e le azioni includono:

  • Esaminare i domini correnti: determinare lo stato corrente esaminando tutti i domini nel portale di amministrazione.
  • Discutere e decidere: determinare quali raggruppamenti di domini funzioneranno meglio per soddisfare le proprie esigenze. Coinvolgere i responsabili decisionali e gli stakeholder pertinenti quando si valuta come gestire i domini.
  • Verificare se è necessaria l'approvazione: determinare se un processo deve esistere per ottenere l'approvazione da altri utenti durante la creazione di un nuovo dominio.
  • Creare una pianificazione da rivedere: configurare una pianificazione per rivalutare i domini a intervalli regolari.
  • Apportare aggiornamenti: aggiornare i domini in caso di nuove esigenze.
  • Creare la documentazione: se è necessario registrare altre informazioni, creare la documentazione per i domini.
  • Creare un processo per gestire le richieste utente: configurare un processo per il modo in cui gli utenti possono richiedere un nuovo dominio.
  • Configurare il controllo: creare un processo di controllo per tenere traccia della creazione di nuovi domini o quando si verificano modifiche.

Gestire le aree di lavoro

Le aree di lavoro sono un concetto fondamentale in Fabric. Le aree di lavoro fungono da contenitori per l'archiviazione e la protezione del contenuto. Principalmente, le aree di lavoro sono progettate per la creazione, la collaborazione e la distribuzione di contenuti.

La pagina aree di lavoro nel portale di amministrazione consente agli amministratori di Infrastruttura di esaminare e gestire tutte le aree di lavoro nel tenant.

Ecco diversi motivi per cui un amministratore di Fabric potrebbe essere coinvolto nella gestione delle aree di lavoro.

  • Ottenere l'accesso a un'area di lavoro standard. Un amministratore dell'infrastruttura potrebbe dover aiutare con una situazione (ad esempio un errore di aggiornamento dei dati) quando il proprietario primario del contenuto è, ad esempio, in vacanza. In tal caso, dovranno assegnarsi a un ruolo dell'area di lavoro.
  • Ottenere l'accesso temporaneo a un'area di lavoro personale. È possibile che un amministratore di Fabric ottenga l'accesso all'area di lavoro personale di un altro utente, ma solo per 24 ore. L'accesso temporaneo a un'area di lavoro personale è utile quando il proprietario dell'area di lavoro ha lasciato l'organizzazione o è in vacanza.
  • Gestire i ruoli dell'area di lavoro. Un amministratore di Infrastruttura dispone dell'autorizzazione per gestire i ruoli dell'area di lavoro per tutte le aree di lavoro nel tenant. Questo è utile quando un team centralizzato gestisce l'accesso all'area di lavoro. È utile anche quando l'area di lavoro si trova in uno stato orfano (che indica che non c'è un amministratore dell'area di lavoro) che può verificarsi a causa di terminazioni o trasferimenti di lavoro.
  • Riassegnare un'area di lavoro. Per sbloccare altre funzionalità, a volte è necessario aggiornare la modalità di licenza dell'area di lavoro per un'area di lavoro. Ad esempio, un amministratore di Fabric può modificare un'area di lavoro da Pro o Premium per utente (PPU) a una capacità.
  • Determinare il tipo di area di lavoro. Un amministratore di Infrastruttura può esaminare il livello SKU a cui è assegnata un'area di lavoro. Ad esempio, l'amministratore può determinare rapidamente che nel tenant sono presenti quattro aree di lavoro attualmente assegnate a PPU.
  • Individuare e/o ripristinare le aree di lavoro eliminate. Lo stato dell'area di lavoro può indicare che un'area di lavoro è stata eliminata. Per un breve periodo, un amministratore di Fabric può ripristinare un'area di lavoro se è stata eliminata in caso di errore. In alternativa, possono ripristinare un'area di lavoro personale eliminata come area di lavoro standard. Per altre informazioni, vedere Conservazione dell'area di lavoro.
  • Aggiornare il nome dell'area di lavoro. Un amministratore di Fabric può rinominare un'area di lavoro, ad esempio perché il nome non è conforme alla convenzione di denominazione stabilita.

Nota

Il livello di coinvolgimento nella gestione delle aree di lavoro dipende dai ruoli e dalle responsabilità assegnate a un amministratore di Fabric. La strategia per la proprietà e la gestione dei contenuti può anche influenzare la misura in cui un amministratore di Fabric viene coinvolto nella gestione dell'area di lavoro.

Passaggio 1: Esaminare le aree di lavoro

Il primo passaggio consiste nell'esaminare le aree di lavoro e l'ambiente tenant esistenti in modo da poter comprendere lo stato corrente. Ecco alcuni fattori da considerare durante il processo di revisione.

  • Aree di lavoro correnti: esaminare tutte le aree di lavoro attualmente esistenti. È anche necessario esaminare le assegnazioni di ruolo e le impostazioni di ogni area di lavoro per assicurarsi che siano appropriate.
  • Impostazione del tenant corrente: esaminare l'impostazione corrente del tenant Crea aree di lavoro.

È possibile compilare un elenco di aree di lavoro correnti in due modi.

  • Visualizzare l'elenco delle aree di lavoro nel portale di amministrazione. L'elenco può essere esportato in un file CSV.
  • Estrarre un inventario tenant a livello di codice usando un'API di amministrazione tramite:
    • API di analisi dei metadati (note anche come API dello scanner). Questo set di API consente di individuare in modo asincrono le aree di lavoro modificate. Poiché è in grado di estrarre aree di lavoro modificate in modo incrementale, è più adatto alle organizzazioni più grandi con un numero elevato di aree di lavoro. Per altre informazioni, vedere API di analisi dei metadati.
    • L'API REST Get Groups As Admin o il cmdlet di PowerShell Get-PowerBIWorkspace. Questi metodi restituiscono dati per tutte le aree di lavoro nel tenant, quindi sono più adatti alle organizzazioni più piccole con volumi di dati inferiori. Per altre informazioni, vedere Cmdlet dell'API o delle aree di lavoro di gruppi.

Passaggio 2: Decidere le aree di lavoro

Dopo aver esaminato le aree di lavoro, è possibile esaminare il processo decisionale.

Ecco alcuni fattori da considerare durante il processo decisionale.

Per altre considerazioni, vedere Pianificazione dell'area di lavoro a livello di tenant e Pianificazione dell'area di lavoro a livello di area di lavoro.

Passaggio 3: Aggiornare le aree di lavoro

A questo punto, sono disponibili le aree di lavoro esistenti e le decisioni intenzionali. Se sono state trovate aree di lavoro da rinominare o riorganizzare, è ora possibile apportare eventuali modifiche necessarie.

Le considerazioni durante il processo di aggiornamento includono:

  • Chi gestirà l'aggiornamento? Se si dispone di più amministratori di Fabric, determinare se le aree di lavoro vengono gestite da uno o due amministratori specifici. Assicurarsi che il processo sia coerente, ben compreso e controllato correttamente.
  • Esiste un processo di gestione delle modifiche? Valutare come evitare discrepanze tra decisioni, documentazione e aggiornamenti risultanti. La comunicazione tra i team è un fattore chiave di successo nella gestione dei cambiamenti. A seconda dei requisiti di controllo, è possibile scegliere di gestire un log delle modifiche interno per tenere traccia di chi ha apportato la modifica, quando e perché (per registrare altri dettagli oltre a quanto acquisito nel log attività).
  • Come verranno gestite le comunicazioni con gli utenti? Quando si apporta una modifica che influisce sulle operazioni che gli utenti possono eseguire, assicurarsi di comunicarla. Mirare sempre a evitare la frustrazione dell'utente e le richieste di supporto non necessarie.

Passaggio 4: Documentare le aree di lavoro

A seconda del numero di aree di lavoro disponibili, è possibile creare la documentazione per aumentare le informazioni disponibili dal portale di amministrazione o dalle API REST. Questo tipo di documentazione è una parte fondamentale di un inventario tenant. La documentazione potrebbe includere quanto segue:

  • Più contesto o dettagli, ad esempio lo scopo previsto per l'area di lavoro (se non è già menzionato nella descrizione dell'area di lavoro).
  • Chi ha approvato l'area di lavoro e quando.
  • Chi è assegnato come proprietario dell'area di lavoro, se il proprietario è diverso dagli amministratori dell'area di lavoro.
  • Requisiti di conformità o normativi relativi al contenuto archiviato nell'area di lavoro.
  • Indica se l'area di lavoro contiene informazioni particolarmente riservate.
  • Requisiti di governance per l'area di lavoro.
  • Processi di gestione del ciclo di vita applicabili all'area di lavoro.

Passaggio 5: Gestire le aree di lavoro

La gestione delle aree di lavoro su base continuativa comporta principalmente:

  • Creazione di nuove aree di lavoro.
  • Aggiornamento dei metadati dell'area di lavoro, ad esempio nome o descrizione.
  • Aggiornamento dei ruoli dell'area di lavoro.
  • Ripristino delle aree di lavoro eliminate.
  • Riassegnazione di un'area di lavoro, ad esempio da Pro a PPU.
  • Gestione dell'impostazione del tenant Crea aree di lavoro.

A seconda dei ruoli e delle responsabilità, le attività di amministratore secondario possono includere:

  • Pubblicazione di contenuto (ad esempio un modello semantico o un report) in un'area di lavoro.
  • Risoluzione dei problemi relativi al contenuto dell'area di lavoro esistente.

Importante

Il ruolo di amministratore dell'infrastruttura è un ruolo con privilegi elevati che può eseguire molte funzioni di alto livello. In particolare, il ruolo non concede automaticamente l'accesso a tutti i dati nel tenant. Tuttavia, poiché gli amministratori hanno i diritti per gestire le aree di lavoro nel tenant, possono concedere l'accesso (tramite i ruoli dell'area di lavoro) ad altri utenti, inclusi se stessi.

Passaggio 6: Controllare le aree di lavoro

È necessario disporre di un processo per controllare regolarmente le aree di lavoro. Ecco alcune azioni da identificare quando si controllano le aree di lavoro usando il log attività.

  • L'impostazione del tenant Crea aree di lavoro è stata modificata: cercare i valori delle impostazioni del tenant modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Il nome dell'elemento sarà CreateAppWorkspaces.
  • Un amministratore di Fabric ha ottenuto l'accesso all'area di lavoro personale di un utente: cercare l'attività AddAdminPersonalWorkspaceAccess. Il nome dell'area di lavoro sarà nel formato PersonalWorkspace-NameOfUser. Nessuna attività viene registrata quando il sistema revoca automaticamente l'accesso, che si verifica dopo 24 ore.
  • È stata creata una nuova area di lavoro: cercare l'attività CreateFolder.
  • Un'area di lavoro esistente è stata modificata: cercare l'attività UpdateFolder.
  • L'accesso per un'area di lavoro è stato modificato: cercare l'attività UpdateWorkspaceAccess o l'attività UpdateFolderAccess.
  • Un'area di lavoro è stata riassegnata: cercare l'attività MigrateWorkspaceIntoCapacity.
  • Un'area di lavoro è stata assegnata a un dominio: cercare l'attività UpdateDataDomainFoldersRelationsAsAdmin.

Suggerimento

Oltre a usare il log attività, è consigliabile creare regolarmente un inventario tenant. Si tratta di uno snapshot, a partire da un punto nel tempo, che descrive tutte le aree di lavoro e il relativo contenuto, ad esempio modelli semantici e report. Può anche acquisire informazioni dettagliate sull'accesso all'area di lavoro. Per altre informazioni, vedere Inventario dei tenant e Accesso ai dati dell'inventario del tenant.

Elenco di controllo: quando si pianificano e gestiscono le aree di lavoro, le decisioni chiave e le azioni includono:

  • Esaminare le aree di lavoro correnti: determinare lo stato corrente esaminando tutte le aree di lavoro e l'impostazione del tenant correlata nel portale di amministrazione.
  • Discutere e decidere: determinare come gestire e gestire le aree di lavoro. Coinvolgere i responsabili delle decisioni e gli stakeholder pertinenti quando si decide chi è autorizzato a gestire le aree di lavoro.
  • Verificare se è necessaria l'approvazione: determinare se deve esistere un processo per ottenere l'approvazione da altri utenti durante la creazione di una nuova area di lavoro.
  • Creare una pianificazione da rivedere: configurare una pianificazione per rivalutare le aree di lavoro a intervalli regolari.
  • Apportare aggiornamenti: aggiornare le aree di lavoro, incluse le assegnazioni di ruolo, quando si verificano nuove esigenze.
  • Creare la documentazione: se è necessario tenere traccia delle informazioni supplementari, creare la documentazione per le aree di lavoro.
  • Creare un processo per gestire le richieste utente: configurare un processo per il modo in cui gli utenti possono richiedere una nuova area di lavoro.
  • Configurare il controllo: creare un processo di controllo per tenere traccia della creazione di nuove aree di lavoro o quando si verificano modifiche.

Gestire i codici di incorporamento

Quando si usa la funzionalità Pubblica sul Web, Power BI genera un codice di incorporamento. Un codice di incorporamento viene usato per incorporare un report in una pagina Web disponibile su Internet a chiunque. Questa funzionalità è disponibile per scopi specifici: è destinata principalmente al giornalismo dei dati o ai report contenenti dati pubblici che possono essere visualizzati da un pubblico anonimo, senza richiedere l'autenticazione.

Esaminare e gestire i codici di incorporamento regolarmente è una responsabilità fondamentale dell'amministratore dell'infrastruttura. È una responsabilità particolarmente critica perché implica la verifica dei report pubblicati pubblicamente su Internet.

Attenzione

Alcuni amministratori ritengono erroneamente che un'applicazione interna o un sito Intranet sia una posizione sicura per incorporare un report Pubblica sul Web. È consigliabile usare questa tecnica in questo modo perché i report pubblicati tramite Pubblica sul Web, indipendentemente dalla posizione in cui vengono incorporati, possono essere individuati con un motore di ricerca. La procedura appropriata per incorporare il contenuto di Power BI per i destinatari interni consiste nell'usare la funzionalità di incorporamento dell'API o per usare la tecnica di incorporamento senza codice. Per altre informazioni, vedere l'incorporamento per lo scenario di utilizzo dell'organizzazione.

Passaggio 1: Esaminare i codici di incorporamento

Il primo passaggio consiste nell'esaminare i codici di incorporamento esistenti e l'ambiente tenant in modo da poter comprendere lo stato corrente. Ecco alcuni fattori da considerare durante il processo di revisione.

Passaggio 2: Decidere i codici di incorporamento

Dopo aver esaminato i codici di incorporamento, è possibile esaminare il processo decisionale. Coinvolgere i responsabili decisionali e le parti interessate nelle discussioni su quali contenuti, se presenti, possono essere pubblicati sul Web.

Determinare anche quali utenti possono pubblicare report sul Web. Quando esistono criteri di governance o criteri di sicurezza, fare riferimento a esso quando possibile.

Importante

È consigliabile abilitare l'impostazione del tenant Pubblica sul Web per un set di utenti molto limitato. A causa del rischio elevato di pubblicazione accidentale di report contenenti dati sensibili, è consigliabile impedire o limitare la pubblicazione sul Web da parte degli autori di contenuti.

Passaggio 3: Aggiornare i codici di incorporamento

A questo punto, sono disponibili i codici di incorporamento esistenti e le decisioni intenzionali. È ora possibile apportare modifiche temporanee o permanenti ai codici di incorporamento esistenti.

Per determinare quali aggiornamenti sono necessari, potrebbe essere necessario eseguire ulteriori ricerche.

  • Esaminare tutti i report con codici di incorporamento attivi per verificare che non siano presenti informazioni non appropriate pubblicate sul Web. Verificare anche che i modelli semantici sottostanti non contengano informazioni riservate o proprietarie.
  • Contattare l'utente che ha pubblicato il report per chiarire lo scopo.
  • Collaborare con il proprietario del contenuto per rilocare il contenuto, se necessario, in un'area di lavoro non personale adatta allo scopo. Prendere in considerazione l'uso di un'area di lavoro che indica chiaramente che contiene contenuto disponibile pubblicamente. Ad esempio, un nome di area di lavoro Finance Reporting [Public] indica chiaramente lo scopo.
  • Esaminare l'etichetta di riservatezza assegnata al contenuto. Verificare che l'etichetta di riservatezza indichi che il gruppo di destinatari è un pubblico.

Passaggio 4: Documentare i codici di incorporamento

A seconda delle circostanze, è possibile creare una documentazione per integrare le informazioni disponibili nel portale di amministrazione. La documentazione potrebbe includere quanto segue:

  • Più contesto e dettagli, ad esempio scopo, destinatari previsti e giustificazione.
  • Chi ha approvato il contenuto da pubblicare pubblicamente e quando.
  • Chi è il proprietario del contenuto, se è diverso dall'utente che lo ha pubblicato.

Passaggio 5: Gestire i codici di incorporamento

I codici di incorporamento devono essere monitorati regolarmente nel portale di amministrazione. Considerare anche come gestire le richieste degli utenti che vogliono pubblicare i propri report sul Web.

Nota

Non tutti i report sono supportati per l'uso con Pubblica sul Web. È possibile che gli utenti abbiano domande per il supporto relative all'uso della funzionalità.

Passaggio 6: Controllare i codici di incorporamento

È importante avere un processo per controllare regolarmente i codici di incorporamento. Ecco alcune azioni da identificare quando si controllano i codici di incorporamento usando il log attività.

  • È stato creato un nuovo codice di incorporamento: cercare l'attività PublishToWebReport.
  • L'impostazione del tenant Pubblica sul Web è stata modificata: cercare i valori delle impostazioni del tenant modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Il nome dell'elemento sarà PublishToWeb.

Elenco di controllo: quando si pianificano e gestiscono i codici di incorporamento, le decisioni chiave e le azioni includono:

  • Esaminare i codici di incorporamento correnti: determinare lo stato corrente esaminando tutti i codici di incorporamento nel portale di amministrazione.
  • Esaminare l'impostazione del tenant corrente: esaminare la configurazione dell'impostazione del tenant Pubblica sul Web.
  • Discutere e decidere: determinare quale contenuto, se disponibile, può essere pubblicato pubblicamente e da quali utenti. Coinvolgere i responsabili decisionali e gli stakeholder pertinenti, quando appropriato. Fare riferimento ai criteri di governance esistenti, quando possibile.
  • Verificare se è necessaria l'approvazione: determinare se un processo deve esistere per ottenere l'approvazione da altri utenti durante la pubblicazione di un report sul Web.
  • Creare una pianificazione da rivedere: configurare una pianificazione per rivedere regolarmente i codici di incorporamento.
  • Apportare aggiornamenti: aggiornare i codici di incorporamento correnti in base alle esigenze. Aggiornare l'impostazione del tenant Pubblica sul Web in base alle decisioni prese (se sono diverse da quelle attualmente pubblicate).
  • Creare la documentazione: se è necessario tenere traccia delle informazioni supplementari, creare la documentazione dei codici di incorporamento.
  • Creare un processo per gestire le richieste degli utenti: configurare un processo per consentire agli utenti di richiedere la pubblicazione del report sul Web o avere l'autorizzazione per pubblicare i propri report sul Web.
  • Configurare il controllo: creare un processo di controllo per tenere traccia della creazione di un nuovo codice di incorporamento e quando l'impostazione del tenant Pubblica sul Web è stata modificata.

Gestire gli oggetti visivi dell'organizzazione

Gli autori di report di Power BI possono usare diversi tipi di oggetti visivi nella progettazione di report di Power BI.

  • Oggetti visivi principali: gli oggetti visivi predefiniti, incorporati in Power BI Desktop e nel servizio Power BI.
  • Oggetti visivi personalizzati non certificati da AppSource: oggetti visivi personalizzati sviluppati da fornitori di software di terze parti o membri della community di Power BI in tutto il mondo.
  • Oggetti visivi personalizzati certificati da AppSource: oggetti visivi personalizzati sviluppati da fornitori di software di terze parti o membri della community di Power BI in tutto il mondo e che hanno superato un processo di certificazione definito da Microsoft.

Un'organizzazione potrebbe scegliere di limitare l'uso di oggetti visivi personalizzati (quando il report viene pubblicato nel servizio Power BI) registrando gli oggetti visivi e le versioni specifici consentiti. Gli oggetti visivi consentiti sono noti come oggetti visivi dell'organizzazione.

Gli amministratori dell'infrastruttura sono responsabili della registrazione e della gestione degli oggetti visivi dell'organizzazione nell'interfaccia di amministrazione. Possono registrare:

La registrazione degli oggetti visivi dell'organizzazione offre molti vantaggi.

  • Alcuni oggetti visivi personalizzati, o tutti, saranno automaticamente disponibili nel riquadro visualizzazioni per tutti gli autori di report.
  • Gli autori di contenuti non devono importare file visivi di Power BI (con estensione pbiviz).
  • La versione degli oggetti visivi personalizzati è coerente per tutti i report.
  • I report e i dashboard verranno aggiornati automaticamente quando viene aggiornato un oggetto visivo dell'organizzazione.
  • Gli oggetti visivi personalizzati nuovi e modificati possono essere testati in modo metodico e pre-approvati prima di diventare ampiamente disponibili per l'organizzazione.
  • Se un oggetto visivo personalizzato esistente non soddisfa più i requisiti dell'organizzazione, può essere disabilitato o eliminato rapidamente.

Per altre considerazioni sulla distribuzione di oggetti visivi personalizzati nei dispositivi utente (per l'uso in Power BI Desktop), vedere Oggetti visivi personalizzati.

La parte restante di questa sezione è incentrata sulla gestione degli oggetti visivi dell'organizzazione.

Passaggio 1: Esaminare gli oggetti visivi dell'organizzazione

Il primo passaggio consiste nell'esaminare gli oggetti visivi dell'organizzazione e l'ambiente tenant esistenti in modo da poter comprendere lo stato corrente.

Passaggio 2: Decidere gli oggetti visivi dell'organizzazione

Dopo aver esaminato gli oggetti visivi dell'organizzazione, è possibile esaminare il processo decisionale. È necessario essere pronti a prendere decisioni con attenzione relative a come gestire gli oggetti visivi personalizzati.

Ecco alcune domande da considerare durante il processo decisionale.

  • Gli oggetti visivi personalizzati sono consentiti dall'organizzazione? Esistono diversi motivi per cui un'organizzazione potrebbe scegliere di essere intenzionale quando si fa affidamento su oggetti visivi personalizzati.
    • Le aspettative di qualità e stabilità variano in base a chi ha sviluppato l'oggetto visivo personalizzato.
    • Gli oggetti visivi personalizzati disponibili gratuitamente potrebbero non avere supporto tecnico.
    • Per le organizzazioni con problemi significativi di privacy dei dati, o estremamente sensibili alle problematiche di perdita dei dati, l'uso di oggetti visivi personalizzati potrebbe non essere compatibile con il profilo di rischio. Ciò è dovuto al fatto che gli oggetti visivi personalizzati hanno accesso ai dati sottoposti a query da modelli semantici. Inoltre, è possibile che l'oggetto visivo personalizzato possa trasmettere i dati a un servizio Web (che è spesso per scopi legittimi, ad esempio la chiamata di un'API o l'esecuzione di un algoritmo di intelligenza artificiale).
  • Come viene convalidato e approvato un oggetto visivo personalizzato per l'uso? Tutti gli oggetti visivi personalizzati devono essere testati e pre-approvati per l'uso nell'organizzazione. Questo processo di convalida riduce il rischio che vengano usati oggetti visivi non attendibili. Consente inoltre all'amministratore di specificare quale versione è stata testata e approvata per l'uso.
  • Chi è autorizzato a usare oggetti visivi personalizzati? L'impostazione Consenti oggetti visivi creati usando l'impostazione tenant di Power BI SDK controlla chi può aggiungere, condividere o interagire con un oggetto visivo personalizzato. Se l'organizzazione ha preso decisioni per limitare o limitare questa funzionalità (da file con estensione pbiviz importati o AppSource), è possibile dipendere dagli oggetti visivi dell'organizzazione come metodo per consentire oggetti visivi personalizzati specifici.
  • Sono necessari oggetti visivi certificati? Se AppSource è consentito, alcune organizzazioni preferiscono limitarla solo agli oggetti visivi certificati. Questa operazione viene eseguita configurando l'impostazione del tenant Aggiungi e usa solo oggetti visivi certificati. In questo caso, è possibile usare gli oggetti visivi dell'organizzazione per distribuire un oggetto visivo non certificato approvato per l'uso da parte dell'organizzazione.
  • Gli oggetti visivi personalizzati devono essere gestiti centralmente? Quando gli oggetti visivi vengono scaricati da AppSource da singoli autori di report, possono verificarsi problemi con versioni non corrispondenti. L'uso del repository visivo aziendale per gestire centralmente gli oggetti visivi personalizzati rende il processo più semplice per gli autori di report perché consente a tutti gli autori di report di Power BI all'interno del tenant di usare la stessa versione approvata. Tuttavia, richiede che l'amministratore dell'infrastruttura venga coinvolto, che potrebbe causare ritardi.
  • Quali origini sono consentite? Gli oggetti visivi dell'organizzazione possono provenire da AppSource o da un file con estensione pbiviz. AppSource è in genere l'origine migliore, soprattutto quando si vuole usare un oggetto visivo certificato. Un file con estensione pbiviz è appropriato quando l'oggetto visivo è stato ottenuto da un fornitore privatamente o quando è stato sviluppato internamente.
  • Quando dovrebbe essere visualizzato l'oggetto visivo personalizzato nel riquadro visualizzazioni? In molti casi, è opportuno consentire la visualizzazione dell'oggetto visivo personalizzato nel riquadro visualizzazioni in modo che sia disponibile automaticamente per tutti gli autori di report.

Passaggio 3: Aggiornare gli oggetti visivi dell'organizzazione

A questo punto, sono disponibili gli oggetti visivi e le decisioni intenzionali esistenti dell'organizzazione. È ora possibile apportare modifiche temporanee o permanenti agli oggetti visivi dell'organizzazione esistenti.

Potrebbe anche essere necessario modificare le impostazioni del tenant correlate agli oggetti visivi personalizzati (se gli autori di report sono autorizzati a scaricare e installare oggetti visivi personalizzati che non si trovano nel repository degli oggetti visivi dell'organizzazione).

Nota

Le impostazioni del tenant correlate agli oggetti visivi personalizzati si applicano solo ai report pubblicati, non ai report in Power BI Desktop. Per assicurarsi che gli autori di report dispongano di opzioni visive personalizzate coerenti sia nel servizio Power BI che in Power BI Desktop, è necessario gestire gli oggetti visivi doganali del computer locale (per Power BI Desktop) con Criteri di gruppo. Per altre informazioni, vedere Strumenti utente e dispositivi.

Passaggio 4: Documentare gli oggetti visivi dell'organizzazione

A seconda della situazione, è possibile creare una documentazione per integrare le informazioni disponibili nel portale di amministrazione. La documentazione potrebbe includere quanto segue:

  • Più contesto e dettagli, ad esempio ciò che l'oggetto visivo personalizzato esegue.
  • Chi ha creato l'oggetto visivo personalizzato (ad esempio uno sviluppatore interno o un fornitore) o chi deve contattare per ulteriori informazioni.
  • I test eseguiti per convalidare l'oggetto visivo, in modo che possano essere ripetuti devono essere aggiornati.
  • Chi ha approvato l'uso dell'oggetto visivo personalizzato e quando.

Passaggio 5: Gestire gli oggetti visivi dell'organizzazione

Gli oggetti visivi dell'organizzazione devono essere monitorati regolarmente nel portale di amministrazione. Considerare anche come gestire le richieste degli utenti che vogliono usare un nuovo oggetto visivo personalizzato che trovano online.

In alcuni casi, è consigliabile esaminare anche quando ogni oggetto visivo personalizzato è stato aggiornato per l'ultimo aggiornamento. Verificare se è disponibile una versione più recente. Quando è disponibile una versione più recente, è possibile aggiornare l'oggetto visivo dell'organizzazione, purché superi il test.

Passaggio 6: Controllare gli oggetti visivi dell'organizzazione

È importante avere un processo per controllare regolarmente gli oggetti visivi dell'organizzazione. Ecco alcune azioni da identificare quando si controllano gli oggetti visivi dell'organizzazione usando il log attività.

  • È stato aggiunto un nuovo oggetto visivo aziendale: cercare l'attività InsertOrganizationalGalleryItem.
  • È stato aggiornato un oggetto visivo aziendale esistente: cercare l'attività UpdateOrganizationalGalleryItem.
  • L'impostazione Consenti oggetti visivi creati usando il tenant di Power BI SDK è cambiata: cercare i valori delle impostazioni del tenant modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Il nome dell'elemento sarà CustomVisualsTenant.
  • L'impostazione del tenant Aggiungi e usa solo certificati (blocca quelli non certificati) è stata modificata: cercare i valori delle impostazioni del tenant modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Il nome dell'elemento sarà CertifiedCustomVisualsTenant.

Elenco di controllo: quando si pianificano e gestiscono oggetti visivi dell'organizzazione, le decisioni chiave e le azioni includono:

  • Esaminare gli oggetti visivi dell'organizzazione correnti: determinare lo stato corrente esaminando tutti gli oggetti visivi dell'organizzazione nel portale di amministrazione.
  • Esaminare le impostazioni del tenant correnti: esaminare ognuna delle impostazioni del tenant degli oggetti visivi di Power BI. Determinare come possono influenzare la dipendenza da oggetti visivi dell'organizzazione.
  • Discutere e decidere: determinare in che modo gli oggetti visivi personalizzati devono essere usati nell'organizzazione e da chi. Coinvolgere i responsabili decisionali e gli stakeholder pertinenti quando si valuta come usare oggetti visivi dell'organizzazione, AppSource e file con estensione pbiviz.
  • Creare una pianificazione da rivedere: configurare una pianificazione per rivalutare gli oggetti visivi dell'organizzazione a intervalli regolari.
  • Apportare aggiornamenti: aggiornare gli oggetti visivi dell'organizzazione correnti in base alle esigenze. Aggiornare le impostazioni del tenant degli oggetti visivi di Power BI in base alle decisioni prese (se sono diverse da quelle attualmente pubblicate).
  • Gestire i computer utente: configurare Criteri di gruppo per assicurarsi che gli oggetti visivi personalizzati vengano gestiti nello stesso modo in Power BI Desktop in cui si trovano nel servizio Power BI.
  • Creare la documentazione: se è necessario tenere traccia delle informazioni supplementari, creare la documentazione degli oggetti visivi dell'organizzazione.
  • Creare un processo per gestire le richieste utente: configurare un processo per consentire agli utenti di richiedere l'uso di oggetti visivi personalizzati (in generale) o per richiedere l'accesso a un oggetto visivo personalizzato specifico.
  • Configurare il controllo: creare un processo di controllo per tenere traccia della registrazione di un nuovo oggetto visivo personalizzato come oggetto visivo aziendale e quando una delle impostazioni del tenant degli oggetti visivi di Power BI è stata modificata.

Gestire le connessioni di Azure

Power BI può essere integrato con i servizi di Azure per estendere le funzionalità e fornire altre funzionalità. Esistono tre motivi principali per usare le connessioni di Azure.

  • Archiviazione dei dati per i flussi di dati (Gen1). È possibile accedere ai dati per i flussi di dati di Power BI (Gen1) direttamente in Azure. Un'area di lavoro può essere connessa a un account di archiviazione definito a livello di tenant o a un account di archiviazione specifico dell'area di lavoro. Questa tecnica viene talvolta definita bring-your-own-lake (BYOL). La flessibilità di una strategia BYOL è utile quando si vogliono riutilizzare i flussi di dati oltre Power BI consentendo ad altri processi o ad altri utenti di visualizzare o accedere ai dati. Per altre informazioni, vedere Configurare l'archiviazione del flusso di dati per l'uso di Azure Data Lake Storage Gen2 e lo scenario di utilizzo della preparazione dei dati self-service.

  • Backup e ripristino del modello semantico. Potrebbe essere necessario eseguire il backup e il ripristino di un modello semantico per scopi di ripristino di emergenza, per soddisfare i requisiti di conservazione dei dati o per eseguire la migrazione di un modello di dati. Per altre informazioni, vedere Eseguire il backup e il ripristino di modelli semantici con Power BI Premium.

  • Integrazione di Azure Log Analytics. È possibile analizzare l'attività, le prestazioni e le tendenze del modello semantico. L'integrazione di Log Analytics consente di esaminare i dati di diagnostica generati dal motore di Analysis Services (che ospita modelli semantici di Power BI). Per altre informazioni, vedere Log eventi del modello semantico.

    Nota

    La modifica del nome del set di dati è stata implementata nella servizio Power BI e nella documentazione, anche se potrebbero esserci alcune istanze, ad esempio con i nomi delle operazioni del registro eventi, in cui la modifica non è ancora stata apportata.

Se il caso d'uso principale per l'uso delle connessioni di Azure riguarda l'archiviazione dei dati (BYOL descritto nel primo punto precedente), è consigliabile usare invece flussi di dati Gen2 e OneLake. Anche se entrambi usano ADLS Gen2 per l'archiviazione dei dati, offrono funzionalità diverse, hanno scopi leggermente diversi e usano diverse opzioni di archiviazione (a seconda della modalità di scrittura dei dati). Ad esempio: OneLake archivia i dati tabulari e i flussi di dati Gen2 nel formato Delta Parquet aperto, mentre l'output dei flussi di dati di Power BI (Gen1) (con connessioni di Azure) archivia i dati nel formato comune del modello di dati. Per altre informazioni, vedere Recupero dalla generazione di flussi di dati 1 alla seconda generazione.

La parte restante di questa sezione è incentrata sulla governance delle connessioni di Azure nel portale di amministrazione.

Passaggio 1: Esaminare le connessioni di Azure

Il primo passaggio consiste nell'esaminare le connessioni di Azure esistenti e l'ambiente tenant in modo da comprendere lo stato corrente. Ci sono due aree da rivedere.

Esaminare prima di tutto le impostazioni esistenti nel portale di amministrazione.

  • Impostazione di archiviazione a livello di tenant corrente: verificare come è attualmente configurata l'archiviazione a livello di tenant. Fornisce una connessione di Azure predefinita a cui gli amministratori dell'area di lavoro possono scegliere di connettersi all'interno delle impostazioni dell'area di lavoro.
  • Autorizzazioni di archiviazione a livello di area di lavoro correnti: verificare se le autorizzazioni di archiviazione a livello di area di lavoro sono abilitate. Se abilitate, gli amministratori dell'area di lavoro possono connettere l'area di lavoro al proprio account ADLS Gen2.

In secondo luogo, esaminare la configurazione dell'impostazione del tenant Azure Log Analytics per gli amministratori dell'area di lavoro. Se abilitata, consente agli amministratori dell'area di lavoro di connettere un'area di lavoro a un account ADLS Gen2 allo scopo di inviare dati di diagnostica per i modelli semantici.

Passaggio 2: Decidere le connessioni di Azure

Dopo aver esaminato le connessioni di Azure, è possibile esaminare il processo decisionale.

Ecco alcune domande da considerare durante il processo decisionale.

  • L'utilizzo delle connessioni di Azure è adatto alla strategia dei dati e alle esigenze degli utenti? Valutare se le connessioni di Azure sarebbero utili per l'archiviazione dei flussi di dati (Gen1). Determinare se sono previsti requisiti per usare la funzionalità di backup e ripristino del modello semantico. Valutare se sono necessarie per l'integrazione di Azure Log Analytics.
  • Quale archiviazione dei dati è centralizzata rispetto a quella decentralizzata? Comprendere le esigenze dei team decentralizzati e se i singoli utenti o i reparti attualmente mantengono i propri account di archiviazione di Azure. Determinare se gli amministratori dell'area di lavoro potranno connettersi al proprio account ADLS Gen2 o se si preferisce usare un account ADLS Gen2 per tutte le aree di lavoro (archiviazione a livello di tenant).
  • Come verrà usato OneLake rispetto alle connessioni di Azure? Con l'introduzione di OneLake, valutare se è possibile scegliere di passare gradualmente all'uso di OneLake per l'archiviazione dei dati (BYOL).

Per altre informazioni, vedere Integrazione dell'area di lavoro con ADLS Gen2.

Per altre informazioni, vedere Integrazione dell'area di lavoro con Azure Log Analytics.

Passaggio 3: Aggiornare le connessioni di Azure

A questo punto, le connessioni di Azure esistenti sono disponibili e sono state prese decisioni intenzionali su se si intende integrare un data lake con Power BI. A questo punto è possibile modificare le impostazioni, se necessario, in base ai risultati.

Passaggio 4: Documentare le connessioni di Azure

A seconda della situazione, è necessario creare una documentazione per integrare le informazioni disponibili nel portale di amministrazione. La documentazione potrebbe includere:

  • Posizione data lake a livello di tenant approvata per l'utilizzo. Includere chi possiede e gestisce il data lake e chi contattare per ulteriori informazioni.
  • Indica se i data lake a livello di area di lavoro possono essere integrati. Altre informazioni, ad esempio decisioni chiave prese e motivi per cui, devono essere documentate per riferimento futuro.

Passaggio 5: Gestire le connessioni di Azure

Le connessioni di Azure devono essere monitorate nel portale di amministrazione di volta in volta.

Si consideri come supportare più account ADLS Gen2 nell'organizzazione (se sono consentite connessioni di Azure a livello di area di lavoro).

Si consideri anche come gestire le richieste degli utenti che vogliono connettere un'area di lavoro a Log Analytics di Azure.

Passaggio 6: Controllare le connessioni di Azure

È importante avere un processo per controllare regolarmente le connessioni di Azure. Esistono diverse azioni da identificare quando si controllano le connessioni di Azure usando il log attività.

  • Un'area di lavoro è stata connessa ad ADLS Gen2: cercare l'attività AddLinkToExternalResource. La voce ResourceType indicherà se si tratta di un account di archiviazione o Log Analytics.
  • Un'area di lavoro è stata disconnessa da ADLS Gen2: cercare l'attività DeleteLinkToExternalResource. La voce ResourceType indicherà se si tratta di un account di archiviazione o Log Analytics.
  • L'archiviazione a livello di tenant è abilitata o disabilitata: cercare i valori modificati nel log attività usando l'attività AddExternalResource o DeleteLinkToExternalResource.
  • L'archiviazione a livello di area di lavoro è abilitata o disabilitata: cercare i valori modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Il nome dell'elemento sarà storageAccountAttachForWorkspaceAdminsEnabled. SwitchState sarà true o false.
  • L'impostazione del tenant Connessioni di Azure Log Analytics per gli amministratori dell'area di lavoro è stata modificata: questa impostazione del tenant consente ad alcuni o a tutti gli amministratori dell'area di lavoro di integrare il proprio account ADLS Gen2. Cercare i valori delle impostazioni del tenant modificati nel log attività usando l'attività UpdatedAdminFeatureSwitch. Il nome dell'elemento sarà LogAnalyticsAttachForWorkspaceAdmins.

Elenco di controllo: durante la pianificazione e la gestione delle connessioni di Azure, le decisioni chiave e le azioni includono:

  • Esaminare le connessioni correnti di Azure: determinare lo stato corrente esaminando le impostazioni a livello di tenant e a livello di area di lavoro per le connessioni di Azure nel portale di amministrazione. Esaminare anche la configurazione dell'impostazione del tenant Connessioni per gli amministratori dell'area di lavoro di Azure Log Analytics.
  • Discutere e decidere: determinare se si intende integrare le connessioni di Azure con Power BI. In futuro, decidere qual è l'uso ottimale per OneLake rispetto alle connessioni di Azure per l'archiviazione dati (BYOL).
  • Verificare se è necessaria l'approvazione: determinare se deve esistere un processo per ottenere le approvazioni per l'uso degli account di archiviazione a livello di area di lavoro.
  • Creare una pianificazione da rivedere: configurare una pianificazione per rivedere regolarmente le connessioni di Azure.
  • Apportare aggiornamenti: aggiornare le connessioni di Azure correnti in base alle esigenze per modificare le autorizzazioni di archiviazione a livello di tenant e a livello di area di lavoro. Aggiornare anche l'impostazione del tenant Connessioni per gli amministratori dell'area di lavoro di Azure Log Analytics in base alle decisioni prese (se sono diverse da quelle attualmente impostate).
  • Creare la documentazione: se è necessario tenere traccia delle informazioni supplementari, creare la documentazione delle connessioni di Azure.
  • Creare un processo per gestire le richieste utente: configurare un processo per consentire agli utenti di richiedere l'uso delle connessioni di Azure.
  • Configurare il controllo: creare un processo di controllo in modo da poter monitorare quando le aree di lavoro hanno impostato una connessione di Azure o quando le impostazioni sono state modificate.

Controllare l'utilizzo di Power BI

I dati di controllo a livello di tenant consentono di analizzare le attività di adozione, comprendere i modelli di utilizzo, informare gli utenti, supportare gli utenti, attenuare i rischi, migliorare la conformità, gestire i costi delle licenze e monitorare le prestazioni. È fondamentale estrarre e archiviare i dati di controllo di Power BI il prima possibile, anche se oggi non si è ancora pronti per analizzare i dati.

Per informazioni sul controllo di utenti, attività e soluzioni in Power BI, vedere Controllo a livello di tenant.

Monitorare il servizio Power BI

Il monitoraggio si riferisce alle attività in corso che informano l'utente su cosa sta succedendo. Il monitoraggio è in genere un'attività passiva che comporta avvisi e automazione, anche se a volte viene eseguita attivamente.

Per informazioni sul monitoraggio di Power BI, vedere Monitoraggio a livello di tenant.

Contenuto correlato

Per altre considerazioni, azioni, criteri decisionali e indicazioni utili per prendere decisioni di implementazione di Power BI, vedere Pianificazione dell'implementazione di Power BI.