Power BI Labby Zero-G-Studio
Lezione 2.4
Gateway on-prem
Modulo 02 · Lezione 2.4 · Livello Base

Il Gateway dati on-premises: cos'è e come si configura

Quando i dati stanno dentro la rete aziendale, il Service nel cloud non può vederli senza ponte. Il Gateway è quel ponte. In questa lezione lo installiamo, lo configuriamo, ci mettiamo una sorgente, e schedule un refresh. Tutta la teoria + 5 esercizi troubleshooting.

  • ⏱ Tempo stimato: ~25 min + esercitazioni
  • 🎯 Prerequisiti: L1.2, L2.3
  • 🛠 Software: Power BI Desktop; opzionale: una VM Windows per installare il Gateway
1

Perché serve il Gateway

Il Power BI Service vive nel cloud Microsoft. La rete aziendale interna è chiusa da firewall: dal cloud non si "entra" dentro per leggere un SQL on-prem, un file su fileshare, un SAP locale.

Il Gateway è un piccolo servizio Windows che installi tu dentro la rete aziendale. Apre un canale sicuro outbound verso il Service. Quando il Service deve fare refresh:

  1. Manda la richiesta al Gateway tramite il canale sicuro.
  2. Il Gateway esegue la query sulla sorgente interna (con credenziali pre-configurate).
  3. Restituisce i risultati al Service, cifrati.
Sicurezza
Il Gateway apre solo connessioni outbound (porte 443 HTTPS). Non serve aprire nulla in inbound. Per certificazioni stringenti si usa anche TLS 1.2+ tra Gateway e sorgenti.
2

Personal Mode vs Standard Mode (Enterprise)

AspettoPersonal ModeStandard Mode (Enterprise)
A chi serveUn solo utente (te stesso)Tutto il team / tutta l'azienda
Dove si installaSul tuo PCSu un server sempre acceso (o cluster di server)
Quando funzionaSolo quando il tuo PC è acceso24/7
Dataset supportatiSolo per i refresh dei tuoi dataset personaliTutti i dataset di tutti gli utenti che lo usano
Alta disponibilitàNoSì, in modalità cluster (fino a 8 nodi)
Quando sceglierloPrototipi, test rapidiSempre in produzione
3

Installazione del Gateway Standard

I 5 passi standard, in produzione:

  1. Scegli il server. Una VM Windows Server 2019/2022 (o Windows 10/11 in laboratorio), 8 GB RAM, sempre accesa, vicina (network) alle sorgenti dati.
  2. Scarica l'installer da powerbi.microsoft.com/gateway → "Standard mode". File MSI ~150 MB.
  3. Esegui il setup. Accetta la EULA, scegli percorso d'installazione. Richiede ~5 minuti.
  4. Sign-in con un account Entra ID che ha permessi nel tenant Power BI. Questo account diventa il proprietario amministrativo del Gateway.
  5. Configura il Gateway: dai un nome (es. GW-Produzione-Milano), scegli la region del cluster (deve corrispondere alla region del Service tenant), e una recovery key (criptata, serve per ripristinare credenziali).
La recovery key
La recovery key non si recupera se la perdi. Salvala in password manager aziendale. Senza, se il Gateway smette di funzionare, devi ri-creare tutte le credenziali delle sorgenti.
Schermata di setup del Gateway Standard: campo nome, region, recovery key.
Schermata di setup del Gateway Standard: campo nome, region, recovery key.
4

Configurazione di una sorgente dati sul Gateway

Dopo l'installazione, vai sul Power BI Service:

  1. Click sull'icona ingranaggio in alto → Manage gateways and connections.
  2. Vedi il cluster del tuo Gateway → click "+ New connection".
  3. Scegli il tipo (SQL Server, Oracle, File, ecc.), inserisci i parametri (server/database/path) e le credenziali con cui il Gateway si autenticherà alla sorgente.
  4. (Opzionale) Configura la privacy level e il map user names(SSO: se la sorgente supporta Kerberos delegation, l'utente che apre il report viene "impersonato" sul DB).
  5. Salva. Power BI mostra "Status: Online" se tutto funziona.
5

Collegare un dataset al Gateway

Hai pubblicato un report .pbix che legge da SQL on-prem? Dal Service, il dataset deve essere mappato al Gateway giusto:

  1. Service → Workspace → Datasets → click sulla riga del dataset.
  2. Settings → Gateway connection.
  3. Vedi i Gateway disponibili. Click sul tuo → seleziona la connessione corrispondente. "Apply".
  4. Vai in Scheduled refresh, attiva, scegli orario (max 8/giorno su Pro, 48 su PPU/F-SKU).
  5. Click "Refresh now" per testare. Se va, sei a posto.
Best practice: Service Principal per il refresh
In produzione, evita le credenziali utente individuali (se l'utente lascia l'azienda, il refresh si rompe). Usa un Service Principal dedicato registrato in Entra ID, con accesso alle sorgenti. Lo configuri come "user" del Gateway connection.
6

Gateway in cluster — alta disponibilità

Per scenari mission-critical, puoi installare il Gateway su più server (fino a 8) e raggrupparli in un cluster. Il Service distribuisce le richieste e fa failover automatico se un nodo cade.

Installazione: identica al primo nodo, ma allo step "Configura" scegli "Add to existing cluster" invece di crearne uno nuovo.

Bilanciamento
Le richieste vengono assegnate round-robin tra i nodi del cluster. Quindi dimensiona ciascun nodo come se dovesse gestire 1/N del carico (più un margine per failover).
7

Monitoring e log

Tre fonti utili per diagnosticare problemi:

  • Gateway app sul server: tab "Diagnostics" → log locali + verifica connettività verso il Service.
  • Service → Manage gateways → Performance: metriche CPU/RAM/Network del cluster (richiede "log uploads" abilitato).
  • Service → Dataset → Refresh history: per ogni refresh fallito, click sulla riga per vedere il messaggio d'errore dettagliato.
8

Errori comuni e soluzioni

'Gateway is offline'
Il servizio Windows "On-premises data gateway service" è fermato. Sul server: services.msc → start. Se ricade subito, controlla i log eventi Windows per crash o problema di porta 443.
'The credentials provided cannot be used for the Source type'
Hai messo credenziali Windows per un SQL configurato con SQL Authentication (o viceversa). Vai sulla connection → Edit → cambia il tipo di auth.
Refresh va lento da quando ho aggiunto altri dataset
Il Gateway su un singolo nodo è sotto carico. Soluzioni: dimensionare meglio la macchina, aggiungere un secondo nodo al cluster, distribuire i refresh in orari diversi.
On-premises Data Gateway (Personal) per i refresh in produzione
È deprecato in pratica per uso produttivo. Non investire tempo a configurarlo per scenari stabili: passa subito a Standard cluster.
9

Esercitazioni

Esercizio 1Base

Personal vs Standard — scegli

Consegna
  1. Sto sviluppando da casa, voglio testare un refresh notturno sui miei dati Excel locali.
  2. L'azienda ha 20 report da rinfrescare ogni notte da un SQL aziendale.
  3. Sviluppatore solo: serve un refresh dal mio PC mentre lavoro.
  4. Production di un'azienda enterprise con compliance e SLA.
Esercizio 2Intermedia

Troubleshooting refresh fallito

Consegna

Il refresh schedulato del dataset "Vendite" fallisce ogni notte. Il messaggio è: "Unable to combine data. ... requires a gateway.". Cosa controlli?

Esercizio 3Intermedia

Service Principal vs utenti

Consegna

Argomenta in 3 frasi perché in produzione conviene il Service Principal per le credenziali Gateway invece dell'account dell'autore.

Esercizio 4Avanzata

Capacity planning di un Gateway cluster

Consegna

In azienda hai: 50 dataset (10 grandi 1 GB+, 40 piccoli < 100 MB), 200 refresh schedulati al giorno, picco notturno 02:00-04:00. Proponi: numero di nodi cluster, dimensione CPU/RAM per nodo, strategia di distribuzione refresh.

Esercizio 5Intermedia

Cosa NON serve il Gateway

Consegna

Per ogni sorgente indica VERO o FALSO se serve il Gateway:

  1. Azure SQL DB (cloud).
  2. SQL Server in DMZ aziendale.
  3. SharePoint Online.
  4. OneDrive Business.
  5. File su fileshare aziendale interno.
  6. Dataverse.
  7. Salesforce.
  8. Snowflake cloud.
10

Quick check finale

Quick check

In quale direzione apre connessioni il Gateway?

Quick check

Per produzione enterprise: Personal o Standard?

Hai finito la Lezione 2.4 ✓

Il Gateway non ha più segreti. Chiudiamo il Modulo 2 con la nuova frontiera: OneLake e Lakehouse Fabric.