L’admin portal di Microsoft Fabric è il punto in cui il tenant decide cosa è tecnicamente possibile. Nella maggior parte degli scenari d’esame DP-600 la domanda non è “come configuro il workspace”, ma “perché quella funzione non compare?”: la risposta corretta è quasi sempre un tenant setting disattivato.
Gerarchia di precedenza
La regola da memorizzare è che le impostazioni si applicano dall’alto verso il basso e il livello più restrittivo vince:
- Tenant setting (admin portal) — abilita o nega la funzione per tutto il tenant, eventualmente delegando a security group specifici.
- Domain setting — un domain admin può restringere ulteriormente, mai allargare.
- Capacity setting — governa il comportamento del workload sulla capacity (es. XMLA endpoint, memoria semantic model).
- Workspace / item setting — permessi, ruoli, Git connection, sensitivity label.
Conseguenza operativa: se un tenant setting è Disabled, nessuna configurazione di workspace lo riattiva. Il primo passo diagnostico in questi scenari è sempre l’admin portal, e chi lo modifica deve essere Fabric administrator (o Power Platform / Global administrator in Microsoft Entra ID).
I tenant setting più ricorrenti
| Requisito nello scenario | Impostazione da toccare | Livello |
|---|---|---|
| Deploy di un modello da Tabular Editor / SSMS, script TMSL, partizioni custom | XMLA endpoint su Read Write | Capacity settings → Semantic Model Workload |
| Connessione live/DAX da Excel o strumenti di terze parti in sola lettura | XMLA endpoint su Read | Capacity settings |
| Bloccare l’estrazione di dati verso Excel/CSV/.pbix | Export data e Export reports as PowerPoint/PDF/Excel | Tenant settings → Export and sharing |
| Pipeline CI/CD non interattive, refresh automatizzato via API | Service principals can use Fabric APIs (e read-only admin APIs) | Tenant settings → Developer settings / Admin API settings |
| Shortcut OneLake verso ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse | Create Onelake shortcuts to external data sources | Tenant settings → OneLake |
| Versionamento notebook, semantic model, report in Azure DevOps o GitHub | Users can synchronize workspace items with their Git repositories (+ variante …in other geographical locations se il repo è in altra region) | Tenant settings → Git integration |
Alcuni dettagli che l’esame ama:
- XMLA endpoint non è un tenant setting: vive in Capacity settings, per singola capacity, e va accoppiato al tenant setting Allow XMLA endpoints and Analyze in Excel with on-premises datasets. Lo scenario “il deployment con Tabular Editor fallisce” richiede quasi sempre di passare da Read a Read Write.
- Service principal: oltre al tenant setting, il principal deve avere un ruolo sul workspace (Member o Admin per scrivere) e appartenere al security group indicato nell’impostazione. Abilitare solo l’uno o solo l’altro non basta.
- Delegation: molti setting possono essere aperti “for a subset of the organization” specificando security group, e alcuni sono delegabili a capacity o domain admin — utile quando il requisito è “consentirlo solo al team Finance”.
- Direct Lake non ha un interruttore dedicato: dipende dal formato Delta in OneLake e dai permessi sul Lakehouse/Warehouse, non da un tenant setting.
Monitoraggio: dove guardare cosa
- Monitoring hub: vista cross-workspace delle attività eseguite — refresh di semantic model e dataflow, run di pipeline, Spark job di notebook e lakehouse. Da qui si aprono i dettagli dell’errore, la durata, l’utente che ha lanciato l’operazione e (per Spark) i log dell’applicazione. È lo strumento per “un refresh notturno è fallito, trova la causa”.
- Microsoft Fabric Capacity Metrics app: consumo in Capacity Units (CU) per item e per operazione, distinzione fra operazioni interactive e background, smoothing su 24 ore, e soprattutto la tabella dei throttling (interactive delay → interactive rejection → background rejection). È lo strumento per “le query sono improvvisamente lente per tutti”.
- Workspace monitoring e log di Microsoft Purview / audit log completano il quadro per governance e tracciamento accessi.
Trappole tipiche d’esame
- Scenario: il pulsante Git integration non appare nel workspace anche se l’utente è workspace admin → risposta: abilitare il tenant setting Users can synchronize workspace items with their Git repositories; il ruolo sul workspace non è sufficiente.
- Scenario: una pipeline Azure DevOps con service principal riceve 401 sulle Fabric REST API → risposta: abilitare Service principals can use Fabric APIs per il security group corretto e assegnare al principal il ruolo Member/Admin sul workspace.
- Scenario: deployment del semantic model con Tabular Editor fallisce in scrittura → risposta: impostare XMLA endpoint su Read Write nelle capacity settings (non nel workspace).
- Scenario: report improvvisamente lenti su tutta la capacity F → risposta: aprire la Capacity Metrics app e verificare throttling/overage, non il Monitoring hub e non il refresh history del singolo modello.
- Scenario: impedire il download dei dati in Excel mantenendo la visualizzazione dei report → risposta: disabilitare Export data nei tenant settings, eventualmente solo per specifici security group; non rimuovere i permessi di lettura sul workspace.