data factory
922 TopicsOn-premises data gateway July 2026 release
The July 2026 release of the on-premises data gateway is version 3000.326. This new version (3000.326) continues our focus on improving gateway manageability, operational visibility, and enterprise governance while maintaining secure and reliable connectivity between on-premises data sources and Microsoft Fabric services. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the July 2026 release of Power BI Desktop. Download on-premises data gateway (standard mode) Download on-premises data gateway (personal mode) This version of the gateway will ensure that the reports that you publish to the Power BI Service and refresh via the gateway will go through the same query execution logic/run-time as in the July version of Power BI Desktop. Thank you! Upgrade to version 3000.326 to take advantage of the latest security, authentication, and diagnostics improvements. We encourage you to share feedback and feature requests through the Power BI Ideas forum to help shape future gateway investments.1.1KViews0likes4CommentsAbility to Recover Previous Versions of Power BI Service Reports After Overwrite
Description: Currently, when a report developed directly in the Power BI Service is overwritten, there is no supported method to recover the previous version of the report. In the observed scenario: The report was created and maintained in the Power BI Service. The report was subsequently overwritten by a newer version. An earlier version remained visible in the published app; however, it could not be exported because the "Allow users to make a copy of the reports in app" setting was not enabled when the app was published. Enabling this setting after the overwrite does not restore access to the previous version, as it requires republishing the current report and does not provide a mechanism to retrieve historical versions. Expectation: Providing report version recovery would improve resiliency, reduce the risk of accidental data loss, and help customers quickly restore reports when unintended overwrites occur.6Views0likes0CommentsFabric Workspace Operator Role for Pipeline Monitoring and Rerun Operations
Many organizations have dedicated production support and operations teams responsible for monitoring Microsoft Fabric pipelines and responding to failures. Currently, the available workspace roles are Admin, Member, Contributor, and Viewer. While Viewers can monitor content, they cannot rerun failed pipelines. Contributors can rerun pipelines, but they also have permissions to modify pipeline definitions and other workspace artifacts. This creates a governance gap for enterprises that require segregation of duties between development and operations teams. Proposed Solution Introduce a new built-in Operator workspace role with permissions such as: Allowed View pipeline definitions Monitor pipeline runs and run history View execution logs and error details Manually trigger pipeline execution Rerun failed pipeline runs Cancel running pipeline executions Access workspace monitoring capabilities Not Allowed Create, edit, or delete pipelines Create, edit, or delete Fabric artifacts Modify notebooks, lakehouses, warehouses, or dataflows Manage workspace access or permissions Change workspace settings Connect/disconnect Git repositories Business Value This role would: Support enterprise segregation of duties requirements. Enable production support teams to resolve operational issues without granting development permissions. Reduce the risk of accidental changes in production workspaces. Improve governance and compliance. Align Microsoft Fabric with operational models commonly used in enterprise data platforms. Many organizations need a role that sits between Viewer and Contributor, providing operational control without development privileges. An Operator role would significantly improve security, governance, and supportability for Fabric Data Factory workloads. Use Case: Production support team monitors Fabric pipelines, investigates failures, and reruns failed executions, but should not be able to modify pipeline definitions or other workspace assets.30Views1like0CommentsConnectivity patterns in Microsoft Fabric: A guide for data integration workloads
This blog post focuses on connectivity options for Microsoft Fabric workloads that use Data Factory runtime components, including Dataflow Gen2, Fabric Data Pipelines, Fabric Copy Job, Fabric Mirroring, Power BI semantic models, and Power BI paginated reports. The guidance and networking considerations described in this article apply to the above data integration scenarios of Fabric. Workloads such as Notebooks, Spark Job Definitions (SJD), and other Spark-based experiences are not covered by this guidance. These workloads use the Fabric Managed Virtual Network (Managed VNet) for data access and therefore follow a different connectivity model and network architecture. Enterprise data rarely lives in a single location. It is often distributed across public cloud services, Azure virtual networks, on-premises environments, and software-as-a-service applications. Microsoft Fabric must have a supported network path to each data source before workloads can access it. The appropriate connectivity option depends primarily on the source network location and whether Fabric must cross a private network boundary. This guide will help you determine when to use a VNet data gateway, an on-premises data gateway, or a direct cloud connection for data integration scenarios of Fabric. A simple way to choose the right option is to start with one question set: Where does the data source live, and does Fabric need to cross a private network boundary to reach it? Why gateway choice matters The connectivity model determines how Fabric reaches data sources and can affect security, governance, operational overhead, and network architecture decisions. Before users can build semantic models, pipelines, reports, notebooks, or analytical experiences, the platform needs a reliable way to reach the data. A gateway acts as an intermediary between a supported Fabric workload and a data source. It establishes the required connectivity path, relays supported queries or data requests and returns results to the calling service. The exact data movement and processing behavior depends on the Fabric workload, connector, connection mode, and gateway type. Gateways provide secure connectivity to private data sources through outbound-only communication and encrypted data transfer, eliminating the need to expose internal systems to the public internet. In Microsoft Fabric, that connectivity decision can affect how securely Fabric reaches the source, whether infrastructure needs to be deployed or maintained, whether the connection can be shared across teams, and how well the pattern fits enterprise governance requirements. Selecting the right connectivity pattern early can help prevent architecture changes later. For example, a source protected by private endpoints may require a different approach than a publicly accessible SaaS application, while an on-premises SQL Server deployment often has different requirements than a cloud-to-cloud integration scenario. Option 1: VNet data gateway Use a VNet data gateway when a supported data source is reachable from an Azure virtual network and is not intended to be accessed through a public endpoint. The source might use a private endpoint, reside in a connected virtual network, or be reachable from Azure through an appropriately configured private network path, such as ExpressRoute. VNet data gateway provides a Microsoft-managed connectivity option for supported data sources that are reachable through an Azure virtual network. Organizations can enable private connectivity without deploying or maintaining gateway virtual machines, making this a good option when you need private network access without managing additional infrastructure. When to use it The data source is reachable from an Azure virtual network. The scenario requires private connectivity, such as access through a private endpoint or an ExpressRoute-connected network. Fabric workloads that need secure and scalable access to data sources enabling Dataflow Gen2, Data Pipelines, Copy Job, Mirroring, Semantic Models, and Paginated Reports to access enterprise data Your organization prefers Microsoft-managed gateway rather than deploying and maintaining gateway virtual machines. The required Fabric workload, connector, authentication method, and region are supported. The Azure virtual network has the required network configuration and available capacity. Key benefits Microsoft-managed infrastructure: Microsoft operates the gateway infrastructure, reducing the need to deploy and maintain gateway virtual machines. Private network reachability: Supported Fabric workloads can connect to sources reachable from the Azure virtual network. Network isolation: Data sources can remain behind private network boundaries instead of requiring public endpoints. Hybrid reachability: Sources connected to the virtual network through supported network paths, including ExpressRoute, can be reachable without deploying the gateway directly in the on-premises environment. Capacity management: Supported scaling capabilities can help accommodate changing workload demands while reducing manual infrastructure management. Centralized connectivity: Administrators can configure and govern shared connections for supported workloads and users Option 2: On-premises Data Gateway, standard mode The on-premises data gateway is customer-managed software that runs on a supported machine in a network that can reach the data source. The gateway can be installed on an on-premises server or on a supported virtual machine, depending on the organization’s network design and operational requirements. Standard mode supports shared connectivity across approved users, connections, and workloads. Your organization is responsible for deploying, updating, monitoring, and maintaining the gateway host. When to use it The data source resides within an on-premises environment or a private network that is not directly accessible from Microsoft cloud services. You're able to provision and manage the required gateway infrastructure, including virtual machines, software updates, monitoring, and lifecycle maintenance. Multiple users or workloads need access, and the gateway should be centrally managed. You need enterprise-grade sharing and governance across Fabric, Power BI, Power Apps, Power Automate, Logic Apps, or Azure Analysis Services. Key Benefits Securely access on-premises and private-network data sources from Microsoft Fabric. Reuse existing network, firewall, and security investments without exposing data sources to the public internet. Centrally manage and govern connectivity for multiple users, teams, and workloads. Support hybrid and multi-cloud integration scenarios from a single gateway platform. Improve reliability and scalability through gateway clustering and high-availability deployments. Accelerate Fabric adoption by leveraging existing infrastructure and operational processes. Option 3: Cloud connection with no gateway Use a cloud connection with no gateway when the source is already cloud-based and publicly accessible. In this scenario, Fabric can connect directly to the service without traversing a private networking layer. Fabric can connect directly to the service using the supported connector and authentication method. This is often the simplest connectivity path. If the source is a public SaaS application, cloud API, or cloud data service that does not require access through a private network, then a gateway may not be needed. When to use it The source is fully cloud-based and publicly reachable. There is no private endpoint or private network boundary. Direct SaaS or cloud-to-cloud connectivity is supported. You do not need gateway infrastructure or runtime management. Common connectivity scenarios The following examples illustrate common Microsoft Fabric connectivity patterns and can help simplify gateway selection. Depending on the network architecture, some on-premises data sources may be reachable through either On-premises Data Gateway or VNet data gateway. Azure SQL Database with a private endpoint: If Azure SQL Database is accessible only through a private endpoint or a virtual network, use a VNet data gateway. This allows Fabric workloads to securely access the data source without requiring public network access. Azure Storage account secured through virtual network rules: When a storage account is protected by Azure virtual network restrictions and cannot be accessed through a public endpoint, a VNet data gateway is typically the appropriate choice. On-premises data sources connected to Azure through ExpressRoute: Organizations often use Azure ExpressRoute to extend their on-premises network into Azure. When a supported data source remains on-premises but is reachable from an Azure virtual network through ExpressRoute, a VNet data gateway can provide private connectivity from Fabric without requiring customer-managed gateway infrastructure. This can simplify operations while maintaining private connectivity between Microsoft Fabric and the data source. SQL Server hosted in an on-premises datacenter: If the data source resides within a corporate datacenter or private network and is not reachable from Azure virtual networks, use On-premises Data Gateway (standard mode) to provide shared, enterprise-grade connectivity. Line-of-business applications hosted behind a corporate firewall: Applications such as SAP HANA, Oracle, or other supported data sources that are accessible only from the corporate network generally require On-premises Data Gateway (standard mode). Cloud services with public endpoints: For supported cloud services such as Salesforce, Azure SQL Database (public endpoint), Azure Data Lake Storage Gen2 (public endpoint), or other publicly accessible SaaS and PaaS offerings, Fabric can often connect directly without requiring a gateway. Although these examples represent common deployment patterns, always verify connector support, authentication requirements, networking configuration, regional availability, and workload compatibility when designing your connectivity architecture. Final takeaway When planning Microsoft Fabric connectivity, start with the location of the data source and determine whether Fabric must traverse a private network boundary. That single decision typically determines whether a VNet data gateway, an On-premises Data Gateway, or a direct cloud connection is the appropriate choice. Use VNet data gateway when you need managed gateway to securely connect Microsoft Fabric workloads to data sources protected by Azure Virtual Networks, private endpoints, or on-premises environments that are connected to Azure through ExpressRoute. Use On-premises Data Gateway standard mode for self-hosted shared enterprise access to on-premises or private firewall sources. Use a cloud connection without a gateway when the supported cloud data source is reachable directly through its public endpoint and the scenario does not require a private network path. By using this decision flow, teams can design cleaner, more secure, and easier-to-manage connectivity patterns for Microsoft Fabric. Next steps Use the decision flow in this article to identify the connectivity model that best aligns with your data source location, network architecture, and operational requirements. Before implementation, review the supported workloads, connectors, authentication methods, and regional availability for your specific scenario. To learn more, explore: Microsoft Fabric documentation VNet data gateway documentation On-premises data gateway documentation Microsoft Fabric security documentation By selecting the appropriate connectivity option early in your architecture design, you can simplify deployment, improve security, and reduce ongoing operational overhead while enabling reliable access to enterprise data. For additional guidance, review the Microsoft Fabric connectivity and gateway documentation to confirm support for your workloads, connectors, authentication methods, and regions.457Views1like0CommentsOn-premises data gateway June 2026 release
The June 2026 release of the on-premises data gateway is version 3000.322. This new version (3000.322) continues our focus on improving gateway manageability, operational visibility, and enterprise governance while maintaining secure and reliable connectivity between on-premises data sources and Microsoft Fabric services. Windows broker authentication update The June 2026 release introduces support for Windows Web Account Manager (WAM) authentication, helping organizations improve token security and align gateway authentication with Microsoft's modern identity platform. This change reduces administrative complexity while providing stronger protection for authentication tokens. Learn more by exploring Acquire a token to call a web API by using Web Account Manager (desktop app). Apache Log4j update To further strengthen gateway security, this release updates the bundled Apache Log4j library to version 2.25.4. The update addresses vulnerabilities identified in the previous version and helps organizations maintain a secure gateway environment. New diagnostics capabilities Organizations can now enable gateway diagnostic uploads through a consent-driven model that provides greater control over how operational data is shared. Enable the Diagnostics settings, when enabled the diagnostic information can help accelerate troubleshooting and provide richer insights when investigating gateway issues. Diagnostic information is also integrated directly into the Dataflow Gen2 run experience, allowing administrators and support teams to access relevant insights without switching between multiple tools and diagnostic sources. Note: Your gateway must be running the latest On-premises Data Gateway version to use these diagnostic capabilities. We strongly recommend keeping the on-premises data gateway updated to the latest version to take advantage of new capabilities, security improvements, and troubleshooting. enhancements. Gateway administrators can initiate gateway updates directly from the Manage connections and gateways experience in Microsoft Fabric. Power BI Desktop compatibility This update brings the on-premises data gateway up to date with the June 2026 release of Power BI Desktop. Download on-premises data gateway (standard mode) Download on-premises data gateway (personal mode) This version of the gateway will ensure that the reports that you publish to the Power BI Service and refresh via the gateway will go through the same query execution logic/run-time as in the June version of Power BI Desktop. Thank you! Upgrade to version 3000.322 to take advantage of the latest security, authentication, and diagnostics improvements. We encourage you to share feedback and feature requests through the Power BI Ideas forum to help shape future gateway investments.11KViews3likes46CommentsIdentifying Toe on Phaseouts/ Closeouts
Hello, I've noticed on all daily reports that the toe type is not listed in the Phaseout or Closeout section. Is there a way to add this important information to the daily reports. When we send out these reports the customer needs to know if it is Steel Toe, Soft Toe or Composite Toe. Thank you! David Loya Key Account Manager Work Group11Views0likes0CommentsCopy job for SAP with ABAP Add-On in Microsoft Fabric (Preview)
SAP systems sit at the center of many enterprises’ core business operations, powering processes across finance, supply chain, manufacturing, procurement, and HR. That makes SAP data some of the most business-critical data in the enterprise. As organizations modernize their analytics and AI platforms, bringing SAP data together with the rest of the enterprise data estate has become increasingly important. But moving SAP data at enterprise scale has historically been difficult. SAP landscapes are complex, data volumes are large, and extraction architectures often require specialized frameworks, custom code, and additional operational layers. For many organizations, this creates friction between where their most important operational data lives and where they want to analyze, enrich, and activate it. We are delivering the next step of our SAP roadmap: Copy job for SAP with ABAP Add-On in Microsoft, this new capability complements offerings like: SAP Business Data Cloud Connect was announced in SAP and Microsoft accelerate business insights and AI innovation with SAP Business Data Cloud Connect for Microsoft Fabric and will be available over the coming months). It will enable bi-directional zero-copy sharing between SAP Business Data Cloud and Microsoft Fabric without the need for data movement. Mirroring via SAP Datasphere, a turnkey data replication capability providing scalable near real-time data movement from SAP sources into Fabric OneLake (Generally Available). To learn more, refer to the Fabric mirroring documentation. Now, organizations can extract large volumes of SAP data through Copy job, reduce the need for external extraction frameworks, and build a scalable path from initial ingestion to ongoing incremental updates. Copy job provides a configuration driven experience for moving data across clouds, applications and on-premises systems – designed to support high-scale, multi-cloud data movement for petabyte-scale ingestion scenarios. Copy job helps bring data into OneLake as part of a unified, governed foundation for analytics and AI. High-performance SAP extraction with Copy job and Microsoft ABAP add-on integration This new integration option enables scalable, high-throughput extraction from SAP systems, making it easier than ever to bring large volumes of SAP data into Microsoft Fabric for analytics, reporting, and AI. Figure: High-level architecture diagram of Copy job with ABAP Add-on. Broad data coverage across SAP Systems Extracting data from SAP systems at scale can be complex and resource intensive. This new capability simplifies the process while delivering high performance. The solution runs directly inside SAP using a Microsoft-provided ABAP Add-On. Data is extracted at the application layer and transferred efficiently through Copy Job in Fabric Data Factory. This removes the need for complex external extraction frameworks and reduces operational overhead. It supports a wide range of SAP data sources. You can extract from SAP tables, views, and ABAP CDS views, including semantically rich models used for analytics. The capability works across both SAP ECC and SAP S/4HANA, whether deployed on-premises or in the cloud. Providing consistent access to both raw operational data and business-ready data models. Flexible data delivery styles for real-world SAP scenarios Through the integration with Copy Job, the solution handles data movement at scale. The integration is designed for high throughput and efficient processing of large datasets. Parallel execution capabilities help accelerate ingestion and reduce data transfer times. The solution supports different loading strategies depending on your needs. You can perform full snapshots for initial ingestion or bulk replication scenarios. For ongoing updates, incremental loads can be configured using watermark-based extraction. This allows you to process only the data that has changed. Together, these capabilities make it easier to design efficient pipelines. You can start with a large initial load and then transition seamlessly to incremental updates, without changing the overall architecture. SAP data in OneLake, ready for analytics and AI After ingestion, SAP data is immediately available in Microsoft OneLake. From there, it can be used across the entire Fabric platform. You can build Power BI reports directly on SAP data and operational datasets. You can run large-scale analytics workloads or combine SAP data with non-SAP sources from across your organization creating a unified data foundation without silos. With all data in one place, it also becomes easier to enable AI-driven scenarios. Applications and data agents can access consistent, trusted business data to generate insights and drive automation. Get started For more information, refer to the ABAP Add-On for SAP data extraction with Copy Job in Microsoft Fabric documentation. You can start exploring this capability today to: Accelerate SAP data ingestion Simplify data extraction architectures Enable scalable analytics and AI scenarios Looking ahead Copy job for SAP with Microsoft ABAP Add-On is another step in our continued investment in SAP data integration for Microsoft Fabric. SAP is one of the most important enterprise data sources for our customers, and Data Factory in Fabric is designed to help organizations bring SAP and non-SAP data together through scalable, flexible data movement experiences. With Copy job, customers can move data across clouds, applications, and on-premises systems into OneLake. With the Microsoft provided ABAP Add-On, that same Copy job experience now extends more deeply into SAP, helping customers bring business-critical SAP data into Fabric for analytics, reporting, and AI. We will continue expanding SAP data integration capabilities across Microsoft Fabric so customers can simplify their data architectures, reduce silos, and build a unified, governed foundation for enterprise analytics and AI.3.4KViews1like3CommentsFirst Look at Microsoft Fabric
Join us for an exciting session as we dive into the world of Microsoft Fabric and explore its powerful capabilities. In this session, Mim, a seasoned expert in data engineering and analytics, will take you on a journey through the intricacies of building a full data pipeline using Microsoft Fabric. Throughout the demonstration, Mim will showcase how to leverage various cutting-edge technologies, including Python Notebook, OneLake Storage, and PowerBI Direct Lake Mode, to create a seamless and efficient data workflow. You'll get a firsthand look at how these tools can be integrated within Microsoft Fabric to enhance your data processing and analysis capabilities. In addition to the technical aspects, Mim will share valuable insights and observations on Fabric's pricing model. Understanding the financial implications of utilizing Microsoft Fabric is crucial for organizations aiming to optimize their resources and budget effectively. Mim will shed light on the different pricing structures, helping you make informed decisions when incorporating Fabric into your data ecosystem. Whether you're a data engineer, data scientist, or an analytics enthusiast, this session will provide you with a solid foundation in utilizing Microsoft Fabric for building efficient data pipelines. Don't miss out on this opportunity to gain valuable knowledge and practical insights from an industry expert. 𝙋𝙚𝙧𝙨𝙞𝙖𝙣 𝙋𝘽𝙄𝙐𝙂- 𝙈𝙞𝙘𝙧𝙤𝙨𝙤𝙛𝙩 𝘾𝙤𝙢𝙢𝙪𝙣𝙞𝙩𝙮: Link 𝙇𝙞𝙣𝙠𝙚𝙙𝙄𝙣: https://bit.ly/32tGkif 𝙏𝙚𝙡𝙚𝙜𝙧𝙖𝙢 𝘾𝙝𝙖𝙣𝙣𝙚𝙡: https://t.me/PersianPBIUG 𝙔𝙤𝙪𝙏𝙪𝙗𝙚: https://bit.ly/3hk20RL Language: English254Views0likes0Comments