Setting up Power Platform vNet Integration

Overview

Integrating Power Platform environments with Azure Virtual Networks can appear daunting. Few people are experts on both Azure and the Power Platform, and even if you are, some aspects of the process are probably new to you. This guide provides step-by-step instructions on setting up Power Platform vNet integration and timely warnings about potential pitfalls.

Power Platform Virtual Network Integration Explained

Power Platform Virtual Network integration provides a more secure way to let Power Platform resources—such as your canvas apps, model-driven apps, and cloud flows—communicate with Azure services like key vaults and SQL databases. It allows approved Power Platform environments to inject data into paired Azure networks through designated subnets. These subnets use service endpoints to communicate with Azure resources. As a result, your Power Platform resources cease contacting your Azure resources as an external service. Instead, they send communications from within your Azure virtual network, making verifying their authenticity easier and keeping bad actors from your data.

This integration may seem unnecessary at first glance. After all, when two Microsoft services, such as Azure and the Power Platform, communicate, the connection is already routed over the Microsoft backbone rather than the public internet. Why does this still matter? The full answer involves key security principles like defense in depth, minimizing attack surfaces, zero trust, and presuming breach. In practice, however, it comes down to three goals. You want:

1. All your Azure resources to be protected by firewalls
2. Your trusted resources to be able to get through those firewalls
3. Nothing else to get through.

Turning off your firewall to allow Power Platform resources through would create a massive attack surface, exposing your Azure resources to the public internet. Without vNet integration, letting your Power Platform resources clear the firewalls would require safelisting the IP addresses of the Power Platform region. Doing so would also allow bad actors inside or outside your organization to potentially reach your resources, as long as they’re using Power Platform in the same region. That’s better than having no firewall, but it’s still a risk.

With Power Platform Virtual Network integration, you can designate secure, managed environments within your tenant that can access specific Azure resources, giving you complete control over the connections. Your network stays safe. Nothing will get through except what you allow.

What does that mean in practice?

Once you integrate your environment into Azure, all supported connections will send all their communications through the designated subnets. Note that this is only supported connections: other Power Platform resources will behave normally. As of writing this, Microsoft supports the following connectors, most of which are specific to Azure:

Once your connectors begin communicating from a service point in an Azure subnet, they will be subject to the full range of network security regulations at work in that subnet/vNet. For example, if your Azure environment has a network security group restricting outbound internet traffic, those restrictions will apply to the supported Power Platform connections.

Prerequisites:

There are several things to verify before you begin. The Microsoft documentation lists several prerequisites for vNet integration, but some deserve further explanation.

Review your connections:

The first recommendation in the docs is that you review your connections. Specifically:

Review your apps, flows, and plug-in code to ensure they connect over your virtual network—they shouldn’t call endpoints over the public internet. If your components need to connect to public endpoints, ensure your firewall or network configuration allows such calls.

While important, this can be misleading for some use cases. For example, if you’re using high-code Dataverse plug-ins, you’ll have great flexibility when connecting to your Azure resources. You should deploy private endpoints and use them to connect to your resources whenever possible.

However, not all components are configurable this way. As it says, your components may need to connect to public endpoints. According to my testing and conversations with Microsoft support, there is no way to force some connections—such as a key vault action in Power Automate—to use the resource’s private endpoint (although I would love to be proven wrong on this). Even if your DNS resolves the private IP, your key vault connectors will still connect to the public endpoint, even with virtual network integration.

However, that’s okay. As I mentioned in the introduction, the communications between Azure and the Power Platform will still travel over Microsoft’s backbone network rather than the public internet. Further, having virtual network integration will let you restrict firewall exceptions to the resources you want to allow.

By all means, configure what you can, but don’t worry too much that you can’t configure some things. The unconfigurable components will still be secure. Just be prepared to allow the subnets’ service endpoint access through your firewalls as part of your configuration.

Prepare your Tenant

The second point, “Prepare your tenant,” may seem straightforward, but depending on your organization’s policies, it may be the most time-consuming. Microsoft’s recommendation to “Have an Azure subscription with permissions to create a virtual network, subnet, and the enterprise policy resources” may mean negotiating any number of Azure policies and initiatives. You should check your policies and initiatives before you begin. I’ll discuss some of these steps here, but there may be others, depending on your settings. In particular, the limited locations policy should be reviewed if you have one since the default settings will always conflict with the enterprise policy deployment.

Check your policies before starting!

In addition to creating those resources, you may need the rights to deploy others if policy requirements compel you to, for example, deploy network security groups or route tables along with your subnets, so ensure you have the necessary access. Also, ensure no policy blocks necessary resources by type or other factors. Often, if you have access, the fastest way to confirm this is to try deploying resources and see if they fail. If a policy blocks them, you should see an error message indicating which policy is responsible. You can also ask someone with knowledge of your organization’s policies, and they can usually confirm any conflicts.

However, one to check explicitly is your limited locations policy. Your subnets need to be in paired regions, and the enterprise policy will deploy at the Power Platform region (Azure geography) level, not an Azure region level. If your organization has policy restrictions on where to place resources, you must account for that.

Consult the official documentation for which Power Platform region (again, note that Power Platform regions are equivalent to Azure geographies) and Azure region pair to use. You must use the Power Platform region for your environment and enterprise policy corresponding to the paired Azure regions in the chart. There can be no mixing and matching.

The Sweden/Singapore Exception

Despite what the documentation claims, deploying to the Sweden and Singapore regions is impossible because Azure strictly requires that your subnets…

1. …cannot be in the same Azure region
2. …must be in the same Power Platform region
3. …must be in supported regions

Because there is only one “supported” (and I use the term loosely here) Azure region for Sweden (swedencentral) and Singapore (southeastasia), it is impossible to meet these requirements there. Your deployment will fail, and there is no workaround. Believe me, I’ve tried, and Microsoft support was kind enough to confirm that it’s futile (but not to fix the documentation).

Adjusting Your Locations Policy

If your organization has a limited locations policy, your Power Platform region/Azure geography (again, same thing) is likely not covered, blocking your enterprise policy deployment. Worse, your geography won’t be available as one of the policy parameters.

To resolve this, your Azure policy administrator must manually edit the definition to allow your geography. Follow the same structure that is probably already used for “Global” deployments in your policy. For example, the default structure of a location policy policyRule looks like this:

To enable deployment to “Europe,” for example, you would need to (at a minimum) change it to this:

For added security, your policy administrator may wish to restrict this change to microsoft.powerplatform/enterprisepolicies type resources. This would ensure that only Power Platform enterprise policies can use the new deployment location. Whether or not this is necessary depends on your organization’s security standards, but it rarely hurts.

Final Preparations

1. On the Power Platform side, ensure your environments are managed and located in the expected region.
2. Download the Powershell scripts.
3. Ensure you have Power Platform system administrator access to the managed environments.

You can find the GitHub repository for them here. Those less familiar with Git can download the files directly with this link. If using the latter, download the zip and unzip it to your preferred location on your machine. Also, ensure you have admin access on the device running the scripts. If your organization requires you to request those on a case-by-case basis, account for the time necessary to get those rights.

Setting up in Azure:

Once you’ve established your prerequisites, it’s time to start deploying Azure resources. At this stage, you must:

1. Create two virtual networks in paired regions.
2. Assign each virtual network a subnet exclusively dedicated to the Power Platform.
3. Deploy the Azure resource you’re connecting to (if you have not already).

If you use a private endpoint connection, see additional resources on setting up a private endpoint and virtual network peering. If you don’t know how to deploy a virtual network in Azure, you can find more information about it here.

This blog will focus on requirements specific to the Power Platform integration.

Virtual Networks and Subnets

Key Requirements:

1. Two virtual networks (vNets) – one in each paired region
2. Two subnets – one in each virtual network
3. A managed Power Platform Environment that matches the geography of the paired regions

Your primary subnet handles most of your traffic. The secondary acts as a failover, directing traffic when the first is unavailable.

For reduced latency, ensure proximity between Azure resources and primary subnets.

• If your resources (such as a key vault or database) are in a region that does not support Power Platform virtual network integration, choose the nearest. For example, if your resource is in Sweden, put your primary subnet in northeurope and secondary in westeurope and your Power Platform environment and enterprise policy in Europe. If the resource is in centralus, put the networks in eastus and westus and the environment/policy in United States.

• If you have an existing virtual network in one of the regions that already contains some of your Azure resources, you can add your primary subnet there instead of creating a new virtual network.

The subnets need to be dedicated to the Power Platform, but the rest of the virtual networks do not. As your architecture permits, feel free to add either subnet to an existing virtual net with space that meets the requirements.

Public and Private Endpoint Considerations

If using public endpoints only:

• The subnets only need to be in the same tenant as the connected Azure resource
• The person allowing them needs access to them.

If connecting to a private endpoint:

• The subnet must be in the same virtual network as the private endpoint or a peered network.
• Because the subnets must be in different regions, at least one must be peered.
• Network peering can occur across regions.

No configuration requires sharing a region or geography with the connected resources.

Subnet Sizing and Configuration

Each subnet needs a /24 CIDR block, granting 251 usable IP addresses.

Microsoft provides a chart for determining the correct size based on your number of environments and traffic, but the network size is always the same.

• Unfortunately, the details on what would require a larger size or at what rate to scale up are somewhat ambiguous. However, Microsoft recommends using a larger subnet if the /24 size is insufficient. A /23 will double the number of your IP addresses, a /22 will quadruple them, etc.
• Despite Microsoft listing a minimum number of environments, integrations with only one environment work fine.

Name your vNet and subnet appropriately. You can leave most other options at their default values. If your policy requires a route table and/or network security group deployment with your subnets, you should create the route table in advance. You can deploy the network security group during subnet deployment.

Resources and Connectivity

If you haven’t already, you must deploy the Azure resources you connect to and ensure the subnets can access them.

For Private Endpoints:

Add a private endpoint to the resource and ensure both subnets can access that endpoint, setting up network peering as necessary (for whichever subnet(s) aren’t in the same virtual network as the endpoint). This is too much to detail here, but the guides above should provide a helpful walkthrough.

For Public Endpoints:

If your Power Platform resources connect via public endpoints, add the subnets to the resource’s networking page, as shown below. The example uses a key vault for demonstration, but the interface is similar across most Azure resources.

Select Allow public access from specific virtual networks and IP addresses and click +Add a virtual network. In the dropdown menu, select Add existing virtual networks and then provide the details of your virtual networks and subnets in the blade that appears on the right.

Your Azure resources are now ready.

Run the Scripts

Here’s where the real magic happens! Luckily, this part is easy, as long as you know how to run a shell script (If not, click here for guidance).

Before Starting:

• Ensure Admin permissions on your local machine.
• Download and install the latest version of Powershell.
• Run Powershell as an administrator.
• Navigate to the folder where you unzipped the Powershell scripts during the earlier step.

I’ll walk through running these scripts step by step, but general instructions for running these scripts also appear on the GitHub repository page.

During this process, the system may prompt you to log in or confirm that you want to run the script. The latter may even appear multiple times for the same script because the scripts interrelate and trigger other scripts. This is expected behavior. Go ahead and give permission when prompted. When asked to log in, use the account with Azure permissions discussed in the prerequisites. The exception is the final script, for which you should use the account with Power Platform admin permissions.

Setup Scripts

If you haven’t, you should start by running the setup scripts.

First, run

.\InstallPowerAppsCmdlets.ps1

You’ll find it in the zip file’s root directory. It will install the basic cmdlets the other scripts use. These are the resources your Powershell environment needs to communicate with Azure and perform the essential functions related to the integration. If you’re unsure if you have installed these, run the script anyway. Repeated runs will not harm your system.

Next, run

.\SetupSubscriptionForPowerPlatform.ps1

This appears in the same directory. The script registers the Power Platform as a resource provider in your Azure subscription. It is unnecessary to rerun this for later integrations in the same subscription, but it won’t harm anything if you try anyway to be sure. You will be prompted to provide your subscription ID. You can find it on the overview page of your subscription in the Azure portal. Copy it (exactly as it appears) into your Powershell prompt when directed.

As always, affirm that you want to run the script if asked. That prompt may appear repeatedly. When asked to sign in, you must sign in with an account that can authorize adding the resource provider.

Create the Enterprise Policy

Next, you need to create the enterprise policy itself.

Run

.\CreateSubnetInjectionEnterprisePolicy.ps1

You can find it in the SubnetInjection subdirectory of your downloaded files. This step takes the most inputs and is where you’ll get stuck if you performed the earlier steps incorrectly. If your subnets are not in paired regions, a policy blocks your deployment, or you skipped earlier stages, this step will fail. If you encounter issues, adjust the relevant resources or repeat the missing steps and try again.

Again, you might start by confirming that you want to run scripts.

You’ll need to supply the following parameters:

• subscriptionID: Copy the subscription ID from the subscription’s overview stage, exactly as you did in the previous step.
• resourceGroup: Copy the resource group name from the Azure portal. Use whatever resource group you want to assign the policy to. I recommend using the same group as your virtual networks to keep your Power Platform virtual network integration resources neatly organized.
• enterprisePolicyName: This is the new name for your policy. Choose whatever name you want. Ideally, this should be descriptive and adhere to your organization’s naming conventions.
• enterprisePolicyLocation: Use the name of the Azure geography/Power Platform region that corresponds to the paired regions of your subnets and the Power Platform environment(s) you wish to integrate. The name should be in lowercase. Omit any spaces, i.e., “unitedstates” or “southafrica”
• primaryVnetId: This is the complete ARM resource ID for the primary virtual network, NOT the ID on the virtual network’s overview page. Use the format below, replacing <Subscription ID> and <Resource Group Name> with the virtual network’s subscription ID and resource group name as you entered previously. Replace <vnet name> with the name of your virtual network:

/subscriptions/<Subscription ID>/resourceGroups/<Resource Group Name>/providers/Microsoft.Network/virtualNetworks/<vnet name>

• primarySubnetName: Provide the name of the designated subnet you created in your first virtual network. Enter it exactly as it appears in the Azure portal (no fancy formats).
• secondaryVnetId: Follow the instructions above for the primary virtual network ID, but, instead, substitute the information from your second virtual network.
• secondarySubnetName: Provide the name of the designated subnet you created in your second virtual network. Enter it exactly as it appears in the Azure portal (no fancy formats).

Sign in with your Azure account when prompted.

The GitHub page offers the following sample inputs:

You’ll see a preview of the new policy definition when the script completes successfully.

Add Subnet Injection to Your Environment

And finally,

Run:

.\NewSubnetInjection.ps1

Find it in the SubnetInjection subdirectory. This script activates the subnet injection for your Power Platform environment. You must run this script once for each environment you wish to connect.

If asked for confirmation, affirm that you want to run the script. Do this as many times as it asks. It will request the following parameters:

• environmentId: The environment ID appears on the environment’s page in the Power Platform admin center.
• policyArmId: Your policy’s ARM ID should use the format below. Replace <Subscription ID> and <Resource Group Name> precisely as you did with the virtual network ARM ID. If the policy is not in the same resource group as your virtual networks, use its resource group name instead. In place of <Policy Name>, use the name you assigned to your enterprise policy when running the previous script.

/subscriptions/<Subscription ID>/resourceGroups/<Resource Group Name>/providers/Microsoft.PowerPlatform/enterprisePolicies/<Policy Name>

Log in when prompted. For this step, the account you use must also have admin permissions in the Power Platform environment.

The operation will typically take a few seconds to complete. However, you may be prompted on whether or not you wish to poll the operation. I’ve found the polling operation to be unreliable, so I personally prefer to choose no and use the steps below to verify that the process was successful.

The GitHub page provides the following sample inputs:

Your Power Platform environment should now be integrated with your Azure virtual networks.

Validation and Testing

The GitHub page provides instructions on using the other scripts to list and view your policy and injections. You can also view the policy via Powershell commands. You may find it beneficial to grant read access for enterprise policies to the Power Platform administrator role. Doing so is optional, but it will let your Power Platform administrators view the enterprise policies applied to their environments, including the one you just created.

Even without all that, you can confirm the process was successful by checking your environment’s history. In the Power Platform Admin Center, select “Environments” on the left blade:

Select the environment and scroll down to the bottom of the page. If your enterprise policy was the most recent action, you’ll see it in the Recent operations box like so:

If not, click Full history in the upper right of that box. This will take you to a timeline where the enterprise policy application should appear. Note that there is a known issue where the timeline entry may appear in a random language instead of matching your environment’s settings. If you see an unfamiliar entry in a language you don’t speak, that might be it. An online translator should help you confirm that it’s your new policy. If the policy does not appear, your integration likely failed, and you’ll have to backtrack and try to identify the problem in your setup.

Your Power Platform resources should now be able to connect to your Azure resources. If you find they cannot, confirm your Azure security settings on the network and resource levels and ensure you have the necessary permissions to access those resources.

Summary and key takeaways:

Integrating your Power Platform environments with Azure Virtual Networks strengthens security, increases your control over data, and ensures reliable and secure communication between systems.

In this blog post, I explained how to perform the integration, beginning with virtual network and subnet creation and configuring Azure resources for secure access by your systems. I took you step-by-step through running the scripts to perform the integration. I also explained the prerequisites and identified possible challenges you may encounter. I aimed to keep the content comprehensive and accessible, but if you have any questions or encounter further issues, feel free to comment below!