Verifying private network paths before you deploy: a what-if for Azure private endpoints
A common Azure scenario: public access is disabled on a PaaS resource, a private endpoint is created, and the connection shows as Approved. The application still times out. Resource-level checks such as what-if report nothing wrong, because every resource is configured. What they do not verify is whether the name the application uses resolves to the private address from the application's VNet. In my experience, most private connectivity failures come from DNS configuration, not from firewall rules. What must be true For a workload in a VNet to reach a PaaS service privately: The private endpoint connection is Approved. The matching privatelink private DNS zone exists. The zone is linked to the VNet that performs the lookup. The zone contains an A record for the resource. If the VNet uses custom DNS servers, they forward privatelink zones to Azure DNS (168.63.129.16) or to an Azure DNS Private Resolver. The third point is the one that is easy to miss: the zone and the record exist, but the VNet performing the lookup cannot see the zone, so the name resolves to the public address. An approach: check the whole path in one command I wrote a small, read-only script that takes a target resource and a source VNet, then reports PASS, WARN, or FAIL for each requirement above, with a suggested fix. It uses the Azure CLI and needs only Reader access. Checks performed: publicNetworkAccess on the target resource Private endpoint connections and their approval state Expected privatelink zone for the endpoint's group id Whether the zone is linked to the source VNet Whether the zone has an A record for the resource Whether the source VNet uses custom DNS servers (reported as a warning for manual review) It exits with code 1 on any failure, so it can run as a pipeline gate after a Dev deployment. Limitations It does not test the network path itself (NSGs, firewalls, routing, ports). Azure Network Watcher covers that. It reads configuration and does not resolve DNS from inside the VNet. A real lookup from a VM in the VNet remains the final proof. In hub-and-spoke designs, the hub VNet may need to be passed as the source. The built-in zone table covers a few services (storage, Key Vault, SQL, Databricks) and needs extending for others. Why I think this matters for AI-assisted infrastructure Script and sample pipeline: Ping me or message me When infrastructure code is generated by an AI assistant, a private endpoint without its DNS zone link is a plausible output: the code is valid and the deployment succeeds. Independent, read-only checks like this one are the kind of gate that lets teams review generated changes with confidence. Questions for the community Which private endpoint failure costs your team the most troubleshooting time? How do you manage DNS in hub-and-spoke networks: Private Resolver, DNS forwarders, or another pattern? Would a check like this be more useful as an Azure Policy, a Network Watcher feature, or a pipeline step? Which services should be added to the DNS zone table first? Shivanna GundanavarMicrosoft Agent 365 and Azure API Management integration for MCP governance
As agents gain access to enterprise tools, organizations need consistent ways to govern what those agents can access and enforce those decisions at runtime Today, we're announcing a new integration between Microsoft Agent 365 and Azure API Management now in public preview. The integration connects centralized governance in Agent 365 with runtime enforcement for MCP servers and tools through Azure API Management for V2 and AI Gateway tiers. With this integration, AI administrators can discover and govern gateway managed MCP servers and tools from Agent 365 and application platform teams use Azure API Management, to enforce those access decisions at runtime. Microsoft Defender and Microsoft Purview add additional layers of protection by evaluating tool requests and results for threats and sensitive information risks. Centralized governance, enforced at the gateway Agent 365 and Azure API Management play complementary roles. Agent 365 defines governance intent, maintains inventory, and manages access decisions. Azure API Management enforces those decisions inline for traffic to MCP servers and tools. Together, they connect the enterprise governance experience with the infrastructure platform teams already use to manage access to business systems. Administrators can make supported access decisions from Agent 365, while enforcement happens at the gateway in the customer's Azure environment. For agents already using a configured gateway endpoint, that connection remains in place. Customers can extend governance to their existing gateway-managed tools without rearchitecting those agents or moving tools out of their Azure subscriptions. Discover tools and control what agents can do The integration brings together four key capabilities: Discover existing gateways and MCP servers. After a one-time tenant-level consent, Agent 365 discovers supported Azure API Management resources and the MCP servers they expose, removing manual registration. Maintain a centralized inventory. Administrators can find gateway-managed MCP servers in Agent 365 and inspect available metadata, bringing these assets into a shared governance experience. Control access at the right level. Block or unblock an entire MCP server. With the Azure API Management AI Gateway tier (preview) they can apply more granular controls by blocking individual tools without disabling the server. Use runtime signals for oversight. Tool activity observability on AI Gateway tier supports monitoring, auditing, and incident investigation, connecting access decisions with what happens at runtime. Add protection before tools run and before results return Controlling which tools agents can access is one part of the governance model. Organizations also need protection for information flowing through those tools . The Agent 365 tool threat protection policy (supported in the AI Gateway tier) uses Microsoft Defender and Microsoft Purview capabilities to evaluate tool requests and results for risks such as malicious content, prompt injection, and exposure of sensitive information. Platform teams can configure evaluation before tool invocation, after invocation, or at both stages. With blocking configured, pre-invocation evaluation can prevent a disallowed call from executing. Post-invocation evaluation can withhold unsafe results before they reach the agent. Build on open standards and existing investments This integration connects centralized governance with enforcement where agents access tools, while building on the infrastructure organizations already operate. MCP provides a common interface for tool access. Azure API Management provides the gateway boundary for applying policy, security, and observability. Agent 365 brings those gateway-managed assets into a centralized governance experience, with Microsoft security capabilities adding protection along the tool-call path. The goal is not to make every agent use the same runtime. It is to help organizations apply governance to tools reached through supported gateway endpoints, bringing AI administrators, platform teams, and security teams closer together, while preserving the existing architecture. Get started API Management v2 tiers support centralized MCP inventory and server-level blocking and unblocking through Agent 365.The AI Gateway tier adds more granular capabilities including individual-tool blocking, tool activity observability, and tool threat protection . Start with the Agent 365 integration guide, explore tool threat protection with Defender and Purview, and configure your gateway in the AI Gateway portal.Optimizing Oracle-to-Power BI Performance and the Path to Modern Analytics
Organizations frequently rely on Oracle databases for large-scale operational workloads while using Microsoft Power BI as their enterprise analytics and visualization platform. Although connecting Power BI directly to Oracle is fully supported, performance can become challenging as datasets grow into the millions of rows. A recent enterprise scenario involving millions of Oracle records illustrates an important principle: Oracle-to-Power BI performance should not be attributed to a single component without first isolating the entire retrieval path. This article provides a practical framework for optimizing that architecture today, while also examining how Microsoft Fabric Mirroring can provide a different data-access pattern for future analytics workloads. The Performance Challenge Consider an Oracle environment containing approximately 15 million records. Testing showed substantially different behavior depending on the client used to retrieve the same Oracle data: A direct Oracle query executed through TOAD returned millions of rows in about eight minutes. Tableau connected to the same Oracle table from the same laptop and refreshed millions of rows in 20 to 30 minutes. Power BI Desktop, however, continued processing for multiple hours before the operation was terminated by network or database controls. Importantly, the Power BI query did not contain additional Power Query transformations. The customer was directly executing SQL and loading the resulting data. This is an extremely useful diagnostic comparison because it demonstrates that Oracle is capable of returning the underlying dataset considerably faster than the Power BI test. It does not, however, prove that the Power BI Oracle connector itself is the single root cause. Performance Is a Pipeline, Not a Single Component Oracle-to-Power BI performance involves several layers: A bottleneck at any one of these layers can affect overall refresh or query performance. Therefore, the first architectural principle is: Measure every layer before attempting to tune the entire solution. A troubleshooting exercise should evaluate: Oracle server-side execution time SQL execution plan Oracle provider/client behavior FetchSize behavior Network transfer Power Query evaluation Query folding Power BI model processing Report design Gateway behavior when the Power BI Service is introduced This approach avoids prematurely concluding that Oracle, Power BI, the gateway, or the connector is inherently responsible for the slowdown. Start With the Oracle Provider Power BI currently provides two important approaches for Oracle connectivity. Built-in Oracle provider Modern versions of Power BI Desktop include Microsoft's bundled Oracle Managed ODP.NET provider. This reduces the dependency on separately installing Oracle client software. For environments using the built-in provider, testing should be performed with a current Power BI Desktop release because provider behavior and defaults can change between releases. Oracle Client for Microsoft Tools Oracle Client for Microsoft Tools, or OCMT, remains another supported option. OCMT configures Oracle Data Provider for .NET and can therefore be tested independently from the built-in provider. This gives architects a useful isolation mechanism: Test A: Built-in Oracle provider vs. Test B: OCMT provider. Use the same: workstation SQL statement Oracle database table credentials network path expected row count Changing several variables simultaneously makes the results considerably harder to interpret. Understand FetchSize One of the most important areas identified during troubleshooting is FetchSize. FetchSize controls how much data the Oracle provider retrieves during each fetch operation. For large datasets, a small FetchSize can require many retrieval operations, increasing overhead. Increasing FetchSize allows the provider to retrieve more data at a time and may improve throughput. However, FetchSize tuning should be tested independently from the choice of Oracle provider. Switching to OCMT, for example, does not by itself demonstrate whether FetchSize tuning improves performance. Benchmark the same SQL and dataset using consistent test conditions and compare elapsed time and throughput. FetchSize controls how much Oracle data the provider pulls back in each retrieval batch. Think of FetchSize like the size of a delivery truck. Imagine Power BI needs to retrieve a very large dataset from Oracle. Small FetchSize: Oracle → 📦 → Power BI Oracle → 📦 → Power BI Oracle → 📦 → Power BI Oracle → 📦 → Power BI ...many retrieval operations Larger FetchSize: Oracle → 📦📦📦📦📦 → Power BI Oracle → 📦📦📦📦📦 → Power BI ...fewer retrieval operations The idea is simple: FetchSize determines how much data the Oracle provider fetches at a time. Examine Oracle Data Types FetchSize is not the only provider consideration. Schema matters. A troubleshooting package should include the table DDL rather than only a list of column names. Pay particular attention to large-object types such as: BLOB CLOB Large-object columns may materially change retrieval behavior and can make simply increasing FetchSize insufficient. Therefore capture: complete table DDL column names Oracle data types row width presence of BLOB/CLOB columns expected total result size Do not optimize FetchSize without understanding the shape of the data being transferred. Filter Rows and Columns as Early as Possible Probably the most universally applicable Power Query optimization is also one of the simplest: Do not retrieve data you do not need. Instead of retrieving every row and column and filtering afterward, reduce the dataset at Oracle whenever possible. Good Oracle SQL should therefore: select only required columns apply restrictive predicates at the source aggregate at Oracle where appropriate avoid unnecessary data transfer This matters substantially when Power BI and Oracle are separated by a network boundary. Preserve Query Folding Power Query query folding allows Power BI transformations to be translated back into SQL executed by the relational source. For relational sources such as Oracle, maintaining folding can substantially reduce the amount of work performed by the Power Query mashup engine. The preferred pattern is: Where practical: filter early remove unnecessary columns early avoid transformations that unexpectedly break folding inspect where folding stops push relational operations back into Oracle For DirectQuery, folding is particularly important because the source remains part of the interactive report-query path. Be Careful With Native SQL and Incremental Refresh Native SQL can be extremely valuable for troubleshooting. Running the same targeted SELECT statement through Power BI that is executed directly against Oracle creates a useful A/B test. It helps isolate questions such as: Is Oracle itself taking a long time? Is Power BI generating a different query? Is additional processing happening after Oracle returns the data? Is the retrieval/provider layer adding significant latency? However, architecture matters. Power BI guidance warns that later Power Query steps cannot necessarily fold after a native SQL query, and native SQL has important implications for incremental refresh. Therefore, native SQL is useful both as an optimization technique in some architectures and as a diagnostic isolation technique, but it should not automatically be substituted for a well-folded Power Query design. Prefer Import for Traditional Oracle BI Workloads If the business does not require near-real-time data, Import should generally be evaluated before DirectQuery for large Oracle analytical workloads. With Import: The latency of Oracle, networking, and the provider is mostly experienced during refresh rather than repeatedly during user interaction. This usually provides a more predictable interactive experience. DirectQuery produces a different dependency chain: As a result, source latency can become report latency. Use DirectQuery when its architectural benefits are required, rather than simply because the source database supports it. Make Incremental Refresh Truly Incremental Import does not necessarily mean repeatedly loading the entire Oracle dataset. For large fact tables, incremental refresh should be evaluated so that only required partitions are refreshed. However, there is an important condition: RangeStart and RangeEnd filtering needs to be pushed back to Oracle. If partition filters do not fold, Power BI can end up retrieving considerably more source data than expected before applying the filtering. Therefore incremental refresh testing should verify that the Oracle query generated by Power BI contains the expected predicates. Treat the Gateway as Its Own Performance Layer Once the workload moves into the Power BI Service, however, the on-premises data gateway becomes another measurable component. For production deployments examine: gateway version Oracle provider/client version CPU memory network proximity to Oracle refresh concurrency DirectQuery concurrency competing workloads Where necessary, large refresh workloads and latency-sensitive DirectQuery workloads can be isolated onto different gateway resources. Do not diagnose gateway performance from a Power BI Desktop test where the gateway is not involved. Optimize DirectQuery If It Cannot Be Avoided Sometimes Import is not viable because users require data with very low latency. If Oracle must remain behind DirectQuery, reduce unnecessary work at every level. At Oracle index frequently filtered columns appropriately review execution plans select only necessary columns reduce returned rows avoid unnecessarily expensive calculations In Power Query maintain query folding push filtering to Oracle minimize transformations requiring local evaluation In the semantic model use efficient dimensional modeling avoid unnecessary high-cardinality columns consider aggregation strategies where appropriate In reports limit visual density use selective filters avoid generating unnecessary simultaneous source queries test with realistic user concurrency DirectQuery performance needs to be assessed as an end-to-end architecture, rather than as an individual SQL benchmark. Collect Diagnostics Before Declaring a Root Cause For difficult Oracle performance cases, establish a repeatable diagnostic package. Capture: Oracle database version execution plan SQL execution duration table DDL data types row count approximate returned data size Provider built-in provider versus OCMT provider/client version FetchSize configuration Power BI Power BI Desktop version generated SQL Query Diagnostics Mashup traces Applied Steps or M code total execution time Network Oracle-to-client path throughput latency connection interruptions or timeouts Comparison clients If Tableau or another Oracle client appears dramatically faster, reproduce the same SQL, same columns, same records, same database and preferably the same machine. Only then does the comparison become a useful engineering benchmark. Future Architecture: Oracle Mirroring in Microsoft Fabric Optimizing the direct Oracle connection solves one class of problem. Microsoft Fabric Mirroring provides a different architecture altogether. Instead of repeatedly placing Oracle in the analytical query path, Fabric can continuously replicate Oracle changes into OneLake. Conceptually: Fabric Mirroring uses Oracle LogMiner to capture changes and maintain an analytical copy in OneLake. This separates many downstream analytical reads from the operational Oracle database. The key architectural advantage isn't simply "a faster connector." The advantage is decoupling analytics from the operational database. Recommended Architecture Decision Tree Requirement: traditional BI with scheduled freshness Use: Oracle → Import → Power BI semantic model. Then optimize: FetchSize provider query folding source-side filtering incremental refresh Requirement: operational or near-real-time reporting where Oracle must remain the source Evaluate: Oracle → DirectQuery → Power BI. But aggressively optimize: Oracle SQL execution plans query folding visual density provider configuration concurrency gateway architecture Requirement: enterprise analytics with frequent Oracle changes and growing BI/AI requirements Evaluate: Oracle → Fabric Mirroring → OneLake → Fabric / Power BI. This reduces repeated analytical pressure against the operational Oracle environment and creates a reusable analytical data foundation for additional workloads. A Practical Troubleshooting Sequence A useful Oracle-to-Power BI performance investigation can be organized into five phases. Phase 1: Establish the Oracle baseline Execute exactly the same query directly against Oracle. Record: SQL → rows → bytes → execution time Phase 2: Isolate the provider Run the same dataset through: Built-in Oracle provider and OCMT. Record the results independently. Phase 3: Test FetchSize Test controlled FetchSize values while holding every other variable constant. Measure throughput rather than relying on subjective impressions. Phase 4: Optimize Power Query Validate: query folding source filtering column projection transformations incremental refresh behavior Phase 5: Decide whether the architecture itself should change If extremely large Oracle datasets must continually feed analytical workloads, consider whether repeatedly querying Oracle remains the appropriate long-term design. At that point, Fabric Mirroring becomes an architectural discussion rather than simply another troubleshooting step. Final Takeaway Oracle-to-Power BI performance problems should not immediately be categorized as an Oracle problem, a Power BI problem, or a gateway problem. They are usually best investigated as a data retrieval pipeline. For existing Power BI architectures, the strongest optimization sequence is: Efficient Oracle SQL For the longer term, Microsoft Fabric Mirroring changes the architecture: Oracle becomes the operational system of record while OneLake becomes the analytical data plane. That separation can be particularly valuable as organizations expand from traditional Power BI reporting into broader Fabric analytics, data engineering and AI workloads.
Cannnot delete tenant
Hello, I am trying to delete one of our customers MS 365 Tenant, however this seems to keep failing due to a single Application Registration which cannot be deleted through Entra ID. The error i am getting is "Failed to delete application Tenant Schema Extension App. Error detail: Deletion of system application is not allowed." I have looked online for solutions but the only solution i can find is "Create a support ticket". I would love to do this but there is no support contract linked to this tenant so that option is not available. Any help would be appreciated! Kind regards, Jos Verhallen
What is the best way to handle networking during a long-running cloud migration?
Hi everyone, I'd like to get some opinions from people who have worked on large-scale cloud migrations. Consider a migration where workloads are gradually moved from AWS to Azure over several weeks or months rather than being migrated in a single cutover. During the migration period, both environments need to remain operational. A simplified architecture could look like: AWS workloads | | Existing connectivity | AWS Network | | Inter-cloud connectivity | Azure Network | | Azure workloads The challenge is that applications may temporarily become distributed across both clouds. For example: • Application servers may still be running in AWS. • New application components may already be deployed in Azure. • Databases or shared services may remain in AWS temporarily. • DNS and routing may need to support both environments. • Migration tools may require connectivity to source and target environments. • Some workloads may be migrated much earlier than their dependent services. For a long-running migration like this, what architecture would you recommend? Some options I have been considering are: 1. Site-to-site VPN between AWS and Azure 2. Dedicated connectivity such as AWS Direct Connect + Azure ExpressRoute 3. A combination of dedicated connectivity and VPN for backup 4. A hub-and-spoke architecture in Azure with controlled connectivity back to AWS 5. Application-level connectivity rather than relying heavily on network-level connectivity Another question is how you would handle routing. Would you prefer to: • Keep AWS and Azure routing domains mostly independent? • Use a centralized hub for cross-cloud traffic? • Advertise routes dynamically using BGP? • Restrict cross-cloud communication to only the application dependencies that require it? For a migration lasting several months, what approach have you found to be the most reliable and easiest to operate? I'm particularly interested in lessons learned around: • Routing • DNS • Security • Latency • Failover • Monitoring • Avoiding unexpected cross-cloud traffic costs Would appreciate experiences from anyone who has handled a production AWS-to-Azure or Azure-to-AWS migration.Should AI agents receive permissions dynamically instead of having fixed access?
Hi everyone, As AI agents move from simple chat-based assistants toward performing real actions—such as querying databases, creating resources, modifying configurations, sending notifications, or executing workflows—I have been thinking about how their permissions should be designed. A traditional application typically has a relatively well-defined permission model. An AI agent, however, may perform different tasks depending on the conversation and the user's request. For example: • Task A may only require read access. • Task B may require creating a resource. • Task C may require modifying an existing configuration. • Task D may involve a potentially destructive operation. This raises an interesting security question: Should an AI agent have a fixed set of permissions for its entire lifetime, or should permissions be granted progressively based on the task it is currently performing? For example: User → AI Agent → Read-only permissions Then, if the user explicitly requests a change: User approval → Temporary elevated permission → AI Agent performs the operation → Permission revoked I see some potential advantages to this approach: 1. Reduced blast radius if the agent behaves unexpectedly. 2. Better alignment between permissions and the actual task. 3. Easier auditing of elevated operations. 4. Reduced risk from prompt injection or unintended actions. 5. Human approval could be required only for high-impact operations. However, it also introduces additional complexity around identity, token issuance, approval workflows, session management, and auditing. I'm curious how others are approaching this. Would you prefer: A. Fixed least-privilege permissions for each agent B. Dynamic/task-based permissions C. Fixed permissions with human approval for sensitive operations D. A combination depending on the workload For production AI agents, which model do you think provides the best balance between security and usability? Would be particularly interested in experiences from people implementing agents in enterprise environments.
When Should Enterprise AI Workflows Use Azure Logic Apps, Durable Functions, or Power Automate?
As AI-enabled business workflows become more complex, the orchestration layer becomes just as important as the AI model itself. I’m interested in how teams are deciding between Azure Logic Apps, Durable Functions, and Power Automate when building production workflows that may include AI models or agents. For example, consider a workflow such as: AI request → data lookup → business-rule validation → external API call → human approval → final action Some areas I’m particularly interested in: When is Logic Apps the better option for integration-heavy workflows? When do Durable Functions become preferable for stateful or long-running processes? Where does Power Automate fit for business-user-driven automation? How are teams handling retries and partial failures? What patterns work best when an AI agent is only one component of the overall workflow? How are human approval steps being implemented? I’d be interested to hear how others are approaching this architecture in production environments.
Matching customer invoices to multiparty private offers
What’s the best way for a reseller to match an Azure Marketplace customer invoice to its multiparty private offer and subscription in Partner Center? We’ve had invoices missing from our reporting and multiple charges tied to the same offer with different Asset IDs. Which reports or fields should we use to match them? Can we also see whether a credit was issued, or does that require the customer’s billing access or Microsoft Support?
Partner credits (billing profile redemption): Cost Analysis shows $0 everywhere
Hi all, I'm a Microsoft partner (MAICPP, Partner Success Core) and I'm stuck on cost visibility for the Azure credit benefit. Has anyone run into this with the new redemption model? Redeemed the $2,400 Azure credit in Sep 2026 through the new Partner Center flow, where credits are deposited directly onto an MCA billing profile. No separate "sponsored" subscription was created. The credit sits on the billing profile and applies to the subscriptions under it. The subscription runs Azure DevOps and Microsoft Fabric. The problem Billing profile > Payment methods > Azure credits shows the credit as Active, with about $320 already consumed (balance around $2,079). Cost Analysis shows $0.00 for everything, at both subscription scope and billing account scope. Services appear in the breakdown, but every value is zero and Actual cost shows "--". So the credit is clearly being drawn down, but I can't see what is consuming it. What I already know / tried I know Cost Analysis doesn't show credits themselves, but it should still show pre-credit usage cost for an Azure plan subscription. The older threads about Sponsorship subscriptions (MS-AZR-0036P) and microsoftazuresponsorships.com seem to describe the legacy model, not this one. I've seen that Microsoft documents a "Transactions" view on the credit resource for MAICPP credits issued after Aug 1, 2026, but I'm still checking it. Questions Has anyone on the new billing profile model seen Cost Analysis stay at $0 while credits were consumed? Did it eventually fix itself? Where did you finally get per-resource usage? The credit Transactions page, the usage CSV on the invoice, the Cost Details or Consumption APIs, or a support ticket? If you opened a billing ticket, what did support say? Is this expected or a bug? Any tips for budgets or alerts while credits are active, so usage doesn't burn silently? Thanks!
