Configure DNS forwarding for Azure NetApp Files
This post has been written with the collaboration of Rizul Khanna Applies to: Azure NetApp Files — SMB, dual-protocol, and NFSv4.1 Kerberos volumes deployed in hub-spoke or Azure Virtual WAN topologies using an external private DNS forwarder. Overview Azure NetApp Files (ANF) has a hard dependency on DNS for all volume types that integrate with Active Directory (AD): SMB, dual-protocol (SMB + NFS), and NFSv4.1 with Kerberos. Unlike most Azure PaaS services, ANF does not use Azure Private Link and has no privatelink.* zone. Its volumes attach directly to a delegated subnet, and their hostnames are registered into AD-integrated DNS via Secure Dynamic DNS (DDNS). This architecture means DNS design decisions for the ANF delegated subnet are fundamentally different from those that apply to storage accounts, SQL databases, or other services that use private endpoints. This article documents what DNS resolution ANF requires, how to correctly configure an external private DNS forwarder in hub-spoke and Virtual WAN deployments, and the specific undocumented requirements that cause volume creation failures and SMB permission errors in practice. Several requirements covered here are not present in the official Azure NetApp Files documentation and have been identified through field support cases. ANF does not inherit the VNET DNS server setting. It queries only the two DNS server IPs configured in the Active Directory connection on the NetApp account. This is not documented in the ANF networking or AD connection articles. The VNET DNS server setting is irrelevant to ANF volume creation and AD join behavior — only the AD connection DNS IPs matter. Architecture overview The following diagram shows the two separate DNS paths that must be configured when ANF is deployed in a hub-spoke or Virtual WAN topology with an external private DNS forwarder. The client resolution path (VNET DNS setting) and the ANF internal resolution path (AD connection DNS fields) are distinct and must not be conflated. Note: ANF AD connection DNS IPs must point to the external DC IPs directly — not to the private DNS forwarder. The forwarder handles client-side resolution only and must have both forward and reverse rulesets for the AD domain. Figure 1: DNS resolution paths for ANF with an external private DNS forwarder. Client VMs use the forwarder (VNET DNS setting). ANF uses the external AD DC IPs directly (AD connection DNS fields). Both forward and reverse lookup rulesets are required on the forwarder. What DNS must provide for Azure NetApp Files Outbound resolution — ANF querying DNS ANF must be able to resolve the following records from the DNS IPs specified in the AD connection: AD domain controller SRV records: _ldap._tcp.<site>._sites.dc._msdcs.<domain>, _kerberos._tcp.dc._msdcs.<domain>, and site-scoped equivalents Kerberos KDC records: _kerberos._tcp.<domain> and _kerberos-master._tcp/udp.<domain> DC A records: Forward lookup for each DC hostname to its IP PTR (reverse) records: IP-to-hostname for each DC — required for dual-protocol volume creation, NFSv4.1 Kerberos, LDAP-over-TLS certificate validation, and NTFS ACL operations on SMB shares. Note: _kerberos-master._tcp and _kerberos-master._udp SRV records are not created automatically by Active Directory DNS. They must be added manually in the DNS zone. Their absence causes Kerberos failures that do not clearly identify DNS as the root cause. This requirement is not documented in any ANF article. ANF performs Secure Dynamic DNS (DDNS) using GSS-TSIG to register SMB and dual-protocol volume hostnames in AD DNS. This requires that the DNS IPs in the AD connection belong to Microsoft AD-integrated DNS servers. External private DNS forwarders (Infoblox, BIND, Unbound, and similar appliances) do not support GSS-TSIG and will silently discard DDNS updates — volume hostnames will not appear in DNS and SMB mounts will fail. No error is surfaced in the ANF portal or activity log when DDNS is silently dropped. Inbound resolution — clients resolving ANF hostnames SMB and dual-protocol volumes are accessed via a hostname of the form <smb-prefix>-XXXX.<ad-dns-domain>, where the four-character suffix is assigned by ANF and cannot be overridden. Clients must resolve this hostname to the volume IP via the VNET DNS server setting, which in enterprise environments points to the external private DNS forwarder. The forwarder must have a forward lookup ruleset for the AD domain pointing to the external DC IPs. NFSv3 mounts use the volume IP directly and do not require hostname resolution. Note: NFSv3 volume creation success does not indicate SMB readiness. NFSv3 mounts use the volume IP directly and require no AD join, Kerberos exchange, or reverse DNS. SMB and dual-protocol volumes require all three. Using NFSv3 as a connectivity proxy during SMB troubleshooting produces false confidence. This distinction is not documented in ANF troubleshooting guidance. Configuring the external private DNS forwarder The two DNS paths — client resolution vs ANF internal In environments using an external private DNS forwarder (Infoblox, BIND, Windows DNS VM, or similar appliance), two distinct DNS paths must be kept separate. The VNET DNS server setting governs client resolution of ANF SMB hostnames and should point to the external forwarder. The ANF AD connection DNS fields govern ANF's own resolution of DCs and DDNS registration and must point directly to writable Microsoft AD-integrated DC IPs. DNS Path Used By Correct Target Client resolution (VNET DNS setting) VMs, Citrix, application servers resolving ANF SMB hostnames. External private DNS forwarder, which forwards AD zone queries to external DC IPs ANF internal resolution (AD connection DNS fields) ANF service — DDNS, Kerberos, LDAP, SRV lookup Writable AD-integrated external DC IPs directly — not the forwarder Required rulesets on the external private DNS forwarder The external private DNS forwarder must have both of the following rulesets configured. Missing either one produces failures that are difficult to diagnose because forward DNS tests pass while the actual failure occurs in a different path. References: Understanding Private DNS resolver endpoints & rulesets How to create Private Reverse DNS records Forward lookup ruleset Forward all queries for the AD domain to the external DC IPs: Zone: ad.contoso.com Targets: <DC-IP-1>:53, <DC-IP-2>:53 (writable external DC IPs) Reverse lookup ruleset (most commonly missing) Forward reverse lookup queries for the DC IP range to the external DC IPs: Zone: <reverse-octets>.in-addr.arpa. Targets: <DC-IP-1>:53, <DC-IP-2>:53 (same external DC IPs) Critical: The reverse lookup ruleset is the most commonly missing configuration item and causes a failure that forward DNS tests do not detect. Without it, Windows clients cannot resolve DC IPs to hostnames. This produces the following error when provisioning NTFS permissions on an ANF SMB share: 'The program cannot open the required dialog box because it cannot determine whether the computer named is joined to a domain.' All connectivity tests pass. Forward DNS passes. The volume was created successfully. Only the reverse lookup fails — and only when NTFS ACL operations are attempted. This failure mode and its root cause are not documented in any ANF article. GSS-TSIG constraint — why the forwarder cannot be in the ANF AD connection External private DNS forwarders (including Infoblox, BIND, Unbound, and third-party appliances) do not support GSS-TSIG, the protocol ANF uses to securely register SMB volume hostnames into AD DNS. If a forwarder IP is placed in the ANF AD connection DNS fields, ANF sends DDNS update packets to the forwarder, which discards them silently. The volume hostname never appears in DNS. Clients cannot mount by name. No error is returned in the ANF portal. The correct design: external DC IPs in the ANF AD connection, external private DNS forwarder as the VNET DNS server for clients only. Role of 168.63.129.16 168.63.129.16 is the Azure-provided internal resolver. It should be configured as the upstream forwarder target on the external private DNS forwarder for all queries not covered by AD or other conditional forwarders. This allows Azure-hosted DNS zones (such as any privatelink.* zones linked to your VNET) to resolve correctly through the forwarder. IMPORTANT: 168.63.129.16 must never be placed in the ANF AD connection DNS fields. It is not AD-aware, cannot answer SRV queries for your domain, cannot accept DDNS updates, and is unreachable from on-premises over ExpressRoute or VPN. Its correct position is as an upstream target on the external private DNS forwarder — not in ANF's AD connection. This is not stated anywhere in the ANF documentation set. DNS forwarder pattern comparison Pattern DDNS Support Reverse DNS Ops overhead Best Fit AD DNS on DCs + upstream 168.63.129.16 Yes, Native Yes, if reverse zones on DC's Medium Default; simplest topology External private DNS forwarder (VMs only) + external DC IPs in ANF AD connection Yes (ANF bypasses forwarder) Yes, if reverse ruleset on forwarder. Medium Enterprise with existing DNS infrastructure External DNS forwarder in ANF AD connection (incorrect) No — DDNS silently dropped N/A — config is wrong High Not supported Azure DNS Private Resolver in ANF AD connection (incorrect) No — DDNS not accepted N/A — config is wrong High Not supported Azure Virtual WAN considerations When ANF is deployed in a spoke VNET connected to an Azure Virtual WAN hub, a routing requirement applies that directly causes Kerberos and LDAP failures — which appear to be DNS or AD failures — when not addressed. This is one of the most common misdiagnoses in ANF deployments using Virtual WAN with NVA inspection. ANF subnet prefix must be in Routing Intent additional prefixes Azure Virtual WAN with Routing Intent routes private traffic through an NVA or Azure Firewall in the hub. For return traffic from external AD domain controllers to reach the ANF data plane IP, the hub must have an explicit routing entry for the ANF delegated subnet prefix. If the ANF delegated subnet is a /26 inside a larger VNET (/21 or /16), the broader VNET prefix alone is not sufficient — the specific /26 must be added explicitly. Action Required: In Azure Virtual WAN: Hub -> Routing -> Routing Intent -> Private Traffic -> Additional Prefixes. Add the ANF delegated subnet prefix (for example, 10.x.x.0/26) explicitly. Without this, Kerberos and LDAP reply traffic from external domain controllers is dropped before reaching the ANF data plane. The symptom is TCP port 88 connects succeeding followed by KRB5_KDC_UNREACH — which looks like a Kerberos or DNS problem but is a routing problem. Use availability zone switching to surface detailed error messages When ANF volume creation fails with the generic 'context deadline exceeded' error from the XMLrequest_filer endpoint, the error does not identify root cause. Redeploying the volume to a different availability zone (AZ1 to AZ2, or AZ2 to AZ3) forces a different backend assignment and consistently produces a more descriptive error that distinguishes routing failures (KRB5_KDC_UNREACH) from Kerberos authentication failures, DNS lookup failures, and LDAP errors. TIP: If the detailed error shows 'Successfully connected to ip <DC-IP>, port 88 using TCP' followed by 'Cannot contact any KDC for requested realm', the outbound path works but reply packets are dropped — this is a routing problem, not a DNS or Kerberos problem. Check vWAN Routing Intent, NVA firewall rules, and UDRs for the ANF subnet prefix. This diagnostic technique is not documented in ANF troubleshooting guidance. Required DNS records The following records must exist in the AD DNS zone served by the external DC DNS servers and must be resolvable from the ANF delegated subnet. Records marked * are not created automatically by AD DNS and must be added manually. Forward lookup zone Record Type Notes _ldap._tcp.dc._msdcs.<domain> SRV Domain-wide DC discovery _kerberos._tcp.dc._msdcs.<domain> SRV Domain-wide KDC discovery _ldap._tcp.<site>._sites.dc._msdcs.<domain> SRV Site-scoped — preferred when AD site is specified in ANF _kerberos._tcp.<site>._sites.dc._msdcs.<domain> SRV Site-scoped Kerberos _kerberos-master._tcp.<domain> * SRV NOT auto-created by AD DNS — must be added manually _kerberos-master._udp.<domain> * SRV NOT auto-created by AD DNS — must be added manually <dc-hostname> A Forward A record for each external DC in the AD site <anf-smb-hostname> A Registered by ANF via DDNS — must not be scavenged or blocked Reverse lookup zone (<reverse-octets>.in-addr.arpa) Record Type Notes PTR for each external DC IP PTR Required for dual-protocol, NFSv4.1 Kerberos, LDAP-over-TLS, and NTFS ACL operations PTR for each ANF volume IP * PTR Required for NFSv4.1 Kerberos reverse-lookup clients — create manually or via DDNS if supported How ANF internally fails when reverse DNS is missing When the reverse DNS ruleset is absent from the external private DNS forwarder, the failure does not surface as a DNS error in the ANF portal. Instead, it propagates through ANF's internal security daemon (secd) and presents as a generic InternalServerError or a Kerberos authentication failure. Understanding the internal failure chain explains why reverse DNS is non-negotiable and why the symptom is so misleading. The secd service list mechanism ANF uses an internal process called secd (Security Daemon) to manage all Active Directory communication — Kerberos ticket exchange, LDAP binds, and DC discovery. secd maintains a service list of discovered DCs. When a DC communication attempt fails for any reason, secd marks that DC as UNUSABLE and records a forgive time after which it will retry. If all DCs in the service list are simultaneously marked UNUSABLE, secd returns RESULT_ERROR_SECD_NO_SERVER_AVAILABLE, which propagates to the portal as InternalServerError. The reverse PTR lookup inside secd A critical and undocumented behavior: before secd completes a SASL/GSSAPI bind to an LDAP server, it performs a reverse PTR lookup of the DC's IP address. This lookup is used to validate the DC identity as part of Kerberos mutual authentication. If the PTR lookup fails — because the external private DNS forwarder has no reverse ruleset for the DC IP range — secd logs the failure and marks that DC UNUSABLE immediately, even though TCP connectivity on ports 88 and 389 succeeded. The following is the exact failure sequence from ANF backend logs when reverse DNS is absent: Stage 1 — TCP connects succeed, PTR lookup fails Successfully connected to ip 10.x.x.60, port 389 using TCP Entry for host-address: 10.x.x.60 not found in the current source: FILES Source: DNS unavailable. Entry for host-address: 10.x.x.60 not found in any of the available sources secd successfully opens the TCP connection to the DC on port 389 (LDAP), then immediately attempts a reverse lookup of that IP. The forwarder has no reverse ruleset, so DNS returns NXDOMAIN. secd logs 'DNS unavailable' and proceeds to mark the DC UNUSABLE. Stage 2 — GSSAPI bind fails as a consequence Unable to SASL bind to LDAP server using GSSAPI: Local error Unable to connect to LDAP (Active Directory) service on dc01.ad.contoso.com (Error: Local error) Because the PTR lookup failed, secd cannot complete the GSSAPI mutual authentication context. The 'Local error' is not a Kerberos configuration problem — it is the direct result of the identity validation step failing due to missing reverse DNS. Stage 3 — All DCs marked UNUSABLE 10.x.x.27 UNUSABLE Wed Apr 8 00:19:24 2026 10.x.x.28 UNUSABLE Wed Apr 8 00:19:24 2026 10.x.x.29 UNUSABLE Wed Apr 8 00:19:25 2026 10.x.x.30 UNUSABLE Wed Apr 8 00:19:25 2026 ... (all DCs in the service list) secd cycles through every DC in the discovered service list. Each DC fails the same PTR lookup. Each is marked UNUSABLE. Once the list is exhausted: Stage 4 — Service list exhausted, error propagates No servers in the service list which aren't marked bad Unable to select any server in the current serviceList RESULT_ERROR_SECD_NO_SERVER_AVAILABLE:6940 No servers available for MS_LDAP_AD, domain: ad.contoso.com This internal error code propagates up through the ANF volume creation stack and is presented to the operator as the generic 'context deadline exceeded (Client.Timeout exceeded while awaiting headers)' error in the portal. The actual cause — missing PTR records — is completely obscured. Stage 5 — Kerberos pre-auth error (secondary, misleading) Received error from KDC: -1765328359 / Additional pre-authentication required This Kerberos error code (KRB5KDC_ERR_PREAUTH_REQUIRED) appears in logs and can mislead investigation toward Kerberos configuration, encryption type mismatches, or clock skew. It is a downstream consequence of the failed PTR-based GSSAPI context — not a root cause. Chasing this error without first verifying reverse DNS is a common and time-consuming dead end. KEY INSIGHT: The complete failure chain is: missing reverse PTR ruleset on DNS forwarder → secd PTR lookup returns DNS unavailable → GSSAPI mutual auth cannot complete → DC marked UNUSABLE → all DCs exhausted → InternalServerError at portal. TCP connectivity on ports 88 and 389 succeeds at every stage. Only the PTR lookup fails. This is why all standard connectivity tests pass and the issue remains invisible until reverse DNS is specifically tested. Why this failure is invisible to standard troubleshooting ? Standard ANF DNS troubleshooting checks forward SRV records, forward A record resolution, and TCP port connectivity to DCs. All of these pass when only the reverse ruleset is missing. The secd PTR lookup is an internal step that occurs after TCP connectivity is confirmed and is not tested by any of the standard nslookup or Test-NetConnection commands used during initial validation. The only reliable way to surface this failure without access to backend logs is to explicitly test reverse PTR resolution from the ANF VNET — as documented in the verification section below. Verify DNS configuration Run the following commands from a test VM in the same VNET as the ANF delegated subnet. Use the external private DNS forwarder IP for client-side tests and an external DC IP for ANF-side tests. Forward SRV lookup — site-scoped nslookup -type=SRV _ldap._tcp.<SITE>._sites.dc._msdcs.<domain> <forwarder-IP> nslookup -type=SRV _kerberos._tcp.<SITE>._sites.dc._msdcs.<domain> <forwarder-IP> Forward SRV lookup — domain-wide nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain> <forwarder-IP> nslookup -type=SRV _kerberos._tcp.dc._msdcs.<domain> <forwarder-IP> Reverse PTR lookup — use the external forwarder IP nslookup <external-DC-IP> <forwarder-IP> Expected output: Server: <forwarder-IP> <reverse-arpa> name = dc01.ad.contoso.com. If reverse lookup returns NXDOMAIN or times out while forward lookup succeeds, add the reverse DNS ruleset to the external private DNS forwarder. This is the most common cause of NTFS permission failures after a volume is successfully created. Port connectivity from ANF VNET Test-NetConnection -ComputerName <external-DC-IP> -Port 88 # Kerberos Test-NetConnection -ComputerName <external-DC-IP> -Port 389 # LDAP Test-NetConnection -ComputerName <forwarder-IP> -Port 53 # DNS Common issues and resolutions Symptom Likely cause Resolution InternalServerError: context deadline exceeded (XMLrequest_filer) Generic ANF backend timeout — routing or Kerberos root cause not visible at this level Switch deployment availability zone for a detailed error. Check vWAN Routing Intent for ANF /26 prefix. KRB5_KDC_UNREACH — TCP port 88 connects succeed but auth fails Return traffic from external DCs dropped before reaching ANF NIC — routing issue, not DNS Add ANF subnet /26 to vWAN Hub Routing Intent > Additional Prefixes > Private Traffic 'Cannot determine whether the computer is joined to a domain' — NTFS permissions Reverse DNS (PTR) lookup failing on external forwarder for DC IPs Add reverse lookup ruleset to external private DNS forwarder: <reverse-zone>.in-addr.arpa. > external DC IPs DDNS fails — SMB hostname not in DNS after volume creation ANF AD connection DNS IPs point to external forwarder — GSS-TSIG not supported by forwarder Set AD connection DNS IPs to writable Microsoft AD-integrated external DC IPs directly 'Failed to validate LDAP configuration' during dual-protocol creation Missing PTR records for external DCs, or reverse zone unreachable Add PTR records for all external DCs. Verify reverse ruleset is present on the forwarder. NFSv4.1 Kerberos: 'Cannot determine realm for numeric host address' Missing PTR for ANF volume IP or external DC IPs Add PTR records for ANF volume IPs and all external DC IPs in the reverse zone. SMB hostname resolves on-premises but not from Azure VMs External private DNS forwarder missing forward ruleset for AD zone, or targeting wrong DC IPs Verify forward ruleset is present and targeting reachable writable external DC IPs. Volume creation fails after external DC IP change External DNS forwarder (especially BIND) caching stale DC IPs — default TTL up to 7 days Flush forwarder cache. Set short TTLs on DC A records. Consider Microsoft AD-integrated DNS for AD zones. Summary of key requirements: ANF AD connection DNS IPs must point to writable Microsoft AD-integrated DNS servers (external DC IPs) — not the external private DNS forwarder, not Azure DNS Private Resolver, not 168.63.129.16. The external private DNS forwarder must have both a forward ruleset (AD domain > external DC IPs) and a reverse ruleset (in-addr.arpa. zone for DC IP ranges > external DC IPs). The reverse ruleset is required for NTFS ACL operations on SMB shares and is not mentioned in ANF documentation. 168.63.129.16 is the upstream forwarder target on the external DNS forwarder — not a target in the ANF AD connection. It is unreachable from on-premises and is not AD-aware. External private DNS forwarders (Infoblox, BIND, Unbound) do not support GSS-TSIG. Placing a forwarder IP in the ANF AD connection causes silent DDNS failure with no portal error. In Virtual WAN deployments, add the ANF delegated subnet /26 to the hub Routing Intent under Additional Prefixes for Private Traffic. The broader VNET prefix alone is not sufficient. NFSv3 volume creation success does not indicate SMB readiness — NFSv3 uses the IP directly and bypasses AD, Kerberos, and reverse DNS. _kerberos-master SRV records are not created automatically by AD DNS and must be added manually. DNS scavenging should be disabled on zones containing ANF records, or records pre-created as static entries, as ANF does not aggressively refresh DDNS registrations. When volume creation fails with a generic 'context deadline exceeded' error, switch the deployment availability zone before deep troubleshooting to surface a more descriptive error. Related documentation: Understand Domain Name Systems in Azure NetApp Files Guidelines for Azure NetApp Files network planning Configure Virtual WAN for Azure NetApp Files Create and manage Active Directory connections for Azure NetApp Files Create and manage reverse DNS zones in Azure Private DNS Understand guidelines for Active Directory Domain Services site design and planning How to configure Virtual WAN Hub routing policies What is IP address 168.63.129.16?
Centralizing Enterprise API Access for Agent-Based Architectures
Problem Statement When building AI agents or automation solutions, calling enterprise APIs directly often means configuring individual HTTP actions within each agent for every API. While this works for simple scenarios, it quickly becomes repetitive and difficult to manage as complexity grows. The challenge becomes more pronounced when a single business domain exposes multiple APIs, or when the same APIs are consumed by multiple agents. This leads to duplicated configurations, higher maintenance effort, inconsistent behavior, and increased governance and security risks. A more scalable approach is to centralize and reuse API access. By grouping APIs by business domain using an API management layer, shaping those APIs through a Model Context Protocol (MCP) server, and exposing the MCP server as a standardized tool or connector, agents can consume business capabilities in a consistent, reusable, and governable manner. This pattern not only reduces duplication and configuration overhead but also enables stronger versioning, security controls, observability, and domain‑driven ownership—making agent-based systems easier to scale and operate in enterprise environments. Designing Agent‑Ready APIs with Azure API Management, an MCP Server, and Copilot Studio As enterprises increasingly adopt AI‑powered assistants and Copilots, API design must evolve to meet the needs of intelligent agents. Traditional APIs—often designed for user interfaces or backend integrations—can expose excessive data, lack intent-level abstraction, and increase security risk when consumed directly by AI systems. This document outlines a practical, enterprise-‑ready approach to organize APIs in Azure API Management (APIM), introduce a Model Context Protocol (MCP) server to shape and control context, and integrate the solution with Microsoft Copilot Studio. The goal is to make APIs truly agent-‑ready: secure, scalable, reusable, and easy to govern. Architecture at a glance Back-end services expose domain APIs. Azure API Management (APIM) groups and governs those APIs (products, policies, authentication, throttling, versions). An MCP server calls APIM, orchestrates/filters responses, and returns concise, model-friendly outputs. Copilot Studio connects to the MCP server and invokes a small set of predictable operations to satisfy user intents. Why Traditional API Designs Fall Short for AI Agents Enterprise APIs have historically been built around CRUD operations and service-‑to-‑service integration patterns. While this works well for deterministic applications, AI agents work best with intent-driven operations and context-aware responses. When agents consume traditional APIs directly, common issues include: overly verbose payloads, multiple calls to satisfy a single user intent, and insufficient guardrails for read vs. write operations. The result can be unpredictable agent behavior that is difficult to test, validate, and govern. Structuring APIs Effectively in Azure API Management Azure API Management (APIM) is the control plane between enterprise systems and AI agents. A well-‑structured APIM instance improves security, discoverability, and governance through products, policies, subscriptions, and analytics. Key design principles for agent consumption Organize APIs by business capability (for example, Customer, Orders, Billing) rather than technical layers. Expose agent-facing APIs via dedicated APIM products to enable controlled access, throttling, versioning, and independent lifecycle management. Prefer read-only operations where possible; scope write operations narrowly and protect them with explicit checks, approvals, and least-privilege identities. Read‑only APIs should be prioritized, while action‑oriented APIs must be carefully scoped and gated. The Role of the MCP Server in Agent‑Based Architectures APIM provides governance and security, but agents also need an intent-level interface and model-friendly responses. A Model Context Protocol (MCP) server fills this gap by acting as a mediator between Copilot Studio and APIM-exposed APIs. Instead of exposing many back-end endpoints directly to the agent, the MCP server can: orchestrate multiple API calls, filter irrelevant fields, enforce business rules, enrich results with additional context, and emit concise, predictable JSON outputs. This makes agent behavior more reliable and easier to validate. Instead of exposing multiple backend APIs directly to the agent, the MCP server aggregates responses, filters irrelevant data, enriches results with business context, and formats responses into LLM‑friendly schemas. By introducing this abstraction layer, Copilot interactions become simpler, safer, and more deterministic. The agent interacts with a small number of well‑defined MCP operations that encapsulate enterprise logic without exposing internal complexity. Designing an Effective MCP Server An MCP server should have a focused responsibility: shaping context for AI models. It should not replace core back-end services; it should adapt enterprise capabilities for agent consumption. What MCP should do An MCP server should be designed with a clear and focused responsibility: shaping context for AI models. Its primary role is not to replace backend services, but to adapt enterprise data for intelligent consumption. MCP does not orchestrate enterprise workflows or apply business logic. It standardizes how agents discover and invoke external tools and APIs by exposing them through a structured protocol interface. Orchestration, intent resolution, and policy-driven execution are handled by the agent runtime or host framework. It is equally important to understand what does not belong in MCP. Complex transactional workflows, long‑running processes, and UI‑specific formatting should remain in backend systems. Keeping MCP lightweight ensures scalability and easier maintenance. Call APIM-managed APIs and orchestrate multi-step retrieval when needed. Apply security checks and business rules consistently. Filter and minimize payloads (return only fields needed for the intent). Normalize and reshape responses into stable, predictable JSON schemas. Handle errors and edge cases with safe, descriptive messages. What MCP should not do Avoid implementing complex transactional workflows, long-running processes, or UI-specific formatting in MCP. Keep it lightweight so it remains scalable, testable, and easy to maintain. Step by step guide 1) Create an MCP server in Azure API Management (APIM) Open the Azure portal (portal.azure.com). Go to your API Management instance. In the left navigation, expand APIs. Create (or select) an API group for the business domain you want to expose (for example, Orders or Customers). Add the relevant APIs/operations to that API group. Create or select an APIM product dedicated for agent usage, and ensure the product requires a subscription (subscription key). Create an MCP server in APIM and map it to the API (or API group) you want to expose as MCP operations. In the MCP server settings, ensure Subscription key required is enabled. From the product’s Subscriptions page, copy the subscription key you will use in Copilot Studio. Screenshot placeholders: APIM API group, product configuration, MCP server mapping, subscription settings, subscription key location. * Note: Using an API Management subscription key to access MCP operations is one supported way to authenticate and consume enterprise APIs. However, this approach is best suited for initial setups, demos, or scenarios where key-based access is explicitly required. For production‑grade enterprise solutions, Microsoft recommends using managed identity–based access control. Managed identities for Azure resources eliminate the need to manage secrets such as subscription keys or client secrets, integrate natively with Microsoft Entra ID, and support fine‑grained role‑based access control (RBAC). This approach improves security posture while significantly reducing operational and governance overhead for agent and service‑to‑service integrations. Wherever possible, agents and MCP servers should authenticate using managed identities to ensure secure, scalable, and compliant access to enterprise APIs. 2) Create a Copilot Studio agent and connect to the APIM MCP server using a subscription key Copilot Studio natively supports Model Context Protocol (MCP) servers as tools. When an agent is connected to an MCP server, the tool metadata—including operation names, inputs, and outputs—is automatically discovered and kept in sync, reducing manual configuration and maintenance overhead. Sign in to Copilot Studio. Create a new agent and add clear instructions describing when to use the MCP tool and how to present results (for example, concise summaries plus key fields). Open Tools > Add tool > Model Context Protocol, then choose Create. Enter the MCP server details: Server endpoint URL: copy this from your MCP server in APIM. Authentication: select API Key. Header name: use the subscription key header required by your APIM configuration. Select Create new connection, paste the APIM subscription key, and save. Test the tool in the agent by prompting for a domain-specific task (for example, “Get order status for 12345”). Validate that responses are concise and that errors are handled safely. Screenshot placeholders: MCP tool creation screen, endpoint + auth configuration, connection creation, test prompt and response. Operational best practices and guardrails Least privilege by default: create separate APIM products and identities for agent scenarios; avoid broad access to internal APIs. Prefer intent-level operations: expose fewer, higher-level MCP operations instead of many low-level endpoints. Protect write operations: require explicit parameters, validation, and (when appropriate) approval flows; keep “read” and “write” tools separate. Stable schemas: return predictable JSON shapes and limit optional fields to reduce prompt brittleness. Observability: log MCP requests/responses (with sensitive fields redacted), monitor APIM analytics, and set alerts for failures and throttling. Versioning: version MCP operations and APIM APIs; deprecate safely. Security hygiene: treat subscription keys as secrets, rotate regularly, and avoid exposing them in prompts or logs. Summary As organizations scale agent‑based and Copilot‑driven solutions, directly exposing enterprise APIs to AI agents quickly becomes complex and risky. Centralizing API access through Azure API Management, shaping agent‑ready context via a Model Context Protocol (MCP) server, and consuming those capabilities through Copilot Studio establishes a clean and governable architecture. This pattern reduces duplication, enforces consistent security controls, and enables intent‑driven API consumption without exposing unnecessary backend complexity. By combining domain‑aligned API products, lightweight MCP operations, and least‑privilege identity‑based access, enterprises can confidently scale AI agents while maintaining strong governance, observability, and operational control. References Azure API Management (APIM) – Overview Azure API Management – Key Concepts Azure MCP Server Documentation (Model Context Protocol) Extend your agent with Model Context Protocol Managed identities for Azure resources – OverviewEnabling Agentic Data Governance with Hybrid Cloud Flexibility in Azure
The “Why” Do you manage data in a complex multi-cloud environment? Are you struggling with data silos, evolving regulations, and the pressure to maintain control and compliance across on-prem and multiple clouds? Do you ever wish an intelligent assistant could help shoulder the load of data governance? If so, I can relate. Let me tell you a story that might sound familiar. Meet Mark (pictured above). He is a data governance officer at Contoso (a fictional but very representative enterprise). Mark’s day job is ensuring data governance and compliance across his company’s vast hybrid cloud estate – think around ~2 million data assets sprawled across 12+ datacenters on-premises and in different public clouds. Regulatory requirements are constantly shifting. Customer data is increasingly sensitive. Each department and region has its own way of doing things. Mark is fighting an uphill battle with data silos and disconnected cloud operations. He bounces between a patchwork of tools – spreadsheets, cloud consoles, governance portals – trying to answer basic questions: Where is our data? Who’s using it? Are we in compliance? Armed with an old desk calculator and a pile of paper-based reports (a perfect 1990s backdrop), he is dealing with the data around him that has exploded in volume and complexity. What if Mark had a single pane of glass. The glass that reflects and acts. It reflects your governance state and enforces compliance – a self-hydrating pane of glass accompanied by a conversational AI. And he’s not alone. We’re all living in a data overload era. Every day, organizations generate and ingest more information than ever before. Transistors and mainframes gave way to the internet boom of the ’90s, then an explosion of mobile devices in the 2000s, social media in the 2010s, and now widespread cloud computing – all funneling data into our systems at an exponential rate. On top of that, a new wave of AI and conversational interfaces has arrived here in the mid-2020s, making data more accessible but also increasing expectations for real-time insight. It’s no wonder modern IT leaders feel overwhelmed. But these challenges are also opportunities. The way I see it, the incredible growth of data and cloud capabilities means we have a chance to reimagine data governance. The fact that I’m writing about this right now is no coincidence. My customers are looking to resolve problems in this space. In my conversations with them, I hear the same needs: We want better governance, more visibility, streamlined oversight… and cherry on top, we want it in an “agentic” fashion. In other words, they want to delegate the grunt work to the platform toolset augmented by AI, so they can focus on higher-value tasks. The “What” That vision – agentic data governance with hybrid cloud flexibility – became the driver for this work. This is a modular solution, and you have these building block style components (cloud services, governance tools, AI agents), which you can snap them together into an intended solution. Think of it as a jumpstart kit for continuous data governance across multiple clouds, with autonomous (“agentic”) assistance baked in that you can leverage and build upon. It’s not the final, productized solution – more a vision of what’s possible. Contoso’s Requirements These are the high-level requirements from Contoso: Data governance across clouds under one roof A single pane of glass dashboard consolidating reporting on the 5 governance domains: o Visibility on data residency and lineage o PII (Personally Identifiable Information) must run on a CC (Confidential Compute) o Security software (Defender) compliance o Resource tagging compliance (foundational for a good governance posture) o OS updates compliance Ability to enforce compliance in an agentic manner with a human in the loop Agentic enforcement of compliance pertaining to residency and confidential compute Solution – The breakdown The solution is comprised of 8 modules addressing these requirements. These solution modules are: Foundational (Landing zones, Data Sources, Operational setup, Policies, etc.) Dashboard Hydration + Agentic Reporting – Residency Compliance Dashboard Hydration + Agentic Reporting – Confidential Compute for PII Compliance Dashboard Hydration + Agentic Reporting – MS Defender Compliance Dashboard Hydration + Agentic Reporting – Resource Tag Compliance Dashboard Hydration + Agentic Reporting – OS Updates/Patch Compliance Enforce Compliance via Copilot Agent - Residency Compliance Enforce Compliance via Copilot Agent – CC PII Compliance Solution – The architecture view These are the main technical components that make up the solution architecture: Data sources of all shapes and sizes on the left, governed by the native Azure or the Arc plane. Additional Azure services across the bottom layer for the foundational governance posture Microsoft Purview, in the top middle, as the unified data governance platform Microsoft Fabric, in the bottom middle, as the end-to-end ingestion and analytics platform Microsoft Power Platform, on the right, as the low code/no code business flow and the copilot agent experience Solution – The end user view So how does Mark see this solution as a data governance officer? He doesn’t see all the intricacies of the solution integration and the logic execution. He sees two things: A Power BI dashboard running on Microsoft Fabric with A compliance dashboard with an overall score in each of the five compliance domains alongside scores for each of the data products across these domains Additional reporting views for more granular reporting Fabric-based pipeline that hydrates the underlying semantic models from various sources to keep the reports fresh and current A Copilot agent (in Teams) for both: Reporting on all compliance domains Enforcing in-scope compliance across selected domains The agent takes care of it - queries Fabric’s semantic model, calls Azure Function endpoints, updates Purview glossary terms, applies Azure tags, and sends Teams notifications. The “How” – Residency Compliance Let’s pick a few modules to walk through how these solution modules work together to give a cohesive agentic governance experience to Mark. It’s Monday morning, and Mark logs into the Contoso governance portal with a cup of coffee in hand. Instead of a dozen browser tabs, he has two main tools opened: the Data Governance Dashboard and the Contoso Governance Copilot agent. To address some inquiries that came as an assigned action to him, he interacted with the agent. During this interaction, not only did he validate if there were any residency missing in the unified data governance platform (Purview), but he was also able to address a mismatch between Purview and Azure resource, based on the designed principles. Here is the snippet of the chat: Now, under the hood, several components have worked on behalf of the agent in performing this governance checking and applying the necessary course of action: Even before Mark's conversation with the agent, an ongoing hydration process keeps the Fabric Power BI dashboard up to date. Dashboard Hydration + Agentic Reporting – Residency Compliance A Fabric notebook runs the residency scorecard code block through a pipeline. It reads two Lakehouse tables containing latest residency information from Purview and the approved region list Then, the notebook gets a Microsoft Entra bearer token Once acquired, the notebook then calls an Azure Function endpoint This endpoint, then searches for the Azure resources associated with the data products in Purview using an Azure resource tag. The notebook then compares the declared Purview residency with the approved region list and the associated resource’s region The notebook then calculates the final 0 / 25 / 50 / 75 / 100 residency compliance score and a reason. For example: A data product without an associated Azure resource gets a 0, while a data product whose residency in Purview is an approved region by Contoso, and also matches with the associated Azure resource, gets a 100. It then writes the results to the relevant residency compliance Lakehouse tables The dedicated compliance table then feeds to the semantic model for reporting The compliance Power BI dashboard is hydrated Enforce Compliance via Copilot Agent - Residency Compliance With the dashboard data regularly updated, the agent follows this logic, the updated reporting data, and the actions at its disposal, during the earlier conversation with Mark : Mark initiates the conversation with the agent The agent calls a Power Automate flow This flow retrieves Purview’s residency information stored in the Fabric semantic model 5, 6, 7 and 8. When Mark asks to investigate further on a data product, the agent carries the conversation using a topic, which then leverages a flow, which uses a Power Automate custom connector to access an Azure Function endpoint. This endpoint then retrieves latest glossary (residency) information about the data product in question, from Purview, and provides a preview back to the user 10, 11, 12, and 13. If the update criteria are met, and if there is no conflict, and with Mark’s blessings, the topic then calls another flow to access the Functions Purview Update endpoint, and make the glossary (residency) update in Purview for that data product The “How” – Confidential Compute for PII Compliance Dashboard Hydration + Agentic Reporting – Confidential Compute for PII Compliance The following snippet shows how Mark addresses the compliance risk with a critical data product (application), S/4 HANA, and performed the necessary compliance actions, such as tagging the associated resources and notifying the data product owners via Teams channel. The following diagram shows the under-the-hood hydration flow for confidential compute compliance: Enforce Compliance via Copilot Agent – CC PII Compliance Finally, the diagram below shows how Mark’s conversation flows through the main solution components: Outcome Stepping back, what did we accomplish for Mark and Contoso? We turned an onslaught of governance challenges into an opportunity to modernize how data is managed. This gave Mark: Centralized Visibility into data assets across the landscape through Purview and a unified dashboard Proactive compliance enabled with automated checks - controlled with Purview exports and Fabric pipeline schedules And compliance enforcement using an agent Hybrid Cloud Consistency. By using Azure Arc and a foundational data plane management setup Reduced Operational overhead with agentic reporting and compliance Though the solution is comprised of wide variety of components/services, it is built from standard building blocks and is relatively simple to implement. In total, the solution combined around a dozen Azure services and over 40 distinct components (from Purview catalogs to data pipelines, to custom functions and flows). You can choose to implement some or all the compliance domains. Or, better yet, build upon and create new domains and pave new paths. Wrap-up I believe many enterprises could take a similar journey. If you’re facing these issues, consider this an invitation to think differently about data governance. Start with the pieces you already have – your own building blocks of cloud services and data – and imagine what you could build. Chances are that a lot of the heavy lifting can be orchestrated with today’s technology. And with the rise of AI copilots, the dream of agentic data governance – where your policies are continuously enforced by smart agents – is no longer science fiction. It’s here, right now, waiting for you to take it for a spin. Next steps Watch the video narrative on SAP on Azure YouTube channel: Build it with the GitHub Repository: https://github.com/moazmirza/data-sov-and-hyb-cloud Comments/questions: Here, or @ LinkedIn /moazmirza Solution Selfies Azure Policy Compliance - Foundational Governance Posture Purview Data Product Catalog and Data Lineage Purview Governance Metadata à Fabric Lakehouse Fabric Semantic Model Additional Fabric Power BI Dashboard Copilot Studio Topic Flow Azure Function EndpointsAdvancing to Agentic AI with Azure NetApp Files VS Code Extension v1.2.0
The Azure NetApp Files VS Code Extension v1.2.0 introduces a major leap toward agentic, AI‑informed cloud operations with the debut of the autonomous Volume Scanner. Moving beyond traditional assistive AI, this release enables intelligent infrastructure analysis that can detect configuration risks, recommend remediations, and execute approved changes under user governance. Complemented by an expanded natural language interface, developers can now manage, optimize, and troubleshoot Azure NetApp Files resources through conversational commands - from performance monitoring to cross‑region replication, backup orchestration, and ARM template generation. Version 1.2.0 establishes the foundation for a multi‑agent system built to reduce operational toil and accelerate a shift toward self-managing enterprise storage in the cloud.Granting Azure Resources Access to SharePoint Online Sites Using Managed Identity
When integrating Azure resources like Logic Apps, Function Apps, or Azure VMs with SharePoint Online, you often need secure and granular access control. Rather than handling credentials manually, Managed Identity is the recommended approach to securely authenticate to Microsoft Graph and access SharePoint resources. High-level steps: Step 1: Enable Managed Identity (or App Registration) Step 2: Grant Sites.Selected Permission in Microsoft Entra ID Step 3: Assign SharePoint Site-Level Permission Step 1: Enable Managed Identity (or App Registration) For your Azure resource (e.g., Logic App): Navigate to the Azure portal. Go to the resource (e.g., Logic App). Under Identity, enable System-assigned Managed Identity. Note the Object ID and Client ID (you’ll need the Client ID later). Alternatively, use an App Registration if you prefer a multi-tenant or reusable identity. How to register an app in Microsoft Entra ID - Microsoft identity platform | Microsoft Learn Step 2: Grant Sites.Selected Permission in Microsoft Entra Open Microsoft Entra ID > App registrations. Select your Logic App’s managed identity or app registration. Under API permissions, click Add a permission > Microsoft Graph. Select Application permissions and add: Sites.Selected Click Grant admin consent. Note: Sites.Selected ensures least-privilege access — you must explicitly allow site-level access later. Step 3: Assign SharePoint Site-Level Permission SharePoint Online requires site-level consent for apps with Sites.Selected. Use the script below to assign access. Note: You must be a SharePoint Administrator and have the Sites.FullControl.All permission when running this. PowerShell Script: # Replace with your values $application = @{ id = "{ApplicationID}" # Client ID of the Managed Identity displayName = "{DisplayName}" # Display name (optional but recommended) } $appRole = "write" # Can be "read" or "write" $spoTenant = "contoso.sharepoint.com" # Sharepoint site host $spoSite = "{Sitename}" # Sharepoint site name # Site ID format for Graph API $spoSiteId = $spoTenant + ":/sites/" + $spoSite + ":" # Load Microsoft Graph module Import-Module Microsoft.Graph.Sites # Connect with appropriate permissions Connect-MgGraph -Scope Sites.FullControl.All # Grant site-level permission New-MgSitePermission -SiteId $spoSiteId -Roles $appRole -GrantedToIdentities @{ Application = $application } That's it, Your Logic App or Azure resource can now call Microsoft Graph APIs to interact with that specific SharePoint site (e.g., list files, upload documents). You maintain centralized control and least-privilege access, complying with enterprise security standards. By following this approach, you ensure secure, auditable, and scalable access from Azure services to SharePoint Online — no secrets, no user credentials, just managed identity done right.How Azure NetApp Files Object REST API powers Azure and ISV Data and AI services – on YOUR data
This article introduces the Azure NetApp Files Object REST API, a transformative solution for enterprises seeking seamless, real-time integration between their data and Azure's advanced analytics and AI services. By enabling direct, secure access to enterprise data—without costly transfers or duplication—the Object REST API accelerates innovation, streamlines workflows, and enhances operational efficiency. With S3-compatible object storage support, it empowers organizations to make faster, data-driven decisions while maintaining compliance and data security. Discover how this new capability unlocks business potential and drives a new era of productivity in the cloud.Unlocking Advanced Data Analytics & AI with Azure NetApp Files object REST API
Azure NetApp Files object REST API enables object access to enterprise file data stored on Azure NetApp Files, without copying, moving, or restructuring that data. This capability allows analytics and AI platforms that expect object storage to work directly against existing NFS based datasets, while preserving Azure NetApp Files’ performance, security, and governance characteristics.Cross-Region Zero Trust: Connecting Power Platform to Azure PaaS across different regions
In the modern enterprise cloud landscape, data rarely sits in one place. You might face a scenario where your Power Platform environment (Dynamics 365, Power Apps, or Power Automate) is hosted in Region A for centralized management, while your sensitive SQL Databases or Storage Accounts must reside in Region B due to data sovereignty, latency requirements, or legacy infrastructure. Connecting these two worlds usually involves traversing the public internet - a major "red flag" for security teams. The Missing Link in Cloud Security When we talk about enterprise security, "Public Access: Disabled" is the holy grail. But for Power Platform architects, this setting is often followed by a headache. The challenge is simple but daunting: How can a Power Platform Environment (e.g., in Region A) communicate with an Azure PaaS service (e.g., Storage or SQL in Region B) when that resource is completely locked down behind a Private Endpoint? Existing documentation usually covers single-region setups with no firewalls. This post details a "Zero Trust" architecture that bridges this gap. This is a walk through for setting up a Cross-Region Private Link that routes traffic from the Power Platform in Region A, through a secure Azure Hub, and down the Azure Global Backbone to a Private Endpoint in Region B, without a single packet ever touching the public internet. 1. Understanding the Foundation: VNet Support Before we build, we must understand what moves: Power Platform VNet integration is an "Outbound" technology. It allows the platform to connect to data sources secured within an Azure Virtual Network and "inject" its traffic into your Virtual Network, without needing to install or manage an on-premises data gateway. According to Microsoft's official documentation, this integration supports a wide range of services: Dataverse: Plugins and Virtual Tables. Power Automate: Cloud Flows using standard connectors. Power Apps: Canvas Apps calling private APIs. This means once the "tunnel" is built, your entire Power Platform ecosystem can reach your private Azure universe. Virtual Network support overview – Power Platform | Microsoft Learn 2. The Architecture: A Cross-Region Global Bridge Based on the Hub-and-Spoke topology, this architecture relies on four key components working in unison: Source (Region A): The Power Platform environment utilizes VNet Injection. This injects the platform's outbound traffic into a dedicated, delegated subnet within your Region A Spoke VNet. The Hub: A central VNet containing an Azure Firewall. This acts as the regional traffic cop and DNS Proxy, inspecting traffic and resolving private names before allowing packets to traverse the global backbone. The Bridge (Global Backbone): We utilize Global VNet Peering to connect Region A to the Region B Spoke. This keeps traffic on Microsoft's private fiber backbone. Destination (Region B): The Azure PaaS service (e.g. Storage Account) is locked down with Public Access Disabled. It is only accessible via a Private Endpoint. The Architecture: Visualizing the Flow As illustrated in the diagram below, this solution separates the responsibilities into two distinct layers: the Network Admin (Azure Infrastructure) and the Power Platform Admin (Enterprise Policy). 3. The High Availability Constraint: Regional Pairs A common pitfall of these deployments is configuring only a single region. Power Platform environments are inherently redundant. In a geography like Europe, your environment is actually hosted across a Regional Pair (e.g., West Europe and North Europe). Why? If one Azure region in the pair experiences an outage, your Power Platform environment will failover to the second region. If your VNet Policy isn't already there, your private connectivity will break. To maintain High Availability (HA) for your private tunnel, your Azure footprint must mirror this: Two VNets: You must create a Virtual Network in each region of the pair. Two Delegated Subnets: Each VNet requires a subnet delegated specifically to Microsoft.PowerPlatform/enterprisePolicies. Two Network Policies: You must create an Enterprise Policy in each region and link both to your environment to ensure traffic flows even during a regional failover. Ensure your Azure subscription is registered for the Microsoft.PowerPlatform resource provider by running the SetupSubscriptionForPowerPlatform.ps1 script. 4. Solving the DNS Riddle with Azure Firewall In a Hub-and-Spoke model, peering the VNets is only half the battle. If your Power Platform environment in Region A asks for mystorage.blob.core.windows.net, it will receive a public IP by default, and your connection will be blocked. To fix this, we utilize the Azure Firewall as a DNS Proxy: Link the Private DNS Zone: Ensure your Private DNS Zones (e.g., privatelink.blob.core.windows.net) are linked to the Hub VNet. Enable DNS Proxy: Turn on the DNS Proxy feature on your Azure Firewall. Configure Custom DNS: Set the DNS servers of your Spoke VNets (Region A) to the Firewall’s Internal IP. Now, the DNS query flows through the Firewall, which "sees" the Private DNS Zone and returns the Private IP to the Power Platform. 5. Secretless Security with User-Assigned Managed Identity Private networking secures the path, but identity secures the access. Instead of managing fragile Client Secrets, we use User-Assigned Managed Identity (UAMI). Phase A: The Azure Setup Create the Identity: Generate a User-Assigned Managed Identity in your Azure subscription. Assign RBAC Roles: Grant this identity specific permissions on your destination resource. For example, assign the Storage Blob Data Contributor role to allow the identity to manage files in your private storage account. Phase B: The Power Platform Integration To make the environment recognize this identity, you must register it as an Application User: Navigate to the Power Platform Admin Center. Go to Environments > [Your Environment] > Settings > Users + permissions > Application users. Add a new app and select the Managed Identity you created in Azure. 6. Creating Enterprise Policy using PowerShell Scripts One of the most important things to realize is that Enterprise Policies cannot be created manually in the Azure Portal UI. They must be deployed via PowerShell or CLI. While Microsoft provides a comprehensive official GitHub repository with all the necessary templates, it is designed to be highly modular and granular. This means that to achieve a High Availability (HA) setup, an admin usually needs to execute deployments for each region separately and then perform the linking step. To simplify this workflow, I have developed a Simplified Scripts Repository on my GitHub. These scripts use the official Microsoft templates as their foundation but add an orchestration layer specifically for the Regional Pair requirement: Regional Pair Automation: Instead of running separate deployments, my script handles the dual-VNet injection in a single flow. It automates the creation of policies in both regions and links them to your environment in one execution. Focused Scenarios: I’ve distilled the most essential scripts for Network Injection and Encryption (CMK), making it easier for admins to get up and running without navigating the entire modular library. The Goal: To provide a "Fast-Track" experience that follows Microsoft's best practices while reducing the manual steps required to achieve a resilient, multi-region architecture. Owning the Keys with Encryption Policies (CMK) While Microsoft encrypts Dataverse data by default, many enterprise compliance standards require Customer-Managed Keys (CMK). This ensures that you, not Microsoft, control the encryption keys for your environments. - Manage your customer-managed encryption key - Power Platform | Microsoft Learn Key Requirements: Key Vault Configuration: Your Key Vault must have Purge Protection and Soft Delete enabled to prevent accidental data loss. The Identity Bridge: The Encryption Policy uses the User-Assigned Managed Identity (created in Step 5) to authenticate against the Key Vault. Permissions: You must grant the Managed Identity the Key Vault Crypto Service Encryption User role so it can wrap and unwrap the encryption keys. 7. The Final Handshake: Linking Policies to Your Environment Creating the Enterprise Policy in Azure is only the first half of the process. You must now "inform" your Power Platform environment that it should use these policies for its outbound traffic and identity. Linking the Policies to Your Environment: For VNet Injection: In the Admin Center, go to Security > Data and privacy > Azure Virtual Network Policies. Select your environment and link it to the Network Injection policies you created. For Encryption (CMK): Go to Security > Data and privacy > Customer-managed encryption Key. Add the Select the Encryption Enterprise Policy -Edit Policy - Add Environment. Crucial Step: You must first grant the Power Platform service "Get", "List", "Wrap" and "Unwrap" permissions on your specific key within Azure Key Vault before the environment can successfully validate the policy. Verification: The "Smoking Gun" in Log Analytics After successfully reaching a Resource from one of the power platform services you can check if the connection was private. How do you prove its private? Use KQL in Azure Log Analytics to verify the Network Security Perimeter (NSP) ID. The Proof: When you see a GUID in the NetworkPerimeter field, it is cryptographic evidence that the resource accepted the request only because it arrived via your authorized private bridge. In Azure Portal - Navigate to your Resource for example KeyVault - Logs - Use the following KQL: AzureDiagnostics | where ResourceProvider == "MICROSOFT.KEYVAULT" | where OperationName == "KeyGet" or OperationName == "KeyUnwrap" | where ResultType == "Success" | project TimeGenerated, OperationName, VaultName = Resource, ResultType, CallerIP = CallerIPAddress, EnterprisePolicy = identity_claim_xms_mirid_s, NetworkPerimeter = identity_claim_xms_az_nwperimid_s | sort by TimeGenerated desc Result: By implementing the Network, and Encryption Enterprise policy you transition the Power Platform from a public SaaS tool into a fully governed, private extension of your Azure infrastructure. You no longer have to choose between the agility of low-code and the security of a private cloud. To summarize the transformation from public endpoints to a complete Zero Trust architecture across regions, here is the end-to-end workflow: PHASE 1: Azure Infrastructure Foundation Create Network Fabric (HA): Deploy VNets and Delegated Subnets in both regional pairs. Deploy the Hub: Set up the Central Hub VNet with Azure Firewall. Connect Globally: Establish Global VNet Peering between all Spokes and the Hub. Solve DNS: Enable DNS Proxy on the Firewall and link Private DNS Zones to the Hub VNet. ↓ PHASE 2: Identity & Security Prep Create Identity: Generate a User-Assigned Managed Identity (UAMI). Grant Access (RBAC): Give the UAMI permissions on the target PaaS resource (e.g., Storage Contributor). Prepare CMK: Configure Key Vault access policies for the UAMI (Wrap/Unwrap permissions). ↓ PHASE 3: Deploy Enterprise Policies (PowerShell/IaC) Deploy Network Policies: Create "Network Injection" policies in Azure for both regions. Deploy Encryption Policy: Create the "CMK" policy linking to your Key Vault and Identity. ↓ PHASE 4: Power Platform Final Link (Admin Center) Link Network: Associate the Environment with the two Network Policies. Link Encryption: Activate the Customer-Managed Key on the environment. Register User: Add the Managed Identity as an "Application User" in the environment. ↓ PHASE 5: Verification Run Workload: Trigger a Flow or Plugin. Audit Logs: Use KQL in Log Analytics to confirm the presence of the NetworkPerimeter ID.Boosting Hybrid Cloud Data Efficiency for EDA: The Power of Azure NetApp Files cache volumes
Electronic Design Automation (EDA) is the foundation of modern semiconductor innovation, enabling engineers to design, simulate, and validate increasingly sophisticated chip architectures. As designs push the boundaries of PPA (Power, Performance, and reduced Area) to meet escalating market demands, the volume of associated design data has surged exponentially with a single System-on-Chip (SoC) project generating multiple petabytes of data during its development lifecycle, making data mobility and accessibility critical bottlenecks. To overcome these challenges, Azure NetApp Files (ANF) cache volumes are purpose-built to optimize data movement and minimize latency, delivering high-speed access to massive design datasets across distributed environments. By mitigating data gravity, Azure NetApp Files cache volumes empower chip designers to leverage cloud-scale compute resources on demand and at scale, thus accelerating innovation without being constrained by physical infrastructure.
