There is a growing discussion around security, with a strong emphasis on ensuring customer service safety while minimizing exposure on the public internet. To address this critical need, Virtual Network support has been introduced, allowing the use of Azure VNet subnet delegation to manage outbound traffic from the Power Platform.
Disclaimer: The architecture diagram and demo discussed in this article are aimed at showcasing VNet support capabilities for Power Platform, highlighting the results of proper configuration. The purpose of this article is twofold: first, to understand the VNet support feature in the Power Platform, and second, to learn the basic steps for configuring it. This knowledge will enable you to create your demo for a clearer understanding of the topic.
Using Virtual Network support enables secure communication between your Power Platform resources, like Power Apps and Power Automate flows, and Azure services without exposing them to the public internet.
Subnet delegation in Azure virtual networks allows you to assign a subnet to a PaaS service such as Azure SQL, Azure Storage, Azure Logic Apps, Azure Functions, etc., improving control over connections and enhancing performance and security. When delegated, the service can set network rules to ensure smooth operation. Azure services use private endpoints for security, and you can connect on-premises resources to the virtual network via ExpressRoute.
The diagram below outlines how the Virtual Network support feature is integrated within the Power Platform, as it relates to this article. This feature can take on various forms, depending on the specific Power Platform and Azure services that you wish to incorporate into your architecture.
The matrix below lists services that enable Azure subnet delegation for Virtual Network support in Power Platform.
| Area | Power Platform services | Virtual Network support availability |
| Dataverse | Dataverse plug-ins | Generally available |
| Connectors |
|
Generally available |
| Connectors |
|
Generally available |
Reference: Power Platform VNet Integration supported services
Prerequisites
Power Platform Environment Prerequisites
Not all Power Platform environments are eligible for the Virtual Network support feature. They must fulfil specific conditions, which are listed below:
- Power Platform environment must be a managed environment
- A user with the Power Platform Admin role
Azure Prerequisites
- Have an active Azure subscription
- Have a user with Owner/contributor access on the subscription
- Register the Microsoft.PowerPlatform resource provider in the subscription via the Azure Portal
- To do this, navigate to the Azure Subscription. Then go to Settings, select Resource Providers,
search for PowerPlatform, click on it, and then click the Register button.
Reference: Set up virtual network support for Power Platform(Prerequisites)
- Register the Microsoft.PowerPlatform resource provider in the subscription via a PowerShell script
- To do this, navigate to the enterprise Policies folder, download the SetupSubscriptionForPowerPlatform.ps1 file, and run it. It will prompt you for the Azure Subscription ID.
Once the script has run successfully, you will see the following result.
Let’s jump on the demo
After reading all this theory and fulfilling the prerequisites, I hope you have understood and digested most of what I describe. Now, let’s start by putting the pieces of the puzzle together.
Azure Resources
The primary resources needed are VNets with subnets. You will require both a primary and a secondary VNet; the secondary will operate as a failover for the primary, automatically directing traffic whenever the primary becomes unavailable.
The requirements on the Azure side are:
- Azure Resource Group
- 2 Azure VNets (You can set up VNet peering between your virtual networks (VNets) based on your specific requirements.)
- Assign one subnet to each Azure VNet delegated to Power Platform, which can be accomplished through either the Azure Portal or a PowerShell script detailed further below.
According to Microsoft recommendations based on telemetry data and remarks, it is advised to have between 25 and 30 IP addresses for the Production environment, and between 6 and 10 IP addresses for the Sandbox and Developer environments.
The image below depicts the two Azure VNets that have been deployed to West and North Europe, respectively, as one is the failover for the other.
If we examine the VNets for the subnet view, you will see the default subnet as well as the one I created for integration, which is delegated to Power Platform.
The screenshots below are not part of the demo since I only used one environment. I am sharing them to help you better understand the estimation of subnet sizes for both sandbox and production.
The first picture shows the recommended subnet size for Sandbox and Developer environments, which has 59 available IPs. While it’s commonly known that a /26 subnet allows for 64 hosts, it’s important to remember that Azure reserves the first 5 IP addresses. This is why we conclude that there are 59 usable IPs.
The second picture depicts the recommended subnet size for production environments, which allows for 27 available IP addresses. As mentioned earlier, a /27 subnet can accommodate a total of 32 hosts; however, Azure reserves the first 5 IP addresses. Therefore, we conclude that 27 is the number of available IPs in this range.
To create an Azure Virtual Network (VNet) with a subnet, you can read this article Deep Dive In VNet Subnets which explains VNet subnets and includes a demonstration on how to build one.
Once you complete the deployment of Azure VNets, take note of the following values:
Values correspondence for ARM Template
| Instance Details Field Names | Detailed Instructions |
| Policy Name | Type a name of your choice |
| Location | Use the GetSupportedEnterprisePolicyLocations.ps1 script to identify the regions that support VNet integration, as well as the one that matches your environment and the location of your Azure resources. |
| Vnet One Subnet Name | Type the Primary Azure VNet subnet name |
| Vnet One Resource Id | Copy the Resource ID of the Primary Azure VNet from the Virtual Network properties by navigating to Settings, then Properties, and selecting Resource ID. |
| Vnet Two Subnet Name | Enter the Secondary (Failover) Azure VNet subnet name |
| Vnet Two Resource Id | Copy the Resource ID of the Secondary (Failover) Azure VNet from the Virtual Network properties by navigating to Settings, then Properties, and selecting Resource ID. |
Values correspondence for the CreateSubnetInjectionEnterprisePolicy PS script
| Instance Details Field Names | Detailed Instructions |
| subscriptionId | Grab the subscription ID where you’re going to set up the enterprise policy. |
| resourceGroup | Type the Azure Resource Group you will create for the enterprise policy. |
| enterprisePolicyName | Enter a name of your choice |
| enterprisePolicyLocation | Use the GetSupportedEnterprisePolicyLocations.ps1 script to identify the regions that support VNet integration, as well as the one that matches your environment and the location of your Azure resources. |
| primaryVnetId | Copy the Resource ID of the Primary Azure VNet from the Virtual Network properties by navigating to Settings, then Properties, and selecting Resource ID. |
| primarySubnetName | Type the Primary Azure VNet subnet name |
| secondaryVnetId | Copy the Resource ID of the Secondary (Failover) Azure VNet from the Virtual Network properties by navigating to Settings, then Properties, and selecting Resource ID. |
| secondarySubnetName | Enter the Secondary (Failover) Azure VNet subnet name |
Values correspondence for the SetupVnetForSubnetDelegation PS script
| Instance Details Field Names | Detailed Instructions |
| virtualNetworkSubscriptionId | Grab the subscription ID where you created the Azure VNet |
| virtualNetworkName | Type the Azure Virtual Network Name |
| subnetName | Enter the Primary/Secondary Azure VNet subnet name |
Values correspondence for the NewSubnetInjection PS script
| Instance Details Field Names | Detailed Instructions |
| environmentId | Grab the Environment ID where you eject the VNet from the Power Platform admin portal |
| policyArmId | Replace the values inside the curly brackets with the actual ones:
/subscriptions/{subscription Id}/resourceGroups/{enterprise policy name}/providers/Microsoft.PowerPlatform/enterprisePolicies/{Policy Name} Reference: NewSubnetInjection |
Now, we will discuss the interesting part of the configuration, which includes PowerShell scripts and ARM templates.
Before moving on to this step, please ensure that you have completed the prerequisites listed below.
- Clone the GitHub repo (enterprisePolicies) that contains the PowerShell scripts for the enterprise policies to your local disk.
- Launch PowerShell ISE with administrative privileges.
- Verify that the user has the necessary permissions to access Azure resources and the Power Platform environment.
If you want to inject your Azure VNet to Power Platform using PowerShell scripts, follow the sequence outlined below and refer to the previous section for the necessary values.
The PowerShell scripts execution order is:
Script 1. InstallPowerAppsCmdlets.ps1
Script 2.SetupVnetForSubnetDelegation.ps1 (run this script one time for each subnet, primary and secondary)
Script 3. CreateSubnetInjectionEnterprisePolicy.ps1 (run this script to create the enterprise policy)
Script 4. NewSubnetInjection.ps1 (run the script to assign to your environment the enterprise policy)
Create the enterprise policy (ARM template)
There are two methods for creating the enterprise policy: one using PowerShell commands and the other utilizing an ARM template, which I demonstrate in this article.
The template used to create the enterprise policy is as follows:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"policyName": {
"type": "string",
"metadata": {
"description": "The name of the Enterprise Policy."
}
},
"powerplatformEnvironmentRegion": {
"type": "string",
"metadata": {
"description": "Geo of the PowerPlatform environment."
}
},
"vNetOneSubnetName": {
"type": "string"
},
"vNetOneResourceId": {
"type": "string",
"metadata": {
"description": "Fully qualified name, such as /subscription/{subscriptionid}/..."
}
},
"vNetTwoSubnetName": {
"defaultValue": "",
"type": "string"
},
"vNetTwoResourceId": {
"defaultValue": "",
"type": "string",
"metadata": {
"description": "Fully qualified name, such as /subscription/{subscriptionid}/..."
}
}
},
"variables": {
"vNetOne": {
"id": "[parameters('vNetOneResourceId')]",
"subnet": {
"name": "[parameters('vNetOneSubnetName')]"
}
},
"vNetTwo": {
"id": "[parameters('vNetTwoResourceId')]",
"subnet": {
"name": "[parameters('vNetTwoSubnetName')]"
}
},
"vNetTwoSupplied": "[and(not(empty(parameters('vNetTwoSubnetName'))), not(empty(parameters('vNetTwoResourceId'))))]"
},
"resources": [
{
"type": "Microsoft.PowerPlatform/enterprisePolicies",
"apiVersion": "2020-10-30-preview",
"name": "[parameters('policyName')]",
"location": "[parameters('powerplatformEnvironmentRegion')]",
"kind": "NetworkInjection",
"properties": {
"networkInjection": {
"virtualNetworks": "[if(variables('vNetTwoSupplied'), concat(array(variables('vNetOne')), array(variables('vNetTwo'))), array(variables('vNetOne')))]"
}
}
}
]
}
Deploy the ARM template
Navigate to the Azure Portal and search for the “custom template” service, as the image below depicts
Choose to Build your own template in the editor
Copy the JSON code from the ARM template above and click the Save button.
Type the values from the “Values correspondence for ARM Template” matrix and choose Review + Create.
Assign the enterprise policy to the environment
To assign the enterprise policy to the Power Platform environment, follow these steps:
Navigate to the Power Platform admin center.
On the left pane, choose Security – Data and privacy – Azure Virtual Network policies.
Choose the environment, i.e., cloudopszone-prod (the type is Sandbox, obviously, because this is not a real production environment), and tap the Next button.
Click the Assign button to apply the enterprise policy to the environment.
Now, click Save to finish the linking process.
Validation
To validate the connection, navigate to the Power Platform Admin Center.
In the left pane, select Manage, then Environments, and choose the Environment where the injection completed.
In the command bar at the top, tap the ellipsis button and select History.
If everything went as planned, you can confirm that the Network Injection Policy has been successfully completed.
Related links
- Virtual Network support overview
- Virtual Network support white paper
- Set up virtual network support for Power Platform