On-premises data gateway 3000.334 adds soft delete, a Server 2016 fix and Power BI Desktop parity
The on-premises data gateway is a Windows application you install on your own network. It connects local data sources to Microsoft cloud services, including Power BI, Microsoft Fabric, Power Apps, Power Automate, Azure Logic Apps, Azure Data Factory and Azure Analysis Services. Microsoft's documentation says the gateway only opens outbound connections and needs no inbound ports. The cloud sends it work as responses to the gateway's own polling.
Microsoft's release notice says 3000.334 ships with Power Query Engine 2.158.928 and lists these changes:
- Deleted gateways can be recovered for 30 days (soft delete).
- The embedded Apache Log4j library moves to version 2.26.1.
- A sign-in issue affecting gateway installations on Windows Server 2016 is fixed.
- The Gateway Configurator app has accessibility improvements.
- Query execution matches the September 2026 Power BI Desktop release.
The notice also mentions "authentication, diagnostics, and overall platform quality" improvements in general terms. Beyond the items above, it doesn't say what those are, so treat the list as the full set of documented changes.
Upgrade timing is more than housekeeping here. Microsoft ships a gateway update every month and actively supports only the six most recent releases. Skip a few months and a gateway falls out of support. The September notice sets no mandatory upgrade date, but the six-release rule does the same job over time.
Soft Delete gives gateway clusters a 30-day undo, for standard mode only
The release notice presents soft delete as a response to customer feedback. It targets the case where someone deletes a gateway and then has to recreate its configuration and restore connectivity. Microsoft's separate Fabric blog post announcing the feature gives the details, including some limits the release notice leaves out.
First, the feature is a preview. Microsoft says soft delete is currently is only available for standard mode of on-premises data gateways in Microsoft Fabric (Preview), and personal mode gateways and virtual network data gateways are not currently supported. That matters because the September release comes in two downloads, standard mode and personal mode. Personal-mode users get the Server 2016 fix and the Desktop alignment, but not the recovery window. Personal mode is the single-user gateway that works only with Power BI. The VNet data gateway is a Microsoft-managed service with nothing to install, and it's also excluded.
Second, the retention period is fixed and ends in permanent deletion. When a supported gateway is deleted, it is retained for 30 days by default rather than being removed immediately and permanently. Once that period ends, Microsoft says the gateway is automatically and permanently removed. Thirty days is enough to catch an accidental deletion. It won't help an admin who finds a missing gateway at a quarterly review.
Third, recovery restores the whole cluster, not individual objects. When an admin recovers a gateway, the gateway is then restored at the cluster level with its previous metadata and permissions. Microsoft is clear about the limits: recovery is not a backup and restore system. It does not recover individual gateway nodes, individual data sources, or partial permission sets as separate objects. You can bring back a deleted cluster as a single unit, but you can't use soft delete to recover a single data source someone removed.
This is a real change in the risk. Before soft delete, deleting a gateway also deleted its connections. Community troubleshooting threads have long warned that removing a gateway in the Power BI service deletes the connections built on it, along with their stored credentials. The recovery window turns that one-click permanent loss into something you can undo for a month, at least for standard-mode clusters.
How gateway recovery works in the Power Platform admin center
Gateway management lives on the Data page of the Power Platform admin center. Go to Manage in the navigation pane, then select Data (preview) under the Data section. Three groups can reach it: Microsoft Entra Global Administrators, Power BI service administrators and gateway administrators. Microsoft notes that the available features differ by role. Only Global Admins and Power BI service admins see the Tenant administration toggle. Turn it on to see every gateway in the organization, or off to see only the gateways you administer.
According to Microsoft's feature announcement, during the retention period, tenant admins and gateway admins can recover from it. The gateway management page includes the Deleted gateways section which shows Deleted clusters and Deleted members. Each entry in Deleted Clusters can show the gateway name, type, deletion timestamp and available actions, including Restore. Deleted members can also be restored from the Deleted members section.
Based on that documentation, recovering an accidentally deleted standard-mode cluster goes like this:
- Sign in to the Power Platform admin center as a Global Admin, a Power BI service admin or a gateway admin for the cluster.
- Open Manage, then Data (preview). If the gateway was installed outside your tenant's default region, pick that region from the region drop-down.
- Open Deleted gateways (Preview) and find the cluster under Deleted clusters by name and deletion time.
- Select Restore (Microsoft's text also calls it Recover) before the 30-day window closes.
Success means the cluster reappears in the active list with its previous metadata and permissions. After that, check connection status with the Check status action on the cluster's Details page.
The same area handles the opposite job, removing a gateway for good. Microsoft's tenant-migration guidance says an ordinary Delete now only soft-deletes a gateway. To remove it fully, go to Deleted gateways (Preview) and select Permanently delete for each entry under Deleted clusters. Before a tenant migration, Microsoft says to keep Tenant administration on. Remove all active and soft-deleted gateways in this region. That applies to both the home region and the target region. If you've scripted migrations that assume Delete is final, add the permanent-delete step now.
One point isn't documented. The release notice bundles soft delete with version 3000.334, but it doesn't say whether clusters running older gateway versions are covered, since recovery happens in the cloud admin center. If you have clusters on older builds, don't assume they're protected until you see them listed under Deleted gateways after a deletion.
The Log4j 2.26.1 claim, and a CVE-2026-18401 that belongs to Jackson
The security section is the least clear part of the release. Microsoft says it upgraded the gateway's embedded Apache Log4j library to 2.26.1, and Apache's official download page does list 2.26.1 as a Log4j release. The next line of the notice says the release addresses the vulnerability in CVE-2026-18401.
That CVE isn't a Log4j bug. Red Hat's security database lists CVE-2026-18401 as a flaw in jackson-core, a Java JSON library. Its non-blocking (asynchronous) JSON parser doesn't enforce the maximum number length limit. If an application feeds untrusted input to that parser, an attacker can send JSON containing an extremely long number and cause heavy memory use and CPU exhaustion, which is a denial of service. Red Hat rates it Moderate, with a preliminary CVSS 3.1 base score of 5.3. It says the standard synchronous parsing API, the default for most Java applications, enforces the limit correctly and isn't affected. The fixed versions are jackson-core 2.18.6, 2.21.1, 3.1.0 or later.
So the notice puts a Log4j version next to a Jackson CVE, and they don't match. Log4j 2.26.1 doesn't fix CVE-2026-18401. The notice doesn't say whether the gateway also updated a bundled Jackson component, or whether the CVE was listed by mistake. Nothing in it shows that the gateway ever used the vulnerable asynchronous parser.
For vulnerability management teams, the practical takeaway is narrower than the notice suggests. Microsoft says the release "addresses vulnerability findings that may be reported by security scanning tools." That's probably the most useful part of the section: if your scanner flags bundled libraries on gateway servers, upgrade to 3000.334 and rescan. If a CVE-2026-18401 finding remains, check which jackson-core version the scanner found against Red Hat's list of fixed versions. The Log4j upgrade won't clear it.
Windows Server 2016 sign-in fix and Power Query Engine 2.158.928
The most specific fix is the one for Windows Server 2016. Microsoft says 3000.334 fixes a sign-in issue affecting gateway installations on that OS. The notice doesn't describe the symptoms, which earlier versions were affected or any workaround. If you've had unexplained sign-in failures in the gateway app on Server 2016 hosts, this build is the one to try.
The Power BI Desktop compatibility item is part of the monthly routine, but it has practical value. Microsoft says reports published to the Power BI service and refreshed through this gateway use the same query execution logic and runtime as the September version of Power BI Desktop. Here that runtime is Power Query Engine 2.158.928. If report authors are on September Desktop while the gateway lags behind, a query that works on the author's machine can behave differently at scheduled refresh. Keeping the gateway on the matching release closes that gap.
The Gateway Configurator accessibility improvements aren't itemized. Microsoft names no specific controls or standards, so there's nothing concrete for admins to check.
Who should upgrade to gateway 3000.334 now
Most admins running standard-mode gateway clusters should plan this upgrade in their normal monthly cycle. Admins with Windows Server 2016 hosts showing sign-in problems, or with open scanner findings on gateway servers, should move it up the queue. Personal-mode users can upgrade for Desktop parity and the Server 2016 fix, but shouldn't count on soft delete.
The notice doesn't include an upgrade procedure, downtime estimates or rollback guidance, so follow your organization's existing gateway change process. For clustered deployments, the cluster-level recovery model is one more reason to know exactly which members belong to each cluster before you change anything.
- Version 3000.334 includes Power Query Engine 2.158.928 and matches cloud refresh behavior to the September 2026 Power BI Desktop release.
- Soft delete keeps deleted standard-mode gateway clusters for 30 days, then deletes them permanently. It's a preview and doesn't cover personal-mode or VNet data gateways.
- Recovery happens in the Power Platform admin center under Data (preview), then Deleted gateways (Preview). It restores the whole cluster with its metadata and permissions, not individual data sources or nodes.
- Tenant migration runbooks now need an explicit Permanently delete step for soft-deleted gateways in both the home and target regions.
- Microsoft's notice pairs a Log4j 2.26.1 upgrade with CVE-2026-18401, but Red Hat lists that CVE as a jackson-core flaw. Verify scanner findings by component rather than assuming the Log4j change resolves them.
- Microsoft supports only the six most recent monthly gateway releases, so a gateway that skips several updates will fall out of support.
Version 3000.334 is mostly a routine monthly release. Soft delete is the change that matters, because accidental gateway deletion goes from a rebuild to a month-long undo. Even in preview, that's a reason to get standard-mode clusters current and add the Deleted gateways view to your admin procedures. The security section needs a correction from Microsoft. Until one appears, scanner findings on gateway servers are a better guide to what the upgrade actually fixed than the CVE listed in the notice.