Votre accès Power BI tombe dès que le PC relais est éteint ? Voici comment fiabiliser vos rafraîchissements en installant la passerelle directement sur le serveur, avec méthodes, prérequis, performances et haute disponibilité.
Installer ou non la passerelle Power BI directement sur le serveur ?
Vue d’ensemble de la question
Bart souhaite publier des rapports Power BI qui s’alimentent depuis des fichiers stockés sur un serveur on‑premises. Aujourd’hui, une passerelle On‑Premises Data Gateway est installée sur un PC intermédiaire qui doit rester allumé. Problème : ce PC s’éteint souvent, bloquant l’accès aux données et les rafraîchissements planifiés. La question est donc simple : peut‑on (et doit‑on) installer la passerelle directement sur le serveur, plus fiable et rarement éteint ?
Réponse & pistes de solution
Oui, l’installation de la passerelle Power BI directement sur le serveur est la voie la plus robuste. Selon votre contexte, plusieurs approches sont possibles :
| Option | Description | Conditions techniques | Avantages | Inconvénients / points d’attention |
|---|---|---|---|---|
| Installer la passerelle standard sur le serveur | Téléchargez et installez On‑Premises Data Gateway (mode Standard) directement sur le serveur Windows qui héberge les fichiers ou qui y accède en réseau. | Windows Server 2012 R2 ou supérieur (recommandé : 2019/2022) Compte de service (AAD/AD) pour exécuter le service Sortie HTTPS 443 vers Internet Optionnel : 5671/5672 (AMQP) si requis par l’environnement | Plus de poste intermédiaire à maintenir Réduction des pannes liées aux arrêts de PC Éligible à la redondance par cluster | Nécessite des droits d’administration sur le serveur Consommation de ressources (prévoir ~4 Go de RAM dédiés pour charges moyennes) |
| Utiliser un cluster de passerelles | Conserver la passerelle sur le PC existant et ajouter le serveur comme second nœud dans le même cluster. | Pré requis identiques à l’option ci‑dessus pour chaque nœud, même version de passerelle recommandée. | Haute disponibilité : bascule automatique si un nœud tombe Mises à jour possibles nœud par nœud | Complexité accrue (deux installations à superviser) Capacité globale dépendante du plus faible des deux nœuds si non équilibrée |
| Migrer vers un service cloud (Dataflows, Fabric, Azure Files) | Déplacer la donnée source vers un stockage cloud natif (Fabric, SharePoint/OneDrive, Data Lake, etc.). | Sortie réseau stable et stratégie cloud validée par la DSI. | Plus de passerelle à administrer Élasticité et services managés | Éventuels coûts et refonte des flux Gouvernance et conformité à revalider |
| Passerelle personnelle (à éviter) | Mode Personal lié à un utilisateur unique. | — | Simple pour des tests ponctuels. | Non adaptée à la production : pas de cluster, pas d’admin centralisée, dépend de la session de l’utilisateur. |
Recommandation : installez la passerelle standard directement sur le serveur et, si la continuité est critique, ajoutez un second nœud en cluster. Cette combinaison élimine la dépendance au PC et offre une vraie haute disponibilité.
Quand installer la passerelle sur le serveur est la meilleure option
- Le serveur est déjà la source (ou a un accès réseau stable aux partages SMB/DFS ou aux bases SQL/Oracle, etc.).
- Des rafraîchissements planifiés doivent se produire en heures creuses sans intervention humaine.
- La DSI tolère l’installation d’un service Windows supplémentaire et l’ouverture du trafic sortant vers Azure (HTTPS 443).
- Les contraintes de conformité exigent que les données restent on‑premises.
Quand éviter l’installation locale
- Les données résident déjà dans des services cloud nativement connectés par Power BI (par exemple, SharePoint Online, OneLake/Fabric, Azure SQL DB).
- Vous n’avez pas de connectivité sortante stable ou l’architecture impose un proxy verrouillé difficile à ajuster.
- Les contraintes de sécurité interdisent toute communication sortante vers des services Microsoft (cas rares, environnements classifiés).
Étapes clés si vous choisissez l’option serveur
Préparer le serveur
- Valider l’OS : Windows Server 2012 R2 minimum (recommandé : 2019/2022 pour long terme).
- Appliquer les mises à jour, activer TLS 1.2 et vérifier l’heure système (NTP) pour éviter des erreurs de certificats.
- Ouvrir le trafic sortant vers Internet en HTTPS 443. Selon votre politique, prévoir AMQP sur 5671/5672.
- Créer un compte de service dédié, à droits minimaux :
- Log on as a service local
- Accès lecture/écriture aux partages ou bases nécessaires
- Aucun droit d’admin de domaine si non nécessaire
- Dimensionner : 4 vCPU et 8 Go de RAM pour charges moyennes (montez à 16 Go si plusieurs datasets volumineux s’exécutent en parallèle).
- Prévoir un disque système sain et un espace tampon pour les traitements (temp). Un SSD accélère les opérations de mashup.
Télécharger la passerelle
Depuis Power BI Service : Paramètres > Passerelles > Télécharger, puis choisir On‑Premises Data Gateway (Standard). Conservez l’installeur dans un répertoire d’outillage du serveur pour vos futures mises à jour.
Installer
- Exécuter l’installeur en tant qu’administrateur local.
- Au premier lancement, se connecter avec un compte disposant des droits Gateway Admin dans Power BI.
- Choisir Créer une nouvelle passerelle (ou Rejoindre un cluster existant si vous mettez en place la redondance).
- Renseigner le compte de service pour le service Windows (PBIEgwService) et valider son bon démarrage.
- Noter la clé de récupération fournie : elle servira à restaurer ou ajouter des nœuds.
Configurer les sources de données
- Dans Power BI Service, ouvrir Gérer les passerelles.
- Créer ou déplacer les connexions existantes sur la passerelle du serveur et définir l’authentification appropriée (Windows/Basic/OAuth/etc.).
- Pour des partages de fichiers, utiliser un chemin UNC (
\\serveur\partage\...) accessible par le compte de service. - Attribuer les autorisations utilisateur nécessaires (qui peut utiliser cette source, qui peut l’administrer).
Superviser
- Activer la journalisation avancée si nécessaire et suivre le Queue time et la CPU/Memory lors des créneaux de rafraîchissement.
- Mettre en place un redémarrage automatique du service en cas d’échec (Tâches planifiées ou outil de supervision).
- Planifier des fenêtres de patching trimestrielles (la passerelle a un rythme de publication mensuel).
Mettre en place un cluster pour la haute disponibilité
La haute disponibilité s’obtient en ajoutant un second nœud dans le même cluster — par exemple, garder le PC existant comme secours, ou mieux, un second serveur dans un autre hôte/VM.
- Installer la même version de passerelle sur le deuxième nœud.
- Choisir Rejoindre un cluster existant et saisir la clé de récupération.
- Vérifier dans Power BI que les deux nœuds apparaissent En ligne.
- Tester la bascule en arrêtant temporairement le service du premier nœud.
Bon à savoir : Power BI répartit les requêtes sur les nœuds disponibles. Vous pouvez retirer un nœud pour maintenance sans indisponibilité, puis le réintégrer.
Procédure de migration sans coupure depuis le PC
- Installer la passerelle sur le serveur mais ne basculez rien pour l’instant.
- Recréez chaque source de données sur la nouvelle passerelle (mêmes chemins/identifiants).
- Pour chaque dataset dans Power BI, changez la passerelle associée vers Serveur et forcez un rafraîchissement à la demande pour valider.
- Planifiez la bascule en heures creuses, surveillez deux cycles de rafraîchissement, puis désinstallez l’ancienne passerelle du PC.
Bonnes pratiques de performance
- Parallélisme : échelonnez les déclencheurs si plusieurs rapports lourds partagent la même passerelle. Un chevauchement excessif augmente la mémoire et le temps d’attente.
- Segments et incrémental : activez le rafraîchissement incrémentiel côté dataset pour réduire la charge sur la passerelle et la source.
- Réduire les déplacements de données : privilégiez des transformations près de la source (vues SQL, ETL) pour limiter le mashup côté passerelle.
- Stockage rapide : un SSD améliore les opérations temporaires du moteur de mashup.
- Surveillance continue : classez les datasets par coût d’exécution et optimisez en priorité les plus consommateurs.
| Contexte | CPU recommandé | RAM recommandée | Conseil |
|---|---|---|---|
| Petit volume (quelques fichiers, rafraîchissements espacés) | 2–4 vCPU | 4–8 Go | Planifier les rafraîchissements hors heures de pointe |
| Moyen volume (plusieurs datasets, parallélisme modéré) | 4–8 vCPU | 8–16 Go | Échelonner les jobs, surveiller la file d’attente |
| Gros volume (datasets volumineux, transformations lourdes) | 8–16 vCPU | 16–32 Go | Étudier la séparation par clusters dédiés et l’incrémental |
Réseau et sécurité
- Flux sortant uniquement : la passerelle initie les connexions vers les services Microsoft (pas d’ouverture de ports entrants).
- Proxy : si un proxy est en place, configurez‑le durant l’installation ou via les paramètres réseau de la passerelle.
- Compte de service : utilisez un compte dédié au moins privilégié, sans droits d’admin de domaine, et gérez ses mots de passe de manière sécurisée.
- Séparation des rôles : distinguez les Admins de passerelle, les Créateurs de sources et les Utilisateurs.
- Journalisation : activez les logs et conservez‑les selon votre politique de rétention.
Dépannage rapide
| Symptôme | Cause probable | Résolution |
|---|---|---|
| Passerelle Hors ligne dans Power BI | Service arrêté, proxy/pare‑feu bloquant, heure système décalée | Redémarrer PBIEgwService, vérifier sortie 443/proxy, synchroniser l’horloge |
| Erreur d’authentification sur un partage | Compte de service sans droits NTFS/Share | Accorder lecture/écriture au compte de service sur le chemin UNC |
| Rafraîchissements très lents | Mashup côté passerelle, sous‑dimensionnement CPU/RAM | Déporter les transformations, augmenter ressources, activer l’incrémental |
| Erreurs sporadiques aux heures de pointe | Parallélisme trop élevé, contention de disque | Échelonner les horaires, ajouter des vCPU/RAM ou SSD, envisager un cluster |
| Impossible d’ajouter une source | Rôle insuffisant dans Power BI | Vérifier que l’utilisateur est Admin de passerelle ou autorisé pour la source |
Scripts utiles
Sur le serveur, quelques commandes PowerShell pratiques :
# Redémarrer le service de passerelle
Restart-Service -Name PBIEgwService
# Vérifier l'état du service
Get-Service -Name PBIEgwService | Format-List Name, Status, StartType
# Exporter les journaux d'événements Application liés à la passerelle
Get-EventLog -LogName Application -Newest 200 |
Where-Object {$_.Source -like "*Gateway*"} |
Export-Csv "C:\Temp\gateway-events.csv" -NoTypeInformation Checklist décisionnelle
| Signal | Interprétation | Action recommandée |
|---|---|---|
| Le PC relais s’éteint régulièrement | Point de défaillance unique | Installer la passerelle sur le serveur et planifier un cluster |
| Rafraîchissements en conflit | Concurrence > capacité | Échelonner les horaires et augmenter CPU/RAM |
| Données sensibles on‑premises | Conformité locale | Rester sur passerelle on‑prem et renforcer la sécurité |
| Mise en cloud en cours | Cible Fabric/OneLake | Planifier une migration progressive et réduire l’usage de la passerelle |
FAQ
La passerelle est‑elle payante ?
Non, la passerelle en elle‑même est gratuite. Les licences Power BI (Pro, Premium/Fabric) des utilisateurs s’appliquent pour la publication et la consommation.
Faut‑il que le serveur héberge les fichiers ?
Non. Il peut simplement accéder en lecture/écriture à un partage réseau ou à une base de données distante. L’important est que le compte de service voie le chemin UNC ou puisse se connecter à la base.
Peut‑on mettre à jour sans coupure ?
Oui. Dans un cluster, mettez à jour un nœud pendant que l’autre reste en ligne, puis inversez.
Quelles versions Windows recommander ?
Minimum : Windows Server 2012 R2. Recommandé : 2019/2022 pour le support à long terme et les performances.
Et si l’accès Internet sortant est restreint ?
Coordonnez‑vous avec le réseau pour autoriser la sortie HTTPS 443 vers les services Microsoft. Un proxy authentifié peut être utilisé si nécessaire.
Le mode personnel convient‑il à la prod ?
Non. Ce mode est lié à un utilisateur, ne supporte pas le clustering et complique l’admin. Réservez‑le aux tests locaux.
Plan de mise en œuvre recommandé
- Semaine 1 : préparation — validation OS, compte de service, règles pare‑feu/proxy, sizing.
- Semaine 2 : installation — déploiement de la passerelle sur le serveur, création des sources, bascule d’un dataset pilote.
- Semaine 3 : généralisation — bascule progressive des autres datasets et mise en place du cluster si requis.
- Semaine 4 : industrialisation — supervision, documentation d’exploitation, routine de patching trimestriel.
Résumé exécutable
- Installez On‑Premises Data Gateway (Standard) sur le serveur.
- Utilisez un compte de service dédié, ouvrez HTTPS 443 en sortie.
- Recréez les sources et associez vos datasets à la nouvelle passerelle.
- Ajoutez un second nœud si la disponibilité est critique.
- Surveillez la queue, la CPU/RAM et échelonnez les rafraîchissements.
Informations complémentaires utiles
- Licences : la passerelle est gratuite ; seules les licences Power BI/Fabric des utilisateurs sont nécessaires.
- Performances : visez 4 cœurs CPU minimum et 8 Go de RAM pour des rafraîchissements volumineux.
- Mises à jour : nouvelle version chaque mois → planifiez un patching trimestriel.
- Sécurité : isolez le service dans un compte AD restreint et validez l’authentification AAD si le serveur peut contacter les endpoints Microsoft.
- Documentation officielle : voir la page d’installation et de configuration de la passerelle (mode Standard).
En bref : pour fiabiliser l’accès aux données de Bart, installez la passerelle Power BI directement sur le serveur et adoptez, si nécessaire, un cluster à deux nœuds. Vous éliminerez le point de défaillance représenté par le PC, gagnerez en performance et en maintenabilité, tout en respectant les contraintes de sécurité et de réseau de l’entreprise.