# Managing Power BI gateways in a large tenant: the jobs the portal has no button for If you look after Power BI or Fabric data gateways - on-premises or virtual network (VNet) - you know Microsoft's **Manage connections and gateways** page. It shows the gateways and connections you manage, and lets you change them - one at a time. That's fine for a handful. In a large tenant, with dozens of gateway clusters and thousands of connections, most of what a gateway admin does every week has no button there: * putting a service account's new password on every connection that uses it * giving a team access to fifty connections at once * handing a leaver's roles to their successor * finding every connection that signs in as a given account, or that a given person can use * showing an auditor who can use what * being told when a gateway member goes down * seeing which clusters are filling up toward the limit of 1,000 data sources, and what could go Each of these ends up as hours of clicking, or a PowerShell script of your own. So I built **GatewayLens**: a free, open-source console for gateway admins that does exactly these jobs, in bulk. It signs in as you, and can do only what you can do in the portal. ![A tour of GatewayLens on Contoso, a fictional company](https://raw.githubusercontent.com/lukas-novacek/GatewayLens/main/assets/screenshot-tour.png align="center") Here are the six jobs it does - and, for most of them, something the docs don't tell you. ## 1\. See every gateway cluster at a glance, and know when one drops GatewayLens opens on a wall of tiles, one per gateway cluster: green when every member is online, amber when some are down, red when the cluster is offline. Each tile shows how many members are online, the gateway version, and how many connections the cluster holds against the limit of 1,000. A badge says when a cluster is near or at the limit, when a version is out of support - Microsoft supports only the last six monthly releases - or when members run different versions. Problems come first, so they are seen first, and the kiosk view puts the wall full screen on a TV for the whole team. You don't have to keep looking. Turn on **alerts**, and GatewayLens tells you when a member goes down and when it is back: a Windows notification, a sound, or a message in Teams through a Teams workflow or a Power Automate flow - which can just as well send an email or open a ticket. A member counts as down only after two checks in a row, so one slow answer wakes nobody. Alerts come while GatewayLens is running - on that wall screen, or on your own PC. **What the docs don't tell you:** asking a virtual network (VNet) data gateway for its status starts it if it has paused - and it then uses capacity until it pauses again. GatewayLens leaves VNet gateways alone unless you ask it to check them. ![The gateway wall](https://raw.githubusercontent.com/lukas-novacek/GatewayLens/main/assets/screenshot-gateways.png align="center") ## 2\. Find any connection - by server, person or account The Connections tab lists every gateway connection you can see, and filters it by what you actually know when something happens: * **by connection string** - a server, a database, a path, or several at once: `sqlprd01; sqlfin01; ora-scm01` * **by who has access** - a person or a group, by part of their name or email * **by the account in the credentials** - every connection that signs in as `svc_sales` * by gateway, by type, and by whether its gateway is online Every button below the list then acts on exactly what is listed. And every list works like a spreadsheet: sort by any column, copy rows straight into Excel, export to CSV. **What the docs don't tell you:** the Fabric REST API doesn't say which account a connection's credentials use, and its access lists carry only object ids - no names. The portal gets the account from an endpoint of its own, and the names from Microsoft Graph. GatewayLens does the same, so you see `svc_sales` and real names instead of ids. (That endpoint isn't documented, so the account has a checkbox of its own.) ![The Connections tab: filters, who has access, and the actions for every listed connection](https://raw.githubusercontent.com/lukas-novacek/GatewayLens/main/assets/screenshot-connections.png align="center") ## 3\. Put a new password on every connection that uses it A service account's password changes. Filter by that account, type the new password once, and press **Update credentials**. GatewayLens says how many connections it will update, and to which account, and asks first. Then it updates each one, encrypted for the members of its own gateway, and tests exactly those connections afterwards - so you know straight away which still fail, with the gateway's own reason. This works for connections on on-premises gateways; VNet gateway connections are on the roadmap. **What the docs don't tell you:** update credentials through Microsoft's documented API, and the username no longer shows in the portal. That call stores only the encrypted credentials, not the readable copy of the username that the portal keeps next to them. GatewayLens updates them the way the portal does, so the username stays - and if that way is refused, it uses the documented one. And with **Skip test connection** on, a test can pass without the gateway even trying the data source. GatewayLens marks those tests **Unverified**, not OK. ![Verify status: every result in the log as it comes](https://raw.githubusercontent.com/lukas-novacek/GatewayLens/main/assets/screenshot-verify-status.png align="center") ## 4\. Grant, review and hand over access in bulk * **Verify users** shows who has access to every listed connection, by name. * **Grant** or **remove** access for several people and groups at once, on every listed connection. Someone who already has the role is left alone; a lower role is raised. * **Hand over access** when someone leaves or changes teams. **Copy access** gives their successor exactly the same roles on every listed connection - and, if you tick it, on the gateway clusters too. **Move access** does the same, then removes the old roles - but only where the successor has them by then, so no connection is ever left without an owner. Each of these asks first, naming who and how many connections, then works through them one at a time - and can be cancelled. ## 5\. Clean up before a cluster hits 1,000 Microsoft allows [1,000 data sources per gateway cluster](https://learn.microsoft.com/en-us/data-integration/gateway/service-gateway-onprem), and a full cluster takes no new connection. Fabric now records, for each connection, when it was made, when it was last linked to an item, and when its credentials were last used. GatewayLens turns that into a cleanup: * every tile says how many of its connections are unused - "940 of 1,000 connections - 312 unused" - and a right-click lists them * **Show > Cleanup candidates** lists what can go, each with its reason: *not used for 212 days*, or *no use recorded since it was made* * copies are found too - the same gateway, type, path, account and sign-in settings. The copy used most recently stays, and a copy still in use is *merge first*, never *can go* * the **cleanup report** is a page to forward: how full each cluster is now and after cleanup, how recently its connections were used, and who owns what can go - so you can ask before you delete * then **Delete all listed connections** - with a backup of every one written first Before anything goes, it helps to know what still points at it - which reports, semantic models, dataflows and pipelines would stop. I wrote about building that map for a whole tenant, with the Scanner API: [You can't see what depends on your Power BI gateways. Here's how to build the map.](https://lukeweaves.hashnode.dev/you-can-t-see-what-depends-on-your-power-bi-gateways-here-s-how-to-build-the-map) **What the docs don't tell you:** connection recency is still a preview, and use from before Microsoft began recording it doesn't show - so "never used" really means "no use recorded". And a quarterly refresh comes only every 90 days or so. That's why GatewayLens waits 120 days before it calls a connection unused, and never lists one that was made or linked in the last 30 days, or one without recency data. ![The cleanup report](https://raw.githubusercontent.com/lukas-novacek/GatewayLens/main/assets/screenshot-cleanup-report.png align="center") ## 6\. Answer the auditor An audit asks two things: who can use what, and who changed what. * The **access report** answers the first: one row per connection or gateway and person, with the role, the connection's path and account, and when it was last used - read fresh from Fabric, as a CSV for Excel. Set the User filter first, and it's everything one person can access. * The **change record** answers the second. Every change GatewayLens makes is written down as it happens: when, by whom, in which tenant, what, on which connection or gateway, for whom, which role, and the result. One CSV a month, which GatewayLens never deletes. If the record can't be written, nothing is changed. * Every delete writes a backup of the connection first. No backup, no delete. **What the docs don't tell you:** the portal leaves accounts that are no longer in Microsoft Entra ID out of its access lists - but they still hold their roles. The access report marks them, and **Show > Access by accounts not in Entra ID** finds every connection where they still have one. ## Built to make mistakes hard A tool that changes credentials and access on hundreds of connections has to be careful: * nothing changes until you press a button that says so, and every one asks first, naming what it will do and to how many * one item at a time, with every item and its result in the log, and a Cancel button while it runs * no passwords or tokens are stored, there is no telemetry, and nothing is sent anywhere but Microsoft ## Questions ### How do I update credentials on many Power BI gateway connections at once? Filter GatewayLens's Connections tab by the account, type the new password once, and press **Update credentials**. Every listed connection on an on-premises gateway gets it, and each one is tested afterwards. ### Can I get an alert when a gateway member goes offline? Yes. While GatewayLens runs, it shows a Windows notification, plays a sound, or posts to a Teams workflow or Power Automate flow - when a member goes down, and when it is back. ### How do I find what to delete before a cluster reaches 1,000 data sources? **Show > Cleanup candidates** lists the connections not used for 120 days, or never used, each with the reason. The cleanup report adds their owners, so you can ask before you delete. ### Does it work with VNet data gateways? Yes - their tiles, connections and access. It never wakes a sleeping VNet gateway unless you ask, and bulk credential updates are for on-premises gateway connections. ### Is it from Microsoft? No. GatewayLens is an independent, free and open-source project under the MIT licence. It signs in as you, and can do only what you can do in the portal. ## Try it GatewayLens runs on Windows with PowerShell 7.2 or later. Download `GatewayLens.exe` from the [latest release](https://github.com/lukas-novacek/GatewayLens/releases/latest) and choose **Try the demo**: it opens the real app on Contoso, a fictional company, so you can try every button without signing in. When you're ready for your own tenant, install Az.Accounts once - `Install-Module Az.Accounts -Scope CurrentUser`, no admin rights needed - and sign in. Run `GatewayLens.exe -SelfTest` first: it tells you what works for your account, and changes nothing. GatewayLens is free and open source, under the MIT licence: [github.com/lukas-novacek/GatewayLens](https://github.com/lukas-novacek/GatewayLens) If something you need is missing, open an issue - and if it saves you time, a star on GitHub helps other gateway admins find it.