-Quota is specific to a (deployment type, mode, region) triplet and isn't interchangeable. Meaning you can't use quota for GPT-4 to deploy GPT-35-turbo. Customers can raise a support request to move the quota across deployment types, models, or regions but we can't guarantee that it will be possible.

-You must also include the `enhancements` and `dataSources` objects. `enhancements` represents the specific Vision enhancement features requested in the chat. It has a `grounding` and `ocr` property, which each have a boolean `enabled` property. Use these to request the OCR service and/or the object detection/grounding service. `dataSources` represents the Computer Vision resource data that's needed for Vision enhancement. It has a `type` property which should be `"AzureComputerVision"` and a `parameters` property. Set the `endpoint` and `key` to the endpoint URL and access key of your Computer Vision resource. Remember to set a `"max_tokens"` value, or the return output will be cut off.

-> Azure AI enhancements for GPT-4 Turbo with Vision will be billed separately from the core functionalities. Each specific Azure AI enhancement for GPT-4 Turbo with Vision has its own distinct charges.

-Processing videos will involve the use of extra tokens to identify key frames for analysis. The number of these additional tokens will be roughly equivalent to the sum of the tokens in the text input plus 700 tokens.

-#### Calculation

-For a typical use case let's imagine that I have use a 3-minute video with a 100-token prompt input. The section of video has a transcript that's 100-tokens long and when I process the prompt, I generate 100-tokens of output. The pricing for this transaction would be as follows:

-| Item | Detail | Total Cost |

-|-||--|

-| GPT-4 Turbo with Vision Input Tokens | 100 text tokens | $0.001 |

-| Additional Cost to identify frames | 100 input tokens + 700 tokens + 1 Video Retrieval txn | $0.00825 |

-| Image Inputs and Transcript Input | 20 images (85 tokens each) + 100 transcript tokens | $0.018 |

-| Output Tokens | 100 tokens (assumed) | $0.003 |

-| **Total Cost** | | **$0.03025** |

-Additionally, there's a one-time indexing cost of $0.15 to generate the Video Retrieval index for this 3-minute segment of video. This index can be reused across any number of Video Retrieval and GPT-4 Turbo with Vision calls.

-## Limitations

-### Image support

-### Video support

- api_key=os.environ['OPENAI_API_KEY']

- api_key=os.environ['OPENAI_API_KEY']

-OpenAI uses the `model` keyword argument to specify what model to use. Azure OpenAI has the concept of unique model [deployments](create-resource.md?pivots=web-portal#deploy-a-model). When using Azure OpenAI `model` should refer to the underling deployment name you chose when you deployed the model.

- model='gpt-3.5-turbo-instruct',

- model=gpt-35-turbo-instruct, # This must match the custom deployment name you chose for your model.

-The name `CVOID-19` might be recognized as `covered 19`. To make sure that `COVID-19 is a virus` is displayed instead of `covered 19 is a virus`, use the following rewrite rule:

-| properties.videoCodec | The codec for output video, could be h264, hevc or vp9.<br/><br/>Vp9 is required for transparent background.<br/><br/>This property is optional, and the default value is hevc.|

-| Contributor | User has full access to the Azure AI resource, including the ability to create new Azure AI resources, but isn't able to manage Azure AI resource permissions on the existing resource. |

-| Azure AI Developer | Perform all actions except create new Azure AI resources and manage the Azure AI resource permissions. For example, users can create projects, compute, and connections. Users can assign permissions within their project. Users can interact with existing AI resources such as Azure OpenAI, Azure AI Search, and Azure AI services. |

-| Reader | Read only access to the Azure AI resource. This role is automatically assigned to all project members within the Azure AI resource. |

-| Contributor | User has full access to the Azure AI project but can't assign permissions to project users. |

-| Azure AI Developer | User can perform most actions, including create deployments, but can't assign permissions to project users. |

-| Reader | Read only access to the Azure AI project. |

-1. Fill in **Subscription**, **Resource group**, and **Region**. **Name** your new Azure AI resource.

- :::image type="content" source="../media/how-to/resource-create-basics.png" alt-text="Screenshot of the option to set Azure AI resource basic information." lightbox="../media/how-to/resource-create-basics.png":::

-1. Select an existing **Azure AI services** or create a new one. New Azure AI services include multiple API endpoints for Speech, Content Safety and Azure OpenAI. You can also bring an existing Azure OpenAI resource. Optionally, choose an existing **Storage account**, **Key vault**, **Container Registry**, and **Application insights** to host artifacts generated when you use AI Studio.

-1. Set up Network isolation. Read more on [network isolation](configure-managed-network.md).

-1. Set up data encryption. You can either use **Microsoft-managed keys** or enable **Customer-managed keys**.

-1. By default, **System assigned identity** is enabled, but you can switch to **User assigned identity** if existing storage, key vault, and container registry are selected in Resources.

-1. Add tags.

-1. Select **Review + create**

-1. Select **+ Add** to add users to your Azure AI resource

-1. Select the **Role** you want to assign.

-1. Select the **Members** you want to give the role to.

-1. **Review + assign**. It can take up to an hour for permissions to be applied to users.

-1. Select **+ Add member**

-1. Enter the member's name in **Add member** and assign a **Role**. For most users, we recommend the AI Developer role. This permission applies to the entire Azure AI resource. If you wish to only grant access to a specific Project, manage permissions in the [Project](create-projects.md)

-# How to create and manage prompt flow runtimes in Azure AI Studio

-In Azure AI Studio, you can create and manage prompt flow runtimes. You need a runtime to use prompt flow.

-Prompt flow runtime has the computing resources required for the application to run, including a Docker image that contains all necessary dependency packages. In addition to flow execution, the runtime is also utilized to validate and ensure the accuracy and functionality of the tools incorporated within the flow, when you make updates to the prompt or code content.

-We support following types of runtimes:

-|automatic runtime |Serverless compute| Automatically | Easily customize python packages|

-|Compute instance runtime | Compute instance | Manually | |

-If you're a new user, we recommend using the automatic runtime that can be used out of box. You can easily customize the environment for this runtime.

-### Create automatic runtime in flow page

-Automatic is the default option for runtime, you can start automatic runtime in runtime dropdown in flow page.

- :::image type="content" source="../media/prompt-flow/how-to-create-manage-runtime/runtime-create-automatic-init.png" alt-text="Screenshot of prompt flow on the start automatic with default settings on flow page. " lightbox = "../media/prompt-flow/how-to-create-manage-runtime/runtime-create-automatic-init.png":::

- :::image type="content" source="../media/prompt-flow/how-to-create-manage-runtime/runtime-creation-automatic-settings.png" alt-text="Screenshot of prompt flow on the start automatic with advanced setting on flow page. " lightbox = "../media/prompt-flow/how-to-create-manage-runtime/runtime-creation-automatic-settings.png":::

-### Create compute instance runtime in runtime page

-A runtime requires a compute instance. If you don't have a compute instance, you can [create one in Azure AI Studio](./create-manage-compute.md).

-To create a prompt flow runtime in Azure AI Studio:

-1. Sign in to [Azure AI Studio](https://ai.azure.com) and select your project from the **Build** page. If you don't have a project already, first create a project.

-1. From the collapsible left menu, select **Settings**.

-1. Make sure that you have a compute instance available and running. If you don't have a compute instance, you can [create one in Azure AI Studio](./create-manage-compute.md).

- :::image type="content" source="../media/compute/runtime-create.png" alt-text="Screenshot of the create runtime button." lightbox="../media/compute/runtime-create.png":::

-1. Select a compute instance for the runtime and then select **Create**.

-1. Acknowledge the warning that the compute instance will be restarted and select **Confirm**.

- :::image type="content" source="../media/compute/runtime-create-confirm.png" alt-text="Screenshot of the option to confirm auto restart via the runtime creation." lightbox="../media/compute/runtime-create-confirm.png":::

-1. You'll be taken to the runtime details page. The runtime will be in the **Not available** status until the runtime is ready. This can take a few minutes.

- :::image type="content" source="../media/compute/runtime-creation-in-progress.png" alt-text="Screenshot of the runtime not yet available status." lightbox="../media/compute/runtime-creation-in-progress.png":::

-1. When the runtime is ready, the status will change to **Running**. You might need to select **Refresh** to see the updated status.

- :::image type="content" source="../media/compute/runtime-running.png" alt-text="Screenshot of the runtime is running status." lightbox="../media/compute/runtime-running.png":::

-1. Select the runtime from the **Prompt flow runtimes** tab to see the runtime details.

- :::image type="content" source="../media/compute/runtime-details.png" alt-text="Screenshot of the runtime details including environment." lightbox="../media/compute/runtime-details.png":::

-## Update runtime from UI

-### Update automatic runtime in flow page

-You can manage automatic runtime in the flow page. Here are options you can use:

-You can also customize the environment used to run this flow.

- :::image type="content" source="../media/prompt-flow/how-to-create-manage-runtime/runtime-create-automatic-save-install.png" alt-text="Screenshot of save and install packages for automatic runtime on flow page. " lightbox = "../media/prompt-flow/how-to-create-manage-runtime/runtime-create-automatic-save-install.png":::

-> You can change the location and even file name of `requirements.txt` by change it in `flow.dag.yaml` file in flow folder as well.

-> Please don't pin version of promptflow and promptflow-tools in `requirements.txt`, as we already include them in runtime base image.

-#### Add packages in private feed in Azure DevOps

-If you want to use a private feed in Azure DevOps, you need follow these steps:

-1. Create user assigned managed identity and add this user assigned managed identity in the Azure DevOps organization. To learn more, see [Use service principals & managed identities](/azure/devops/integrate/get-started/authentication/service-principal-managed-identity).

- > [!NOTE]

- > If the 'Add Users' button isn't visible, it's likely you don't have the necessary permissions to perform this action.

-

-1. [Add or update user assigned identities to project](../../machine-learning/how-to-identity-based-service-authentication.md#to-create-a-workspace-with-multiple-user-assigned-identities-use-one-of-the-following-methods).

-1. You need to add `{private}` to your private feed URL. For example, if you want to install `test_package` from `test_feed` in Azure devops, add `-i https://{private}@{test_feed_url_in_azure_devops}` in `requirements.txt`.

- ```

-1. Specify the user assigned managed identity in `start with advanced setting` if automatic runtime is not running or `edit` button if automatic runtime is running.

- :::image type="content" source="../media/prompt-flow/how-to-create-manage-runtime/runtime-advanced-setting-msi.png" alt-text="Screenshot of specify user assigned managed identity. " lightbox = "../media/prompt-flow/how-to-create-manage-runtime/runtime-advanced-setting-msi.png":::

-### Update compute instance runtime in runtime page

-Azure AI Studio gets regular updates to the base image (`mcr.microsoft.com/azureml/promptflow/promptflow-runtime-stable`) to include the latest features and bug fixes. You should periodically update your runtime to the [latest version](https://mcr.microsoft.com/v2/azureml/promptflow/promptflow-runtime-stable/tags/list) to get the best experience and performance.

-Go to the runtime details page and select **Update**. Here you can update the runtime environment. If you select **use default environment**, system will attempt to update your runtime to the latest version.

-Every time you view the runtime details page, AI Studio will check whether there are new versions of the runtime. If there are new versions available, you'll see a notification at the top of the page. You can also manually check the latest version by selecting the **check version** button.

-## Limitations

-Azure CNI Overlay networking in AKS currently has the following limitations:

-* In case you are using your own subnet to deploy the cluster, the names of the subnet, VNET and resource group which contains the VNET, must be 63 characters or less. This comes from the fact that these names will be used as labels in AKS worker nodes, and are therefore subjected to [Kubernetes label syntax rules](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).

-## Regional availability for ARM64 node pools

-Azure CNI Overlay is currently unavailable for ARM64 node pools in the following regions:

-* Network policies cannot use `ipBlock` to allow access to node or pod IPs ([Cilium issue #9209](https://github.com/cilium/cilium/issues/9209) and [#12277](https://github.com/cilium/cilium/issues/12277)).

-The following are the results from the [CIS Kubernetes V1.24 Benchmark v1.0.0][cis-benchmark-kubernetes] recommendations on AKS. These are applicable to AKS 1.21.x through AKS 1.24.x.

-*Scored* recommendations affect the benchmark score if they are not applied, while *Not Scored* recommendations don't.

-* *Fail* - The recommendation has not been applied.

-* *Depends on Environment* - The recommendation is applied in the user's specific environment and is not controlled by AKS. *Scored* recommendations affect the benchmark score whether the recommendation applies to the user's specific environment or not.

-|1.2.3|Ensure that `--DenyServiceExternalIPs` is not set|Scored|L1|Pass|

-|1.2.18|Ensure that the `--audit-log-path` argument is set|Scored|L1|Pass|

-|1.2.20|Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate|Scored|L1|Equivalent Control|

-|1.2.28|Ensure that the `--etcd-cafile` argument is set as appropriate|Scored|L1|Pass|

-|5.2.1|Minimize the admission of privileged containers|Not Scored|L1|Depends on Environment|

-|5.2.2|Minimize the admission of containers wishing to share the host process ID namespace|Scored|L1|Depends on Environment|

-|5.2.3|Minimize the admission of containers wishing to share the host IPC namespace|Scored|L1|Depends on Environment|

-|5.2.4|Minimize the admission of containers wishing to share the host network namespace|Scored|L1|Depends on Environment|

-|5.2.5|Minimize the admission of containers with allowPrivilegeEscalation|Scored|L1|Depends on Environment|

-|5.2.9|Minimize the admission of containers with capabilities assigned|Not Scored|L2|Depends on Environment|

-|5.5.1|Configure Image Provenance using ImagePolicyWebhook admission controller|Not Scored|L2|Depends on Environment|

-|5.6|General Policies||||

-|5.6.1|Create administrative boundaries between resources using namespaces|Not Scored|L1|Depends on Environment|

-|5.6.2|Ensure that the seccomp profile is set to docker/default in your pod definitions|Not Scored|L2|Depends on Environment|

-|5.6.3|Apply Security Context to Your Pods and Containers|Not Scored|L2|Depends on Environment|

-|5.6.4|The default namespace should not be used|Scored|L2|Depends on Environment|

-| balance-similar-node-groups | Detects similar node pools and balances the number of nodes between them | false |

-* Create an AKS cluster with a new managed NAT gateway using the [`az aks create`][az-aks-create] command with the `--outbound-type managedNATGateway`, `--nat-gateway-managed-outbound-ip-count`, and `--nat-gateway-idle-timeout` parameters. If you want the NAT gateway to operate out of a specific availability zone, specify the zones using `--zones`.

-* A managed NAT gateway resource cannot be used across multiple availability zones. When you deploy a managed NAT gateway instance, it is deployed to "no zone". No zone NAT gateway resources are deployed to a single availability zone for you by Azure. For more information on non-zonal deployment model, see [non-zonal NAT gateway](/azure/nat-gateway/nat-availability-zones#non-zonal).

- > [!IMPORTANT]

- > Zonal configuration for your NAT gateway resource can be done with user-assigned NAT gateway resources. See [Create an AKS cluster with a user-assigned NAT gateway](#create-an-aks-cluster-with-a-user-assigned-nat-gateway) for more details.

- > If no value for the outbound IP address is specified, the default value is one.

-3. On the popup that asks you to confirm the deletion of the cluster, select **Yes**.

-You can also automate your container deployment [with GitHub Actions](./deploy-ci-cd-custom-container.md). The workflow file below will build and tag the container with the commit ID, push it to a container registry, and update the specified site slot with the new image tag.

-name: Build and deploy a container image to Azure Web Apps

-

- - uses: actions/checkout@main

- -name: Authenticate using a Service Principal

- uses: azure/actions/login@v1

- with:

- creds: ${{ secrets.AZURE_SP }}

- - uses: azure/container-actions/docker-login@v1

- username: ${{ secrets.DOCKER_USERNAME }}

- password: ${{ secrets.DOCKER_PASSWORD }}

- - name: Build and push the image tagged with the git commit hash

- run: |

- docker build . -t contoso/demo:${{ github.sha }}

- docker push contoso/demo:${{ github.sha }}

- - name: Update image tag on the Azure Web App

- uses: azure/webapps-container-deploy@v1

- app-name: '<your-webapp-name>'

- slot-name: '<your-slot-name>'

- images: 'contoso/demo:${{ github.sha }}'

-### Limitations

-+ Your [function app runtime version](set-runtime-version.md) must be 4.3.0 or a later version.

-Azure Maps doesn't count billing transactions for:

-For more information on billing transactions and other Azure Maps pricing information, see [Azure Maps pricing].

-> [!NOTE]

-> The Geofence API async event requires the region property of your Azure Maps account be set to ***Global***. When creating an Azure Maps account in the Azure portal, this isn't given as an option. For more information, see [Create an Azure Maps account with a global region].

-* The Geofence API async event requires the region property of your Azure Maps account be set to ***Global***. When creating an Azure Maps account in the Azure portal, this isn't given as an option. For more information, see [Create an Azure Maps account with a global region].

-[Create an Azure Maps account with a global region]: tutorial-geofence.md#create-an-azure-maps-account-with-a-global-region

-> * Create an Azure Maps account with a global region.

-* This tutorial uses the [Postman] application, but you can use a different API development environment.

-> * In the URL examples, replace `{Your-Azure-Maps-Subscription-key}` with your Azure Maps subscription key.

-## Create an Azure Maps account with a global region

-The Geofence API async event requires the region property of your Azure Maps account be set to ***Global***. This setting isn't given as an option when creating an Azure Maps account in the Azure portal, however you do have several other options for creating a new Azure Maps account with the *global* region setting. This section lists the three methods that can be used to create an Azure Maps account with the region set to *global*.

-> [!NOTE]

-> The `location` property in both the ARM template and PowerShell `New-AzMapsAccount` command refer to the same property as the `Region` field in the Azure portal.

-### Use an ARM template to create an Azure Maps account with a global region

-[Create your Azure Maps account using an ARM template], making sure to set `location` to `global` in the `resources` section of the ARM template.

-### Use PowerShell to create an Azure Maps account with a global region

-```powershell

-New-AzMapsAccount -ResourceGroupName your-Resource-Group -Name name-of-maps-account -SkuName g2 -Location global

-```

-### Use Azure CLI to create an Azure Maps account with a global region

-The Azure CLI command [az maps account create] doesnΓÇÖt have a location property, but defaults to `global`, making it useful for creating an Azure Maps account with a global region setting for use with the Geofence API async event.

-Follow the steps outlined in the [How to create data registry] article to upload the geofence JSON file into your Azure storage account then register it in your Azure Maps account.

-3. In the **Search the Marketplace** box, type **Logic App**.

- :::image type="content" source="./media/tutorial-geofence/logic-app-create.png" alt-text="Screenshot of create a logic app.":::

-6. Select **Review + Create**. Review your settings and select **Create**.

-8. In the **Logic App Designer**, scroll down to the **Start with a common trigger** section. Select **When an HTTP request is received**.

- :::image type="content" source="./media/tutorial-geofence/logic-app-trigger.png" alt-text="Screenshot of create a logic app HTTP trigger.":::

- :::image type="content" source="./media/tutorial-geofence/logic-app-httprequest.png" alt-text="Screenshot of Logic App HTTP Request URL and JSON.":::

- :::image type="content" source="./media/tutorial-geofence/logic-app-designer.png" alt-text="Screenshot of create a logic app designer.":::

- :::image type="content" source="./media/tutorial-geofence/logic-app-email.png" alt-text="Screenshot of create a logic app send email step.":::

- :::image type="content" source="./media/tutorial-geofence/events-subscription.png" alt-text="Screenshot of Azure Maps events subscription details.":::

-You can also [Send email notifications using Event Grid and Logic Apps] and check [Supported Events Handlers in Event Grid] using Azure Maps.

-[az maps account create]: /cli/azure/maps/account?view=azure-cli-latest&preserve-view=true#az-maps-account-create

-[Create your Azure Maps account using an ARM template]: how-to-create-template.md

-[Supported Events Handlers in Event Grid]: ../event-grid/event-handlers.md

-These telemetry items can be found in the same places as any other `TraceTelemetry` or `ExceptionTelemetry` items for Application Insights, including the Azure portal, analytics, or the Visual Studio local debugger.

-`pattern` can contain a named group placed betwen `?<` and `>:`. Example: `(?<userGroupName>[a-zA-Z.:\/]+)\d+`? The group is `(?<userGroupName>[a-zA-Z.:\/]+)` and `userGroupName` is the name of the group. `pattern` can then contain the same named group placed between `${` and `}` followed by the mask. Example where the mask is **: `${userGroupName}**`.

-description: Run and manage a chaos experiment with Azure Chaos Studio by using REST APIs.

-# Use the Chaos Studio REST APIs to run and manage chaos experiments

-> [!WARNING]

-> Injecting faults can affect your application or service. Be careful not to disrupt customers.

-The Azure Chaos Studio REST API provides support for starting experiments programmatically. You can also use the Azure Resource Manager client and the Azure CLI to execute these commands from the console. The examples in this article are for the Azure CLI.

-> [!Warning]

-> These APIs are still under development and subject to change.

-## REST APIs

-* Start, stop, and manage experiments.

-* View and manage targets.

-* Query experiment status.

-* Query and delete subscription configurations.

-Use the `AZ CLI` utility to perform these actions from the command line.

-> To get more verbose output with the AZ CLI, append `--verbose` to the end of each command. This variable returns more metadata when commands execute, including `x-ms-correlation-request-id`, which aids in debugging.

-### Chaos Studio provider commands

-This section lists the Chaos Studio provider commands.

-#### List details about the Microsoft.Chaos resource provider

-az rest --method get --url "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Chaos?api-version={apiVersion}" --resource "https://management.azure.com"

-#### List all the operations of the Microsoft.Chaos resource provider

-az rest --method get --url "https://management.azure.com/providers/Microsoft.Chaos/operations?api-version={apiVersion}" --resource "https://management.azure.com"

-#### List Chaos provider configurations

-az rest --method get --urlΓÇ»"https://management.azure.com/subscriptions/{subscriptionId}/providers/microsoft.chaos/chaosProviderConfigurations/?api-version={apiVersion}" --resource "https://management.azure.com" --verbose

-#### Create Chaos provider configuration

-az rest --method put --url "https://management.azure.com/subscriptions/{subscriptionId}/providers/microsoft.chaos/chaosProviderConfigurations/{chaosProviderType}?api-version={apiVersion}" --body @{providerSettings.json} --resource "https://management.azure.com"

-### Chaos Studio target and agent commands

-This section lists the Chaos Studio target and agent commands.

-#### List all the targets or agents under a subscription

-az rest --method get --url "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Chaos/chaosTargets/?api-version={apiVersion}" --url-parameter "chaosProviderType={chaosProviderType}" --resource "https://management.azure.com"

-### Chaos Studio experiment commands

-This section lists the Chaos Studio experiment commands.

-#### List all the experiments in a resource group

-az rest --method get --url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Chaos/chaosExperiments?api-version={apiVersion}" --resource "https://management.azure.com"

-#### Get an experiment's configuration details by name

-az rest --method get --url "https://management.azure.com/{experimentId}?api-version={apiVersion}" --resource "https://management.azure.com"

-#### Create or update an experiment

-az rest --method put --url "https://management.azure.com/{experimentId}?api-version={apiVersion}" --body @{experimentName.json} --resource "https://management.azure.com"

-#### Delete an experiment

-az rest --method delete --url "https://management.azure.com/{experimentId}?api-version={apiVersion}" --resource "https://management.azure.com" --verbose

-#### Start an experiment

-#### Get past statuses of an experiment

-az rest --method get --url "https://management.azure.com/{experimentId}/statuses?api-version={apiVersion}" --resource "https://management.azure.com"

-#### Get the status of an experiment

-az rest --method get --url "https://management.azure.com/{experimentId}/status?api-version={apiVersion}" --resource "https://management.azure.com"

-#### Cancel (stop) an experiment

-az rest --method get --url "https://management.azure.com/{experimentId}/cancel?api-version={apiVersion}" --resource "https://management.azure.com"

-#### List the details of the last two experiment executions

-az rest --method get --url "https://management.azure.com/{experimentId}/executiondetails?api-version={apiVersion}" --resource "https://management.azure.com"

-#### List the details of a specific experiment execution

-az rest --method get --url "https://management.azure.com/{experimentId}/executiondetails/{executionDetailsId}?api-version={apiVersion}" --resource "https://management.azure.com"

-| Parameter name | Definition | Lookup |

-| | | |

-| {apiVersion} | Version of the API to use when you execute the command provided | Can be found in the [API documentation](/rest/api/chaosstudio/) |

-| {experimentId} | Azure Resource ID for the experiment | Can be found on the [Chaos Studio Experiment page](https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.chaos%2Fchaosexperiments) |

-| {chaosProviderType} | Type or Name of Chaos Studio provider | Available providers can be found in the [List of current Provider Config Types](chaos-studio-fault-providers.md) |

-| {experimentName.json} | JSON that contains the configuration of the chaos experiment | Generated by the user |

-| {subscriptionId} | Subscription ID where the target resource is located | Can be found on the [Subscriptions page](https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade) |

-| {resourceGroupName} | Name of the resource group where the target resource is located | Can be found on the [Resource groups page](https://portal.azure.com/#blade/HubsExtension/BrowseResourceGroups) |

-| {executionDetailsId} | Execution ID of an experiment execution | Can be found on the [Chaos Studio Experiment page](https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.chaos%2Fchaosexperiments) |

-## Log structure

-Azure Communication Services creates two types of logs:

-In a P2P call, each log contains data that relates to each of the outbound streams associated with each endpoint. In a group call, each stream associated with `endpointType` = `"Server"` creates a log that contains data for the inbound streams. All other streams create logs that contain data for the outbound streams for all non-server endpoints. In group calls, use the `participantId` value as the key to join the related inbound and outbound logs into a distinct participant connection.

-The following diagram represents two endpoints connected directly in a P2P call. In this example, Communication Services creates two call summary logs (one for each `participantID` value) and four call diagnostic logs (one for each media stream). Each log contains data that relates to the outbound stream of `participantID`.

-The following diagram represents a group call example with three `participantID` values (which means three participants) and a server endpoint. Values for `endpointId` can potentially appear in multiple participants--for example, when they rejoin a call from the same device. Communication Services creates one call summary log for each `participantID` value. It creates four call diagnostic logs: one for each media stream per `participantID`.

-### Example: Cross-tenant P2P call

-### Example: Cross-tenant group call

-### P2P call

-#### Call summary logs

-#### Call diagnostic logs

-### Error codes

-If you encounter quality or reliability issues you are unable to resolve and need support, you can submit a request for technical support. See: [How to create azure support requests](/azure/azure-portal/supportability/how-to-create-azure-support-request)

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

-Before you run this command, replace `<REGISTRY_CONTAINER_NAME>` with the full name the public container registry location, including the registry path and tag. For example, a valid container name is `mcr.microsoft.com/azuredocs/containerapps-helloworld:latest`.

-az group create --location centralus --resource-group name my-container-apps

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest `

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

- Image = "mcr.microsoft.com/azuredocs/containerapps-helloworld:latest"

-An Azure account with an active subscription is required. If you don't already have one, you can [create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F). Also, please make sure to have the Resource Provider "Microsoft.App" registered.

-7. Select the **Create** button at the bottom of the *Create Container App Environment* page.

-Select **Go to resource** to view your new container app. Select the link next to *Application URL* to view your application. You'll see the following message in your browser.

-1. Select **Delete**.

- The process to delete the resource group may take a few minutes to complete.

- Image = 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

- Image = 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest `

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

- --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \

-* PgBouncer

-1. If you get errors, the account may not be valid in the active directory. Azure uses User Principal Name (UPN), which isn't always identical to the email address.

-Work or school accounts are available to organizations that have set up Active Directory with federation and where all accounts are on a single tenant. Users can be added with work or school federated user authentication if the company's internal Active Directory is federated.

-If your organization doesn't use Active Directory federation, you can't use your work or school email address. Instead, register or create a new email address and register it as a Microsoft account.

- - If you're using your work account, enter your work email and work password. Your work password is provided by your organization. You can check with your IT department about how to reset the password if you've issues with it.

- - You'll see the **Manage how to sign in to Microsoft** page where you can view your account aliases. Check that the primary alias is the one that you're using to sign in to the Azure EA portal. If it isn't, you can make it your primary alias. Or, you can use the primary alias for Azure EA portal instead.

-### Subscriptions leaving AAD directory

-### Subscriptions entering AAD directory

- - For Enterprise Agreement customers, the billing context is the enrollment. The reservation shared scope would include multiple Active Directory tenants in an enrollment.

- - For enterprise customers, the billing context is the EA enrollment. The reservation shared scope would include multiple Active Directory Microsoft Entra tenants in an enrollment.

- - For Enterprise Agreement customers, the billing context is the enrollment. The savings plan shared scope would include multiple Active Directory tenants in an enrollment.

-description: Apache Airflow configuration options can be attached to your Azure Managed Integration Runtimes for Apache Airflow environment as key value pairs

-# Apache Airflow configuration options on Azure Managed Airflow

-Apache Airflow configuration options can be attached to your Azure Managed Integration runtime as key value pairs. While we don't expose the `airflow.cfg` in Managed Airflow UI, users can override the Apache Airflow configurations directly on UI as key value pairs under `Airflow Configuration overrides` section and continue using all other settings in `airflow.cfg`. In Azure Managed Airflow, developers can override any of the Airflow configurations provided by Apache Airflow except the following shown in the table.

-For the Airflow configurations reference, see [Airflow Configurations](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html)

-**The following table contains the list of configurations does not support overrides.**

-|Configuration |Description | Default Value

-|[AIRFLOW__CORE__DONOT_PICKLE](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#donot-pickle) |Whether to disable pickling dags. |false |

-|[AIRFLOW__CORE__ENABLE_XCOM_PICKLING](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#enable-xcom-pickling) |Whether to enable pickling for xcom. |false |

-|[AIRFLOW__CORE__EXECUTOR](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#executor) |The executor class that airflow should use. |CeleryExecutor |

-|[AIRFLOW__CORE__FERNET_KEY](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#fernet-key) |Secret key to save connection passwords in the db. |AIRFLOW_FERNET_KEY |

-|[AIRFLOW__CORE__DAGS_ARE_PAUSED_AT_CREATION](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#dags-are-paused-at-creation) |Are DAGs paused by default at creation |False |

-|[AIRFLOW__CORE__PLUGINS_FOLDER](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#plugins-folder) |Path to the folder containing Airflow plugins. |AIRFLOW_PLUGINS_FOLDER |

-|[AIRFLOW__LOGGING__BASE_LOG_FOLDER](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#base-log-folder) |The folder where airflow should store its log files.|/opt/airflow/logs |

-|[AIRFLOW__LOGGING__LOG_FILENAME_TEMPLATE](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#log-filename-template) |Formatting for how airflow generates file names/paths for each task run. |{{ ti.dag_id }}/{{ ti.task_id }}/{{ ts }}/{{ try_number }}.log |

-|[AIRFLOW__LOGGING__DAG_PROCESSOR_MANAGER_LOG_LOCATION](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#dag-processor-manager-log-location) |Full path of dag_processor_manager logfile. |/opt/airflow/logs/dag_processor_manager/dag_processor_manager.log |

-|[AIRFLOW__LOGGING__LOGGING_CONFIG_CLASS](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#logging-config-class) |Logging config class specifies the logging configuration. This class has to be on the python classpath. |log_config.LOGGING_CONFIG |

-|[AIRFLOW__SCHEDULER__DAG_DIR_LIST_INTERVAL](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#dag-dir-list-interval) |How often (in seconds) to scan the DAGs'directory for new files. Default to 5 minutes. |5|

-|[AIRFLOW__WEBSERVER__BASE_URL](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#webserver) |The base url of your website as airflow cannot guess what domain or cname you are using. This url is used in automated emails that airflow sends to point links to the right web server. |https://localhost:8080 |

-|[AIRFLOW__WEBSERVER__COOKIE_SAMESITE](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#cookie-samesite) |Set samesite policy on session cookie |None |

-|[AIRFLOW__WEBSERVER__COOKIE_SECURE](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#cookie-secure) |Set secure flag on session cookie |True |

-|AIRFLOW__WEBSERVER__AUTHENTICATE |Authenticate user to login into Airflow UI. |True |

-|[AIRFLOW__WEBSERVER__RELOAD_ON_PLUGIN_CHANGE](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#reload-on-plugin-change) |If set to True, Airflow tracks files in plugins_folder directory. When it detects changes, then reload the gunicorn. |True |

-|[AIRFLOW__API__AUTH_BACKEND](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#auth-backends) |Comma separated list of auth backends to authenticate users of the API. |airflow.api.auth.backend.basic_auth |

-description: This document talks about recommended deployment patterns with Azure Managed Airflow

-# CI/CD Patterns with Azure Managed Airflow

-Azure Data Factory's Managed Airflow service is a simple and efficient way to create and manage Apache Airflow environments, enabling you to run data pipelines at scale with ease. There are two primary methods to run directed acyclic graphs (DAGs) in Azure Managed Airflow. You can either upload the DAG files in your blob storage and link them with the Airflow environment.

-Alternatively, you can use the Git-sync feature to automatically sync your Git repository with the Airflow environment.

-Working with data pipelines in Airflow requires you to create or update your DAGs, plugins and requirement files frequently, based upon your workflow needs. While developers can manually upload or edit DAG files in blob storage, many organizations prefer to use a CI/CD approach for code deployment. Therefore, this guide walks you through the recommended deployment patterns to seamlessly integrate and deploy your Apache Airflow DAGs with the Azure Managed Airflow service. 

-## Understanding CI/CD 

-### Continuous Integration (CI) 

-Continuous Integration (CI) is a software development practice that emphasizes frequent and automated integration of code changes into a shared repository. It involves developers regularly committing their code, and upon each commit, an automated CI pipeline builds the code, runs tests, and performs validation checks. The primary goal is to detect and address integration issues early in the development process, providing rapid feedback to developers. CI ensures that the codebase remains in a constantly testable and deployable state. This practice leads to enhanced code quality, collaboration, and the ability to catch and fix bugs before they become significant problems. 

-### Continuous Deployment (CD)

-Continuous Deployment (CD) is an extension of CI that takes the automation one step further. While CI focuses on automating the integration and testing phases, CD automates the deployment of code changes to production or other target environments. This practice helps organizations release software updates quickly and reliably. It reduces mistakes in manual deployment and ensures that approved code changes are delivered to end-users swiftly. 

-## CI/CD Workflow Within Azure Managed Airflow: 

-#### Git-sync with Dev/QA IR: Map your Managed Airflow environment with your Git repository’s Development/QA branch. 

-**CI Pipeline with Dev/QA IR:**

-When a pull request (PR) is made from a feature branch to the Development branch, it triggers a PR pipeline. This pipeline is designed to efficiently perform quality checks on your feature branches, ensuring code integrity and reliability. The following types of checks can be included in the pipeline: 

-If any of these checks fail, the pipeline terminates, signaling that the developer needs to address the issues identified. 

-#### Git-sync with Production IR: Map your Managed Airflow environment with your Git repository’s Production branch. 

-**PR pipeline with Prod IR:** 

-It's considered a best practice to maintain a separate production environment to prevent every development feature from becoming publicly accessible. 

-Once the Feature branch successfully merges into Development branch, you can create a pull request to the production branch in order to make your newly merged feature public. This pull request triggers the PR pipeline that conducts rapid quality checks on the Development branch to ensure that all features have been integrated correctly and there are no errors in the production environment.

-### Benefits of using CI/CD workflow in Managed Airflow 

-## Deployment Patterns in Azure Managed Airflow: 

-### Pattern 1: Develop data pipelines directly in Azure Managed Airflow. 

-### Prerequisites: 

-### Advantages: 

-### Workflow: 

-1. **Leverage Git-sync feature:** 

-In this workflow, there's no requirement to establish your own local environment. Instead, you can start by using the Git-sync feature offered by the Managed Airflow service. This feature automatically synchronizes your DAG files with Airflow webservers, schedulers, and workers, allowing you to develop, test, and execute your data pipelines directly through the Managed Airflow UI. 

-Learn more about how to use Azure Managed Airflow's [Git-sync feature](airflow-sync-github-repository.md).

-2. **Individual Feature branch Environment:** 

-You can choose the branch from your repository to sync with Azure Managed Airflow. This capability lets you create individual Airflow Environment for each feature branch, allowing developers to work on specific tasks for data pipelines. 

-3. **Create a Pull Request:** 

-Proceed to submit a Pull Request (PR) to the Airflow Development Environment (DEV IR), once you have thoroughly developed and tested your features within your dedicated Airflow Environment.

-### Pattern 2: Develop DAGs Locally and Deploy on Managed Airflow

-### Prerequisites: 

-### Advantages: 

-**Limited Access:** You can limit access to Azure resources to admin only. 

-### Workflow: 

-1. **Local Environment Setup** 

-Begin by setting up a local development environment for Apache Airflow on your development machine. In this environment, you can develop and test your Airflow code, including DAGs and tasks. This approach allows you to develop pipelines without relying on direct access to Azure resources.

-2. **Leverage Git-sync feature:** 

-Synchronize your GitHub repository’s branch with Azure Managed Airflow Service. 

-Learn more about how to use Azure Managed Airflow's [Git-sync feature](airflow-sync-github-repository.md).

-3. **Utilize Managed Airflow Service as Production environment:** 

-After successfully developing and testing data pipelines on your local setup, you can raise a Pull Request (PR) to the branch synchronized with the Managed Airflow Service. Once the branch is merged, utilize the Managed Airflow service's features like autoscaling and monitoring and logging at production level. 

-## Sample CI/CD Pipeline

-**Step 1:** Copy the code of a DAG deployed in Managed Airflow IR using the Git-sync feature.

-```python

-from datetime import datetime

-from airflow import DAG

-from airflow.operators.bash import BashOperator

-with DAG(

-ΓÇ» ΓÇ» dag_id="airflow-ci-cd-tutorial",

-ΓÇ» ΓÇ» start_date=datetime(2023, 8, 15),

-ΓÇ» ΓÇ» schedule="0 0 * * *",

-ΓÇ» ΓÇ» tags=["tutorial", "CI/CD"]

-) as dag:

-ΓÇ» ΓÇ» # Tasks are represented as operators

-ΓÇ» ΓÇ» task1 = BashOperator(task_id="task1", bash_command="echo task1")

-ΓÇ» ΓÇ» task2 = BashOperator(task_id="task2", bash_command="echo task2")

-ΓÇ» ΓÇ» task3 = BashOperator(task_id="task3", bash_command="echo task3")

-ΓÇ» ΓÇ» task4 = BashOperator(task_id="task4", bash_command="echo task4")

-ΓÇ» ΓÇ» # Set dependencies between tasks

-ΓÇ» ΓÇ» task1 >> task2 >> task3 >> task4

-```

-**Step 2:** Create a CI/CD pipeline.

-### Using Azure Devops

-**Step 2.1:** Create a file `azure-devops-ci-cd.yaml` and copy the following code. The pipeline triggers on pull request or push request to dev branch:

-```python

-trigger:

-pr:

-pool:

- vmImage: ubuntu-latest

-strategy:

- matrix:

- Python3.11:

- python.version: '3.11.5'

-steps:

- inputs:

- versionSpec: '$(python.version)'

- displayName: 'Use Python $(python.version)'

- python -m pip install --upgrade pip

- pip install -r requirements.txt

- displayName: 'Install dependencies'

- airflow webserver &

- airflow db init

- airflow scheduler &

- pytest

- displayName: 'Pytest'

-```

-For more information, See [Azure Pipelines](/azure/devops/pipelines/get-started/pipelines-sign-up)

-### Using GitHub Actions

-**Step 2.1:** Create a `.github/workflows` directory in your GitHub repository. 

-**Step 2.2:** In the `.github/workflows` directory, create a file named `github-actions-ci-cd.yml` 

-**Step 2.3:** Copy the following code: The pipeline triggers whenever there's pull request or push request to dev branch:

-```python

-name: GitHub Actions CI/CD

-on:

-ΓÇ» pull_request:

-ΓÇ» ΓÇ» branches:

-ΓÇ» ΓÇ» ΓÇ» - "dev"

-ΓÇ» push:

-ΓÇ» ΓÇ» branches:

-ΓÇ» ΓÇ» ΓÇ» - "dev"

-jobs:

-ΓÇ» flake8:

-ΓÇ» ΓÇ» strategy:

-ΓÇ» ΓÇ» ΓÇ» matrix:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» python-version: [3.11.5]

-ΓÇ» ΓÇ» runs-on: ubuntu-latest

-ΓÇ» ΓÇ» steps:

-ΓÇ» ΓÇ» ΓÇ» - name: Check out source repository

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» uses: actions/checkout@v4

-ΓÇ» ΓÇ» ΓÇ» - name: Setup Python

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» uses: actions/setup-python@v4

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» with:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» python-version: ${{matrix.python-version}}

-ΓÇ» ΓÇ» ΓÇ» - name: flake8 Lint

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» uses: py-actions/flake8@v1

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» with:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» max-line-length: 120

-ΓÇ» tests:

-ΓÇ» ΓÇ» strategy:

-ΓÇ» ΓÇ» ΓÇ» matrix:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» python-version: [3.11.5]

-ΓÇ» ΓÇ» runs-on: ubuntu-latest

-ΓÇ» ΓÇ» needs: [flake8]

-ΓÇ» ΓÇ» steps:

-ΓÇ» ΓÇ» ΓÇ» - uses: actions/checkout@v4

-ΓÇ» ΓÇ» ΓÇ» - name: Setup Python

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» uses: actions/setup-python@v4

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» with:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» python-version: ${{matrix.python-version}}

-ΓÇ» ΓÇ» ΓÇ» - name: Install dependencies

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» run: |

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» python -m pip install --upgrade pip

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» pip install -r requirements.txt

-ΓÇ» ΓÇ» ΓÇ» - name: Pytest

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» run: |

- airflow webserver &

- airflow db init

- airflow scheduler &

- pytest tests/

-```

-**Step 3:** In the tests folder, create the tests for Airflow DAGs. Following are the few examples: 

-* At the least, it's crucial to conduct initial testing using `import_errors` to ensure the DAG's integrity and correctness. 

-This test ensures: 

-```python

-@pytest.fixture()

-def dagbag():

-ΓÇ» ΓÇ» return DagBag(dag_folder="dags")

-def test_no_import_errors(dagbag):

-ΓÇ» ΓÇ» """

-ΓÇ» ΓÇ» Test Dags to contain no import errors.

-ΓÇ» ΓÇ» """

-ΓÇ» ΓÇ» assert not dagbag.import_errors

-```

-* Test to ensure specific Dag IDs to be present in your feature branch before merging it into the development (dev) branch. 

-```python

-def test_expected_dags(dagbag):

-ΓÇ» ΓÇ» """

-ΓÇ» ΓÇ» Test whether expected dag Ids are present.

-ΓÇ» ΓÇ» """

-ΓÇ» ΓÇ» expected_dag_ids = ["airflow-ci-cd-tutorial"]

-ΓÇ» ΓÇ» for dag_id in expected_dag_ids:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» dag = dagbag.get_dag(dag_id)

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» assert dag is not None

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» assert dag_id == dag.dag_id

-```

-* Test to ensure only approved tags are associated with your DAGs. This test helps to enforce the approved tag usage. 

-```python

-def test_requires_approved_tag(dagbag):

-ΓÇ» ΓÇ» """

-ΓÇ» ΓÇ» Test if DAGS contain one or more tags from list of approved tags only.

-ΓÇ» ΓÇ» """

-ΓÇ» ΓÇ» Expected_tags = {"tutorial", "CI/CD"}

-ΓÇ» ΓÇ» dagIds = dagbag.dag_ids

-ΓÇ» ΓÇ» for id in dagIds:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» dag = dagbag.get_dag(id)

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» assert dag.tags

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» if Expected_tags:

-ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» ΓÇ» assert not set(dag.tags) - Expected_tags

-```

-**Step 4:** Now, when you raise pull request to dev branch, GitHub Actions triggers the CI pipeline to run all the tests. 

-#### For more information:

-description: Learn how to copy and transform data to and from Microsoft Fabric Lakehouse (Preview) using Azure Data Factory or Azure Synapse Analytics pipelines.

-# Copy and transform data in Microsoft Fabric Lakehouse (Preview) using Azure Data Factory or Azure Synapse Analytics

-This article outlines how to use Copy activity to copy data from and to Microsoft Fabric Lakehouse (Preview) and use Data Flow to transform data in Microsoft Fabric Lakehouse (Preview). To learn more, read the introductory article for [Azure Data Factory](introduction.md) or [Azure Synapse Analytics](../synapse-analytics/overview-what-is.md).

-> [!IMPORTANT]

-> This connector is currently in preview. You can try it out and give us feedback. If you want to take a dependency on preview connectors in your solution, please contact [Azure support](https://azure.microsoft.com/support/).

-| Supported capabilities|IR | Managed private endpoint|

-|| --| --|

-|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

-|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |- |

-1. Register an application with the Microsoft Identity platform. To learn how, see [Quickstart: Register an application with the Microsoft identity platform](../active-directory/develop/quickstart-register-app.md). Make note of these values, which you use to define the linked service:

- - Application ID

- - Application key

-| servicePrincipalCredential | The service principal credential. <br/> When you use **ServicePrincipalKey** as the credential type, specify the application's key. Mark this field as **SecureString** to store it securely, or [reference a secret stored in Azure Key Vault](store-credentials-in-key-vault.md). <br/> When you use **ServicePrincipalCert** as the credential, reference a certificate in Azure Key Vault, and ensure the certificate content type is **PKCS #12**.| Yes |

-| filesystem<br/>&nbsp;&nbsp;&nbsp;&nbsp;FolderA<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**File1.csv**<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;File2.json<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Subfolder1<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**File3.csv**<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;File4.json<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**File5.csv**<br/>&nbsp;&nbsp;&nbsp;&nbsp;Metadata<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FileListToCopy.txt | File1.csv<br>Subfolder1/File3.csv<br>Subfolder1/File5.csv | **In dataset:**<br>- File system: `filesystem`<br>- Folder path: `FolderA`<br><br>**In copy activity source:**<br>- File list path: `filesystem/Metadata/FileListToCopy.txt` <br><br>The file list path points to a text file in the same data store that includes a list of files you want to copy, one file per line with the relative path to the path configured in the dataset. |

-description: This article explains how to use diagnostic logs and metrics to monitor Airflow IR.

-This guide walks you through the following:

-1. How to enable diagnostics logs and metrics for the Managed Airflow.

-2. How to view logs and metrics.

-3. How to run a query.

-4. How to monitor metrics and set the alert system in Dag failure.

-## How to enable Diagnostics logs and metrics for the Managed Airflow

-1. Open your Azure Data Factory resource -> Select **Diagnostic settings** on the left navigation pane -> Select ΓÇ£Add Diagnostic setting.ΓÇ¥

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/start-with-diagnostic-logs.png" alt-text="Screenshot that shows where diagnostic logs tab is located in data factory." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/start-with-diagnostic-logs.png":::

-2. Fill out the Diagnostic settings name -> Select the following categories for the Airflow Logs

- - Airflow dag processing logs

- - If you select **AllMetrics**, various Data Factory metrics are made available for you to monitor or raise alerts on. These metrics include the metrics for Data Factory activity and Managed Airflow IR such as AirflowIntegrationRuntimeCpuUsage, AirflowIntegrationRuntimeMemory.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/select-log-category-and-all-metrics.png" alt-text="Screenshot that shows which logs to select for Airflow environment." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/select-log-category-and-all-metrics.png":::

-3. Select the destination details, Log Analytics workspace:

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/select-log-analytics-workspace.png" alt-text="Screenshot that shows select log analytics workspace as destination for diagnostic logs." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/select-log-analytics-workspace.png":::

-4. Click on Save.

-## How to view logs

-1. After adding Diagnostic settings, you can find them listed in the "**Diagnostic settings**" section. To access and view logs, simply click on the Log Analytics workspace that you've configured.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/01-click-on-log-analytics-workspace.png" alt-text="Screenshot that shows click on log analytics workspace url." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/01-click-on-log-analytics-workspace.png":::

-2. Click on **View Logs**, under the section ΓÇ£Maximize your Log Analytics experienceΓÇ¥.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/02-view-logs.png" alt-text="Screenshot that shows click on view logs." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/02-view-logs.png":::

-3. You are directed to your log analytics workspace, where the chosen tables are imported into the workspace automatically.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/03-log-analytics-workspace.png" alt-text="Screenshot that shows logs analytics workspace." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/03-log-analytics-workspace.png":::

-1. [Azure Monitor Logs reference - ADFAirflowSchedulerLogs | Microsoft Learn](/azure/azure-monitor/reference/tables/ADFAirflowSchedulerLogs)

-2. [Azure Monitor Logs reference - ADFAirflowTaskLogs | Microsoft Learn](/azure/azure-monitor/reference/tables/adfairflowtasklogs)

-3. [Azure Monitor Logs reference - ADFAirflowWebLogs | Microsoft Learn](/azure/azure-monitor/reference/tables/adfairflowweblogs)

-4. [Azure Monitor Logs reference - ADFAirflowWorkerLogs | Microsoft Learn](/azure/azure-monitor/reference/tables/adfairflowworkerlogs)

-5. [Azure Monitor Logs reference - AirflowDagProcessingLogs | Microsoft Learn](/azure/azure-monitor/reference/tables/AirflowDagProcessingLogs)

-## How to write a query

-1. LetΓÇÖs start with simplest query that returns all the records in the ADFAirflowTaskLogs.

- You can double click on the table name to add it to query window, or you can directly type table name in window.

-2. To narrow down your search results, such as filtering them based on a specific task ID, you can use the following query:

-```kusto

-ADFAirflowTaskLogs

-| where DagId == "<your_dag_id>"

-and TaskId == "<your_task_id>"

-```

-Similarly, you can create custom queries according to your needs using any tables available in LogManagement.

-For more information:

-1. [Log Analytics Tutorial](../azure-monitor/logs/log-analytics-tutorial.md)

-2. [Kusto Query Language (KQL) overview - Azure Data Explorer | Microsoft Learn](/azure/data-explorer/kusto/query/)

-## How to monitor metrics.

-Azure Data Factory offers comprehensive metrics for Airflow Integration Runtimes (IR), allowing you to effectively monitor the performance of your Airflow IR and establish alerting mechanisms as needed.

-1. Open your Azure Data Factory Resource.

-2. In the left navigation pane, Click **Metrics** under Monitoring section.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/metrics-in-data-factory-studio.png" alt-text="Screenshot that shows where metrics tab is located in data factory." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/metrics-in-data-factory-studio.png":::

-3. Select the scope -> Metric Namespace -> Metric you want to monitor.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/monitor-metrics.png" alt-text="Screenshot that shows metrics to select." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/monitor-metrics.png":::

-4. For example, we created the multi-line chart, to visualize the Integration Runtime CPU Percentage and Airflow Integration Runtime Dag Bag Size.

-5. You can set up an alert rule that triggers when specific conditions are met by your metrics.

- Refer to guide: [Overview of Azure Monitor alerts - Azure Monitor | Microsoft Learn](/azure/azure-monitor/alerts/alerts-overview)

-6. Click on Save to Dashboard, once your chart is complete, else your chart disappears.

- :::image type="content" source="media/diagnostics-logs-and-metrics-for-managed-airflow/save-to-dashboard.png" alt-text="Screenshot that shows save to dashboard." lightbox="media/diagnostics-logs-and-metrics-for-managed-airflow/save-to-dashboard.png":::

-## Airflow Metrics

-The following table lists the metrics available for the Managed Airflow.

-Table headings

-Metric - The metric display name as it appears in the Azure portal.

-Name in Rest API - Metric name as referred to in the REST API.

-Unit - Unit of measure.

-Aggregation - The default aggregation type. Valid values: Average, Minimum, Maximum, Total, Count.

-Dimensions - Dimensions available for the metric.

-Time Grains - Intervals at which the metric is sampled. For example, PT1M indicates that the metric is sampled every minute, PT30M every 30 minutes, PT1H every hour, and so on.

-DS Export- Whether the metric is exportable to Azure Monitor Logs via Diagnostic Settings.

-|Metric|Name in REST API|Description|Unit|Aggregation|Dimensions|Time Grains|DS Export|

-|**Airflow Integration Runtime Collect DB Dags** |`AirflowIntegrationRuntimeCollectDBDags` |Milliseconds taken for fetching all Serialized Dags from DB. |Milliseconds |Average |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Memory Usage** |`AirflowIntegrationRuntimeCpuUsage` |Millicores consumed by Airflow Integration Runtime, indicating the CPU resources used in thousandths of a CPU core. |Millicores |Average |`IntegrationRuntimeName`, `ContainerName`|PT1M |Yes|

-|**Airflow Integration Runtime Dag Callback Exceptions** |`AirflowIntegrationRuntimeDagCallbackExceptions` |Number of exceptions raised from DAG callbacks. When this happens, it means DAG callback is not working. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime DAG Processing Last Duration** |`AirflowIntegrationRuntimeDAGProcessingLastDuration` |Seconds taken to load the given DAG file. |Milliseconds |Average |`IntegrationRuntimeName`, `DagFile`|PT1M |No|

-|**Airflow Integration Runtime DAG ProcessingManager Stalls** |`AirflowIntegrationRuntimeDAGProcessingManagerStalls` |Number of stalled DagFileProcessorManager. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime DAG Processing Processes** |`AirflowIntegrationRuntimeDAGProcessingProcesses` |Relative number of currently running DAG parsing processes (ie this delta is negative when, since the last metric was sent, processes have completed). |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime DAG Processing Processor Timeouts** |`AirflowIntegrationRuntimeDAGProcessingProcessorTimeouts` |Number of file processors that have been killed due to taking too long. |Seconds |Average |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime DAG Processing Total Parse Time** |`AirflowIntegrationRuntimeDAGProcessingTotalParseTime` |Seconds taken to scan and import dag_processing.file_path_queue_size DAG files. |Seconds |Average |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime DAG Run Duration Failed** |`AirflowIntegrationRuntimeDAGRunDurationFailed` |Seconds taken for a DagRun to reach failed state. |Milliseconds |Average |`IntegrationRuntimeName`, `DagId`|PT1M |No|

-|**Airflow Integration Runtime DAG Run Duration Success** |`AirflowIntegrationRuntimeDAGRunDurationSuccess` |Seconds taken for a DagRun to reach success state. |Milliseconds |Average |`IntegrationRuntimeName`, `DagId`|PT1M |No|

-|**Airflow Integration Runtime DAG Run First Task Scheduling Delay** |`AirflowIntegrationRuntimeDAGRunFirstTaskSchedulingDelay` |Seconds elapsed between first task start_date and dagrun expected start. |Milliseconds |Average |`IntegrationRuntimeName`, `DagId`|PT1M |No|

-|**Airflow Integration Runtime DAG Run Schedule Delay** |`AirflowIntegrationRuntimeDAGRunScheduleDelay` |Seconds of delay between the scheduled DagRun start date and the actual DagRun start date. |Milliseconds |Average |`IntegrationRuntimeName`, `DagId`|PT1M |No|

-|**Airflow Integration Runtime Executor Open Slots** |`AirflowIntegrationRuntimeExecutorOpenSlots` |Number of open slots on executor. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Executor Queued Tasks** |`AirflowIntegrationRuntimeExecutorQueuedTasks` |Number of queued tasks on executor. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Executor Running Tasks** |`AirflowIntegrationRuntimeExecutorRunningTasks` |Number of running tasks on executor. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Job End** |`AirflowIntegrationRuntimeJobEnd` |Number of ended <job_name> job, ex. SchedulerJob, LocalTaskJob. |Count |Total |`IntegrationRuntimeName`, `Job`|PT1M |No|

-|**Airflow Integration Runtime Heartbeat Failure** |`AirflowIntegrationRuntimeJobHeartbeatFailure` |Number of failed Heartbeats for a <job_name> job, ex. SchedulerJob, LocalTaskJob. |Count |Total |`IntegrationRuntimeName`, `Job`|PT1M |No|

-|**Airflow Integration Runtime Job Start** |`AirflowIntegrationRuntimeJobStart` |Number of started <job_name> job, ex. SchedulerJob, LocalTaskJob. |Count |Total |`IntegrationRuntimeName`, `Job`|PT1M |No|

-|**Airflow Integration Runtime Memory Percentage** |`AirflowIntegrationRuntimeMemoryPercentage` |Memory Percentage used by Airflow Integration Runtime environments. |Percent |Average |`IntegrationRuntimeName`, `ContainerName`|PT1M |Yes|

-|**Airflow Integration Runtime Operator Failures** |`AirflowIntegrationRuntimeOperatorFailures` |Total Operator failures. |Count |Total |`IntegrationRuntimeName`, `Operator`|PT1M |No|

-|**Airflow Integration Runtime Operator Successes** |`AirflowIntegrationRuntimeOperatorSuccesses` |Total Operator successes. |Count |Total |`IntegrationRuntimeName`, `Operator`|PT1M |No|

-|**Airflow Integration Runtime Scheduler Critical Section Duration** |`AirflowIntegrationRuntimeSchedulerCriticalSectionDuration` |Milliseconds spent in the critical section of scheduler loop ΓÇô only a single scheduler can enter this loop at a time. |Milliseconds |Average |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Scheduler Orphaned Tasks Adopted** |`AirflowIntegrationRuntimeSchedulerOrphanedTasksAdopted` |Number of Orphaned tasks adopted by the Scheduler. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Scheduler Orphaned Tasks Cleared** |`AirflowIntegrationRuntimeSchedulerOrphanedTasksCleared` |Number of Orphaned tasks cleared by the Scheduler. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Scheduler Tasks Starving** |`AirflowIntegrationRuntimeSchedulerTasksStarving` |Number of tasks that cannot be scheduled because of no open slot in pool. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Task Instance Created Using Operator** |`AirflowIntegrationRuntimeTaskInstanceCreatedUsingOperator` |Number of tasks instances created for a given Operator. |Count |Total |`IntegrationRuntimeName`, `Operator`|PT1M |No|

-|**Airflow Integration Runtime Task Instance Failures** |`AirflowIntegrationRuntimeTaskInstanceFailures` |Overall task instances failures |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Task Instance Successes** |`AirflowIntegrationRuntimeTaskInstanceSuccesses` |Overall task instances successes. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Task Removed From DAG** |`AirflowIntegrationRuntimeTaskRemovedFromDAG` |Number of tasks removed for a given dag (i.e. task no longer exists in DAG). |Count |Total |`IntegrationRuntimeName`, `DagId`|PT1M |No|

-|**Airflow Integration Runtime Task Restored To DAG** |`AirflowIntegrationRuntimeTaskRestoredToDAG` |Number of tasks restored for a given dag (i.e. task instance which was previously in REMOVED state in the DB is added to DAG file). |Count |Total |`IntegrationRuntimeName`, `DagId`|PT1M |No|

-|**Airflow Integration Runtime Triggers Blocked Main Thread** |`AirflowIntegrationRuntimeTriggersBlockedMainThread` |Number of triggers that blocked the main thread (likely due to not being fully asynchronous). |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Triggers Succeeded** |`AirflowIntegrationRuntimeTriggersSucceeded` |Number of triggers that have fired at least one event. |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-|**Airflow Integration Runtime Zombie Tasks Killed** |`AirflowIntegrationRuntimeZombiesKilled` |Zombie tasks killed |Count |Total |`IntegrationRuntimeName`|PT1M |No|

-For more information: [https://learn.microsoft.com/azure/azure-monitor/reference/supported-metrics/microsoft-datafactory-factories-metrics](/azure/azure-monitor/reference/supported-metrics/microsoft-datafactory-factories-metrics)

-| **Unusual amount of data extracted from a sensitive blob container (Preview)**<br>Storage.Blob_DataExfiltration.AmountOfDataAnomaly.Sensitive | The alert indicates that someone has extracted an unusually large number of blobs from a blob container with sensitive data in the storage account.<br>Applies to: Azure Blob (Standard general-purpose v2, Azure Data Lake Storage Gen2 or premium block blobs) storage accounts with the new Defender for Storage plan with the data sensitivity threat detection feature enabled. | Exfiltration | Medium |

-| **Unusual number of blobs extracted from a sensitive blob container (Preview)**<br>Storage.Blob_DataExfiltration.NumberOfBlobsAnomaly.Sensitive | The alert indicates that someone has extracted an unusually large amount of data from a blob container with sensitive data in the storage account. <br>Applies to: Azure Blob (Standard general-purpose v2, Azure Data Lake Storage Gen2 or premium block blobs) storage accounts with the new Defender for Storage plan with the data sensitivity threat detection feature enabled. | Exfiltration | |

-**You must have the SSM Agent for auto provisioning Arc agent on EC2 machines. If the SSM doesn't exist, or is removed from the EC2, the Arc provisioning wonΓÇÖt be able to proceed.**

-## Azure

-| Domain | Feature | Supported Resources | Linux release state | Windows release state | Agentless/Agent-based | Plans | Azure clouds availability |

-|--|--|--|--|--|--|--|--|

-| Security posture management | [Agentless discovery for Kubernetes](defender-for-containers-introduction.md#security-posture-management) | AKS | GA | GA | Agentless | Defender for Containers **OR** Defender CSPM | Azure commercial clouds |

-| Security posture management | Comprehensive inventory capabilities | ACR, AKS | GA | GA | Agentless| Defender for Containers **OR** Defender CSPM | Azure commercial clouds |

-| Security posture management | Attack path analysis | ACR, AKS | GA | - | Agentless | Defender CSPM | Azure commercial clouds |

-| Security posture management | Enhanced risk-hunting | ACR, AKS | GA | - | Agentless | Defender for Containers **OR** Defender CSPM | Azure commercial clouds |

-| Security posture management | [Control plane hardening](defender-for-containers-architecture.md) | ACR, AKS | GA | Preview | Agentless | Free | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| Security posture management | [Kubernetes data plane hardening](kubernetes-workload-protections.md) |AKS | GA | - | Azure Policy | Free | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| Security posture management | Docker CIS | VM, Virtual Machine Scale Set | GA | - | Log Analytics agent | Defender for Servers Plan 2 | Commercial clouds<br><br> National clouds: Azure Government, Microsoft Azure operated by 21Vianet |

-| [Vulnerability assessment](defender-for-containers-vulnerability-assessment-azure.md) | Agentless registry scan (powered by Qualys) <BR> [Supported OS packages](#registries-and-images-support-for-azurevulnerability-assessment-powered-by-qualys) | ACR, Private ACR | GA | Preview | Agentless | Defender for Containers | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| [Vulnerability assessment](defender-for-containers-vulnerability-assessment-azure.md) | Agentless registry scan (powered by Qualys) <BR> [Supported language packages](#registries-and-images-support-for-azurevulnerability-assessment-powered-by-qualys) | ACR, Private ACR | Preview | - | Agentless | Defender for Containers | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| [Vulnerability assessment](defender-for-containers-vulnerability-assessment-azure.md) | Agentless/agent-based runtime scan(powered by Qualys) [OS packages](#registries-and-images-support-for-azurevulnerability-assessment-powered-by-qualys) | AKS | GA | Preview | Defender agent | Defender for Containers | Commercial clouds |

-| [Vulnerability assessment](agentless-vulnerability-assessment-azure.md) | Agentless registry scan (powered by Microsoft Defender Vulnerability Management) [supported packages](#registries-and-images-support-for-azurevulnerability-assessment-powered-by-microsoft-defender-vulnerability-management)| ACR, Private ACR | GA | Preview | Agentless | Defender for Containers or Defender CSPM | Commercial clouds<br/><br/> National clouds: Azure Government, Azure operated by 21Vianet |

-| [Vulnerability assessment](agentless-vulnerability-assessment-azure.md) | Agentless/agent-based runtime (powered by Microsoft Defender Vulnerability Management) [supported packages](#registries-and-images-support-for-azurevulnerability-assessment-powered-by-microsoft-defender-vulnerability-management)| AKS | GA | Preview | Agentless **OR/AND** Defender agent | Defender for Containers or Defender CSPM | Commercial clouds<br/><br/> National clouds: Azure Government, Azure operated by 21Vianet |

-| Runtime threat protection | [Control plane](defender-for-containers-introduction.md#run-time-protection-for-kubernetes-nodes-and-clusters) | AKS | GA | GA | Agentless | Defender for Containers | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| Runtime threat protection | Workload | AKS | GA | - | Defender agent | Defender for Containers | Commercial clouds |

-| Deployment & monitoring | Discovery of unprotected clusters | AKS | GA | GA | Agentless | Free | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| Deployment & monitoring | Defender agent auto provisioning | AKS | GA | - | Agentless | Defender for Containers | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-| Deployment & monitoring | Azure Policy for Kubernetes auto provisioning | AKS | GA | - | Agentless | Free | Commercial clouds<br><br> National clouds: Azure Government, Azure operated by 21Vianet |

-### Registries and images support for Azure - vulnerability assessment powered by Qualys

-## AWS

-### Outbound proxy support

-## GCP

-### Outbound proxy support

-description: This guide is for IT professionals, security analysts, and cloud admins who need to troubleshoot Microsoft Defender for Cloud related issues.

-# Microsoft Defender for Cloud Troubleshooting Guide

-This guide is for information technology (IT) professionals, information security analysts, and cloud administrators whose organizations need to troubleshoot Defender for Cloud related issues.

-> When you're facing an issue or need advice from our support team, the **Diagnose and solve problems** section of the Azure portal is good place to look for solutions:

-> :::image type="content" source="media/release-notes/solve-problems.png" alt-text="Defender for Cloud's 'Diagnose and solve problems' page":::

-## Use the Audit Log to investigate issues

-The first place to look for troubleshooting information is the [Audit Log records](../azure-monitor/essentials/platform-logs-overview.md) records for the failed component. In the audit logs, you can see details including:

-The audit log contains all write operations (PUT, POST, DELETE) performed on your resources, but not read operations (GET).

-## Troubleshooting the native multicloud connector

-Defender for Cloud uses connectors to collect monitoring data from AWS accounts and GCP projects. If youΓÇÖre experiencing issues with the connector or you don't see data from AWS or GCP, we recommend that you review these troubleshooting tips:

-Common connector issues:

-AWS connector issues:

-Defender API calls to AWS:

-Cost impact: When you onboard your AWS single or management account, our Discovery service initiates an immediate scan of your environment by executing API calls to various service endpoints in order to retrieve all resources that we secure.

-Following this initial scan, the service will continue to periodically scan your environment at the interval that you configured during onboarding. It's important to note that in AWS, each API call to the account generates a lookup event that is recorded in the CloudTrail resource.

-The CloudTrail resource incurs costs, and the pricing details can be found in [AWS CloudTrail Pricing](https://aws.amazon.com/cloudtrail/pricing/).

-Furthermore, if you have connected your CloudTrail to GuardDuty, you're also responsible for associated costs, which can be found in the [GuardDuty documentation](https://docs.aws.amazon.com/guardduty/latest/ug/monitoring_costs.html).

-**Getting the number of native API calls executed by Defender for Cloud**:

-There are two ways to get the number of calls made by Defender for Cloud and both rely on querying AWS CloudTrail logs:

-1. Use an existing or create a new *Athena table*. For more information, see [Querying AWS CloudTrail logs](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html).

-1. Navigate to the above Athena table and use one of the below predefined queries per your needs.

-1. Use an existing or create a new *Event Data Store*. For more information, see [Working with AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).

-1. Navigate to the above lake and use one of the below predefined queries per your needs.

- Sample Queries:

- - List the number of overall API calls by Defender for Cloud:

- ```sql

- SELECT COUNT(*) AS overallApiCallsCount FROM <TABLE-NAME>

- WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

- AND eventTime > TIMESTAMP '<DATETIME>'

- ```

- - List the number of overall API calls by Defender for Cloud aggregated by day:

- ```sql

- SELECT DATE(eventTime) AS apiCallsDate, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME>

- WHERE userIdentity.arn LIKE 'arn:aws:sts:: <YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

- AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY DATE(eventTime)

- ```

- - List the number of overall API calls by Defender for Cloud aggregated by event name:

- ```sql

- SELECT eventName, COUNT(*) AS apiCallsCountByEventName FROM <TABLE-NAME>

- WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

- AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY eventName

- ```

- - List the number of overall API calls by Defender for Cloud aggregated by region:

- ```sql

- SELECT awsRegion, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME>

- WHERE userIdentity.arn LIKE 'arn:aws:sts::120589537074:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>'

- AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY awsRegion

- ```

- - The TABLE-NAME is Athena table or Event data store ID

-GCP connector issues:

-Defender API calls to GCP:

-When you onboard your GCP single project or organization, our Discovery service initiates an immediate scan of your environment by executing API calls to various service endpoints in order to retrieve all resources that we secure.

-Following this initial scan, the service will continue to periodically scan your environment at the interval that you configured during onboarding.

-**Getting the number of native API calls executed by Defender for Cloud**:

- 1. Go to **Logging** -> **Log Explorer**

- 1. Filter the dates as you wish (for example, 1d)

- 1. To show API calls executed by Defender for Cloud, run this query:

- ```json

- protoPayload.authenticationInfo.principalEmail : "microsoft-defender"

- ```

-## Troubleshooting the Log Analytics agent

-Alert types:

-Depending on the alert types, customers can gather the necessary information to investigate the alert by using the following resources:

-Customers can share feedback for the alert description and relevance. Navigate to the alert itself, select the **Was This Useful** button, select the reason, and then enter a comment to explain the feedback. We consistently monitor this feedback channel to improve our alerts.

-Just like the Azure Monitor, Defender for Cloud uses the Log Analytics agent to collect security data from your Azure virtual machines. After data collection is enabled and the agent is correctly installed in the target machine, the `HealthService.exe` process should be running.

-Open the services management console (services.msc), to make sure that the Log Analytics agent service running as shown:

-To see which version of the agent you have, open **Task Manager**, in the **Processes** tab locate the **Log Analytics agent Service**, right-click on it and select **Properties**. In the **Details** tab, look the file version as shown:

-### Log Analytics agent installation scenarios

-There are two installation scenarios that can produce different results when installing the Log Analytics agent on your computer. The supported scenarios are:

-> [!NOTE]

-> To avoid the behavior explained in the second scenario, make sure you download the latest version of the agent.

-### Monitoring agent network connectivity issues

-For agents to connect to and register with Defender for Cloud, they must have access to the DNS addresses and network ports for Azure network resources.

-| Agent Resource | Ports | Bypass HTTPS inspection |

-| *.ods.opinsights.azure.com | 443 | Yes |

-| *.oms.opinsights.azure.com | 443 | Yes |

-| *.blob.core.windows.net | 443 | Yes |

-| *.azure-automation.net | 443 | Yes |

-If you're having trouble onboarding the Log Analytics agent, make sure to read [how to troubleshoot Operations Management Suite onboarding issues](https://support.microsoft.com/help/3126513/how-to-troubleshoot-operations-management-suite-onboarding-issues).

-## Antimalware protection isn't working properly

-The guest agent is the parent process of everything the [Microsoft Antimalware](../security/fundamentals/antimalware.md) extension does. When the guest agent process fails, the Microsoft Antimalware protection that runs as a child process of the guest agent might also fail.

-Here are some other troubleshooting tips:

-By default the Microsoft Antimalware user interface is disabled, but you can [enable the Microsoft Antimalware user interface](/archive/blogs/azuresecurity/enabling-microsoft-antimalware-user-interface-post-deployment) on Azure Resource Manager VMs.

-## Troubleshooting problems loading the dashboard

-If you experience issues loading the workload protection dashboard, make sure that the user that first enabled Defender for Cloud on the subscription and the user that want to turn on data collection have the *Owner* or *Contributor* role on the subscription. If that is the case, users with the *Reader* role on the subscription can see the dashboard, alerts, recommendations, and policy.

-## Troubleshoot Azure DevOps Organization connector issues

-If you are not able to onboard your Azure DevOps organization, follow the following troubleshooting tips:

- 1. On your profile page, select the drop-down menu to select another account.

- :::image type="content" source="./media/troubleshooting-guide/authorize-select-tenant.png" alt-text="Screenshot of the Azure DevOps profile page that is used to select an account.":::

- 1. After selecting the correct account/tenant combination, navigate to **Environment settings** in Defender for Cloud and edit your Azure DevOps connector. You will have the option to Re-authorize the connector, which will update the connector with the correct account/tenant combination. You should then see the correct list of organizations from the drop-down selection menu.

-## Contacting Microsoft Support

-You can also find troubleshooting information for Defender for Cloud at the [Defender for Cloud Q&A page](/answers/topics/azure-security-center.html). If you need further troubleshooting, you can open a new support request using **Azure portal** as shown:

-## See also

-In this page, you learned about troubleshooting steps for Defender for Cloud. To learn more about Microsoft Defender for Cloud:

-| Endpoint protection discovery recommendations | The current [GA recommendations](endpoint-protection-recommendations-technical.md) to install endpoint protection and fix health issues in the detected solutions will be deprecated in August 2024. The preview recommendations available today over Azure Monitor agent (AMA) will be deprecated when the alternative is provided over Agentless Disk Scanning capability. | A new agentless version will be provided for discovery and configuration gaps by April 2024. As part of this upgrade, this feature will be provided as a component of Defender for Servers plan 2 and Defender CSPM, and wonΓÇÖt cover on-premises or Arc-connected machines. |

-1. Sign into your OT sensor via SFTP and create a directory for your backup files. Run:

- add - //<server_IP>/<folder_path> /<backup_folder_name_on_cyberx_server> cifsrw,credentials=/etc/samba/user,vers=X.X,uid=cyberx,gid=cyberx,file_mode=0777,dir_mode=0777 0 0

- sudo nano /var/cyberx/properties/backup.properties`

- Set the `backup_directory_path` to the folder on your OT sensor where you want to save your backup files.

- > - Make sure that the backup file you select uses the same OT sensor software version that's currently installed on your OT sensor.

- > - Your backup file must be one that had been generated automatically or manually via the CLI. If you're using a backup file generated manually by the GUI, you'll need to contact support to use it to restore your sensor.

-

-For more information, see [Maintain OT network sensors from the GUI](how-to-manage-individual-sensors.md).

-In Azure DNS, compute resources such as virtual machines, virtual machine scale sets, and Service Fabric clusters have Public IP addresses. Reverse DNS lookups are configured using the 'ReverseFqdn' property of the Public IP address.

-A third party shouldn't have access to create reverse DNS records for Azure service mapping to your DNS domains. That's why Azure only allows you to create a reverse DNS record if the domain name is the same or resolves to a Public IP address in the same subscription. This restriction also applies to Cloud Service.

-This validation is only done when the reverse DNS record is set or modified. Periodic revalidation isn't done.

-For example, suppose the Public IP address resource has the DNS name `contosoapp1.northus.cloudapp.azure.com` and IP address `23.96.52.53`. The reverse FQDN for the Public IP address can be specified as:

-* The DNS name for the Public IP address: `contosoapp1.northus.cloudapp.azure.com`.

-* A vanity DNS name, such as: `app1.contoso.com`. As long as the name is *first* configured as a CNAME pointing to `contosoapp1.northus.cloudapp.azure.com`. The name can also be pointed to a different Public IP address in the same subscription.

-## Reverse DNS for Public IP address resources

-This section provides detailed instructions for how to configure reverse DNS for Public IP address resources in the Resource Manager deployment model. You can use either Azure PowerShell, Azure classic CLI, or Azure CLI to accomplish this task. Configuring reverse DNS for a Public IP address resource is currently not supported in the Azure portal.

-Azure currently supports reverse DNS only for Public IPv4 address resources.

-### Add reverse DNS to an existing PublicIpAddresses

-To update reverse DNS to an existing PublicIpAddress:

-To add reverse DNS to an existing PublicIpAddress that doesn't already have a DNS name, you must also specify a DNS name:

-To add reverse DNS to an existing PublicIpAddress:

-To add reverse DNS to an existing PublicIpAddress that doesn't already have a DNS name, you must also specify a DNS name:

-To add reverse DNS to an existing PublicIpAddress:

-To add reverse DNS to an existing PublicIpAddress that doesn't already have a DNS name, you must also specify a DNS name:

-### Create a Public IP Address with reverse DNS

-### View reverse DNS for an existing PublicIpAddress

-To view the configured value for an existing PublicIpAddress:

-### Remove reverse DNS from existing Public IP Addresses

-### Will my reverse DNS records resolve from the internet?

-### What happens if the validation check for the reverse DNS I've specified fails?

-Where the reverse DNS validation check fails, the operation to configure the reverse DNS record fails. Correct the reverse DNS value as required, and retry.

-Create a resource group with the [az group create](/cli/azure/group#az-group-create) command. The following example creates a resource group named *gridResourceGroup* in the *westus2* location. If you click **Try it**, you'll see the Azure Cloud Shell window in the right pane. Then, click **Copy** to copy the command and paste it in the Azure Cloud Shell window, and press ENTER to run the command. Change the name of the resource group and the location if you like.

-An Event Grid topic provides a user-defined endpoint that you post your events to. The following example creates the custom topic in your resource group using Bash in Azure Cloud Shell. Replace `<your-topic-name>` with a unique name for your topic. The custom topic name must be unique because it's part of the DNS entry. Additionally, it must be between 3-50 characters and contain only values a-z, A-Z, 0-9, and "-"

-Before subscribing to the custom topic, let's create the endpoint for the event message. Typically, the endpoint takes actions based on the event data. To simplify this quickstart, you deploy a [pre-built web app](https://github.com/Azure-Samples/azure-event-grid-viewer) that displays the event messages. The deployed solution includes an App Service plan, an App Service web app, and source code from GitHub.

-The deployment may take a few minutes to complete. After the deployment has succeeded, view your web app to make sure it's running. In a web browser, navigate to:

-```azurecli-interactive

-endpoint=https://$sitename.azurewebsites.net/api/updates

-az eventgrid event-subscription create \

- --source-resource-id "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.EventGrid/topics/$topicname" \

- --name demoViewerSub \

- --endpoint $endpoint

-

-```

-View your web app again, and notice that a subscription validation event has been sent to it. Select the eye icon to expand the event data. Event Grid sends the validation event so the endpoint can verify that it wants to receive event data. The web app includes code to validate the subscription.

-

-1. Flush memstore data.

- HBase writes incoming data to an in-memory store called a *memstore*. After the memstore reaches a certain size, HBase flushes it to disk for long-term storage in the cluster's storage account. Deleting the source cluster after an upgrade also deletes any data in the memstores. To retain the data, manually flush each table's memstore to disk before upgrading.

- You can flush the memstore data by running the [flush_all_tables.sh](https://github.com/Azure/hbase-utils/blob/master/scripts/flush_all_tables.sh) script from the [hbase-utils GitHub repository](https://github.com/Azure/hbase-utils/).

- You can also flush the memstore data by running the following HBase shell command from inside the HDInsight cluster:

- 1. From you ssh session, use the HDFS command to copy the file from your head node local storage to Azure Storage.

- The path to the data in HDFS is built dynamically according to the expression provided in the `uri-template` element. In this coordinator, a frequency of one day is also used with the dataset. While the start and end dates on the coordinator element control when the actions are scheduled (and defines their nominal times), the `initial-instance` and `frequency` on the dataset control the calculation of the date that is used in constructing the `uri-template`. In this case, set the initial instance to one day before the start of the coordinator to ensure that it picks up the first day's (1/1/2017) worth of data. The dataset's date calculation rolls forward from the value of `initial-instance` (12/31/2016) advancing in increments of dataset frequency (one day) until it finds the most recent date that doesn't pass the nominal time set by the coordinator (2017-01-01T00:00:00 GMT for the first action).

-* Point 3: When Oozie finds that file, it schedules an instance of the workflow that will process the data for 2017-01-01. Oozie then continues processing for 2017-01-02. This evaluation repeats up to but not including 2017-01-05.

-6. Select a coordinator instance to display the list of scheduled actions. In this case, you should see four actions with nominal times in the range from 1/1/2017 to 1/4/2017.

-To view data in Azure Data Explorer as soon as the pipeline sends it, you can set the ingestion batching policy `Count` to 1. To edit the ingestion batching policy, run the following command in your database query tab:

-```kusto

-.alter table <DatabaseName>.<TableName> policy ingestionbatching

-An Azure Arc-enabled Kubernetes cluster is a prerequisite for deploying Azure IoT Operations Preview. This article describes how to prepare an Azure Arc-enabled Kubernetes cluster before you deploy Azure IoT Operations. This article includes guidance for both Ubuntu, Windows, and cloud environments.

-* In this quickstart, you use the `AksEdgeQuickStartForAio.ps1` script to set up an AKS Edge Essentials single-machine K3S Linux-only cluster. To learn more, see the [AKS Edge Essentials system requirements](/azure/aks/hybrid/aks-edge-system-requirements). For this quickstart, ensure that your machine has a minimum of 10 GB RAM, 4 vCPUs, and 40 GB free disk space.

-There are 2 ways to execute a full backup. You must provide the following information to execute a full backup:

-> [!NOTE]

-> Backing up and restoring using storage container SAS token requires your storage account to have public network access enabled. You can backup and restore your MHSM using a user assigned managed identity regardless of whether your storage account has public network access or private network access enabled, including if the storage account is behind a private endpoint.

-description: Learn how to configure a Virtual Machine Scale Set with an existing Azure Load Balancer using the Azure CLI.

-# Configure a Virtual Machine Scale Set with an existing Azure Load Balancer using the Azure CLI

-In this article, you'll learn how to configure a Virtual Machine Scale Set with an existing Azure Load Balancer.

-## Prerequisites

-

-## Deploy a Virtual Machine Scale Set with existing load balancer

-Deploy a Virtual Machine Scale Set with [`az vmss create`](/cli/azure/vmss#az-vmss-create).

-Replace the values in brackets with the names of the resources in your configuration.

-```azurecli-interactive

-az vmss create \

- --resource-group <resource-group> \

- --name <vmss-name>\

- --image <your-image> \

- --admin-username <admin-username> \

- --generate-ssh-keys \

- --upgrade-policy-mode Automatic \

- --instance-count 3 \

- --vnet-name <virtual-network-name> \

- --subnet <subnet-name> \

- --lb <load-balancer-name> \

- --backend-pool-name <backend-pool-name>

-```

-The below example deploys a Virtual Machine Scale Set with:

-```azurecli-interactive

-az vmss create \

- --resource-group myResourceGroup \

- --name myVMSS \

- --image Canonical:UbuntuServer:18.04-LTS:latest \

- --admin-username adminuser \

- --generate-ssh-keys \

- --upgrade-policy-mode Automatic \

- --instance-count 3 \

- --vnet-name myVnet\

- --subnet mySubnet \

- --lb myLoadBalancer \

- --backend-pool-name myBackendPool

-```

-> [!NOTE]

-> After the scale set has been created, the backend port cannot be modified for a load balancing rule used by a health probe of the load balancer. To change the port, you can remove the health probe by updating the Azure virtual machine scale set, update the port and then configure the health probe again.

-## Next steps

-In this article, you deployed a Virtual Machine Scale Set with an existing Azure Load Balancer. To learn more about Virtual Machine Scale Sets and load balancer, see:

-

-description: Learn how to configure a Virtual Machine Scale Set with an existing Azure Load Balancer using the Azure portal.

-# Configure a Virtual Machine Scale Set with an existing Azure Load Balancer using the Azure portal

-In this article, you'll learn how to configure a Virtual Machine Scale Set with an existing Azure Load Balancer.

-description: Learn how to configure a Virtual Machine Scale Set with an existing Azure Load Balancer using Azure PowerShell.

-# Configure a Virtual Machine Scale Set with an existing Azure Load Balancer using Azure PowerShell

-In this article, you'll learn how to configure a Virtual Machine Scale Set with an existing Azure Load Balancer.

-## Prerequisites

-## Sign in to Azure CLI

-Sign into Azure with [`Connect-AzAccount`](/powershell/module/az.accounts/connect-azaccount#example-1-connect-to-an-azure-account)

-```azurepowershell-interactive

-Connect-AzAccount

-```

-## Deploy a Virtual Machine Scale Set with existing load balancer

-Deploy a Virtual Machine Scale Set with [`New-AzVMss`](/powershell/module/az.compute/new-azvmss). Replace the values in brackets with the names of the resources in your configuration.

-```azurepowershell-interactive

-$rsg = <resource-group>

-$loc = <location>

-$vms = <vm-scale-set-name>

-$vnt = <virtual-network>

-$sub = <subnet-name>

-$lbn = <load-balancer-name>

-$pol = <upgrade-policy-mode>

-$img = <image-name>

-$bep = <backend-pool-name>

-$lb = Get-AzLoadBalancer -ResourceGroupName $rsg -Name $lbn

-New-AzVmss -ResourceGroupName $rsg -Location $loc -VMScaleSetName $vms -VirtualNetworkName $vnt -SubnetName $sub -LoadBalancerName $lb -UpgradePolicyMode $pol

-```

-The below example deploys a Virtual Machine Scale Set with the following values:

-```azurepowershell-interactive

-$rsg = "myResourceGroup"

-$loc = "East US 2"

-$vms = "myVMSS"

-$vnt = "myVnet"

-$sub = "mySubnet"

-$pol = "Automatic"

-$lbn = "myLoadBalancer"

-$bep = "myBackendPool"

-$lb = Get-AzLoadBalancer -ResourceGroupName $rsg -Name $lbn

-New-AzVmss -ResourceGroupName $rsg -Location $loc -VMScaleSetName $vms -VirtualNetworkName $vnt -SubnetName $sub -LoadBalancerName $lb -UpgradePolicyMode $pol -BackendPoolName $bep

-```

-> [!NOTE]

-> After the scale set has been created, the backend port cannot be modified for a load balancing rule used by a health probe of the load balancer. To change the port, you can remove the health probe by updating the Azure virtual machine scale set, update the port and then configure the health probe again.

-## Next steps

-In this article, you deployed a Virtual Machine Scale Set with an existing Azure Load Balancer. To learn more about Virtual Machine Scale Sets and load balancer, see:

-1. Under **POLICY RULE**, the JSON edit box is pre-populated with a policy definition template. Replace this template with your [policy definition](../governance/policy/concepts/definition-structure.md) based on the properties described in the table below and by following this syntax:

-1. Under **POLICY RULE**, the JSON edit box is pre-populated with a policy definition template. Replace this template with your [policy definition](../governance/policy/concepts/definition-structure.md) based on the properties described in the table below and by following this syntax:

-For more information, see [Quickstart: Create a policy assignment to identify non-compliant resources](../governance/policy/assign-policy-portal.md).

-description: Call logic apps from Microsoft Power Automate flows by exporting logic apps as connectors.

-# Call logic apps from Power Automate and Power Apps

-To call your logic apps from Microsoft Power Automate and Microsoft Power Apps, you can export your logic apps as connectors. When you expose a logic app as a custom connector in a Power Automate or Power Apps environment, you can then call your logic app from flows there.

-If you want to migrate your flow from Power Automate or Power to Logic Apps instead, see [Export flows from Power Automate and deploy to Azure Logic Apps](export-from-microsoft-flow-logic-app-template.md).

-> [!NOTE]

-> Not all Power Automate connectors are available in Azure Logic Apps. You can migrate only Power Automate flows

-> that have the equivalent connectors in Azure Logic Apps. For example, the Button trigger, the Approval connector,

-> and Notification connector are specific to Power Automate. Currently, OpenAPI-based flows in Power Automate aren't

-> supported for export and deployment as logic app templates.

->

-> * To find which Power Automate connectors don't have Logic Apps equivalents, see

-> [Power Automate connectors](/connectors/connector-reference/connector-reference-powerautomate-connectors).

->

-> * To find which Logic Apps connectors don't have Power Automate equivalents, see

-> [Logic Apps connectors](/connectors/connector-reference/connector-reference-logicapps-connectors).

-## Prerequisites

-* An Azure account and subscription. If you don't have an Azure subscription, [sign up for a free Azure account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* A Power Automate or Power Apps license.

-* A Consumption logic app workflow with a request trigger to export.

- > [!NOTE]

- >

- > The Export capability is available only for Consumption logic app workflows in multi-tenant Azure Logic Apps.

-* A flow in Power Automate or Power Apps from which you want to call your logic app.

-## Export your logic app as a custom connector

-Before you can call your logic app from Power Automate or Power Apps, you must first export your logic app as a custom connector.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the Azure portal search box, enter `Logic Apps`. In the results, under **Services**, select **Logic Apps**.

-1. Select the logic app that you want to export.

-1. From your logic app's menu, select **Export**.

- :::image type="content" source="./media/call-logic-apps-from-power-automate-power-apps/export-logic-app.png" alt-text="Screenshot of logic app's page in Azure portal, showing menu with 'Export' button selected.":::

-1. On the **Export** pane, for **Name**, enter a name for the custom connector to your logic app. From the **Environment** list, select the Power Automate or Power Apps environment from which you want to call your logic app. When you're done, select **OK**.

- :::image type="content" source="./media/call-logic-apps-from-power-automate-power-apps/export-logic-app2.png" alt-text="Screenshot of export pane for logic app, showing required fields for custom connector name and environment.":::

-1. To confirm that your logic app was successfully exported, check the notifications pane.

-### Exporting errors

-Here are errors that might happen when you export your logic app as a custom connector and their suggested solutions:

-* **Failed to get environments. Make sure your account is configured for Power Automate, then try again.**: Check that your Azure account has a Power Automate plan.

-* **The current Logic App cannot be exported. To export, select a Logic App that has a request trigger.**: Check that your logic app begins with a [request trigger](./logic-apps-workflow-actions-triggers.md#request-trigger).

-## Connect to your logic app from Power Automate

-To connect to the logic app that you exported with your Power Automate flow:

-1. Sign in to [Power Automate](https://make.powerautomate.com).

-1. From the **Power Automate** home page menu, select **My flows**.

-1. On the **Flows** page, select the flow that you want to connect to your logic app.

-1. From your flow page's menu, select **Edit**.

-1. In the flow editor, select **&#43; New step**.

-1. Under **Choose an action**, in the search box, enter the name of your logic app connector. Optionally, to show only the custom connectors in your environment, filter the results by selecting the **Custom** tab.

- :::image type="content" source="./media/call-logic-apps-from-power-automate-power-apps/power-automate-custom-connector-action.png" alt-text="Screenshot of Power Automate flow editor, showing a new step being added for the custom connector and available actions.":::

-1. Select the action that you want to take with your logic app connector.

-1. Provide the information that the action passes to the logic app connector.

-1. To save your changes, from the Power Automate editor menu, select **Save**.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the Logic Apps service, find the logic app that you exported.

-1. Confirm that your logic app works the way that you expect in your Power Automate flow.

-## Delete logic app connector from Power Automate

-1. Sign in to [Power Automate](https://make.powerautomate.com).

-1. On the **Power Automate** home page, select **Data** &gt; **Custom connectors** in the menu.

-1. In the list, find your custom connector, and select the ellipses (**...**) button &gt; **Delete**.

- :::image type="content" source="./media/call-logic-apps-from-power-automate-power-apps/delete-custom-connector.png" alt-text="Screenshot of Power Automate 'Custom connectors' page, showing logic app's custom connector management buttons.":::

-1. To confirm the deletion, select **OK**.

-## Connect to your logic app from Power Apps

-To connect to the logic app that you exported with your Power Apps flow:

-1. Sign in to [Power Apps](https://powerapps.microsoft.com/).

-1. On the **Power Apps** home page, select **Flows** in the menu.

-1. On the **Flows** page, select the flow that you want to connect to your logic app.

-1. On your flow's page, select **Edit** in the flow's menu.

-1. In the flow editor, select the **&#43; New step** button.

-1. Under **Choose an action** in the new step, enter the name of your logic app connector in the search box. Optionally, filter the results by the **Custom** tab to see only custom connectors in your environment.

- :::image type="content" source="./media/call-logic-apps-from-power-automate-power-apps/power-apps-custom-connector-action.png" alt-text="Screenshot of Power Apps flow editor, showing a new step being added for the custom connector and available actions.":::

-1. Select the action that you want to take with the connector.

-1. Configure what information your action passes to the logic app connector.

-1. In the Power Apps editor menu, select **Save** to save your changes.

-1. Sign in to the [Azure portal](https://portal.azure.com).

-1. In the Logic Apps service, find the logic app that you exported.

-1. Confirm that your logic app is functioning as intended with your Power Apps flow.

-## Delete logic app connector from Power Apps

-1. Sign in to [Power Apps](https://powerapps.microsoft.com).

-1. On the **Power Apps** home page, select **Data** &gt; **Custom Connectors** in the menu.

-1. In the list, find your custom connector, and select the ellipses (**...**) button &gt; **Delete**.

- :::image type="content" source="./media/call-logic-apps-from-power-automate-power-apps/delete-custom-connector.png" alt-text="Screenshot of Power Apps 'Custom connectors' page, showing logic app's custom connector management buttons.":::

-1. To confirm the deletion, select **OK**.

-## Next steps

-* [Managed connectors for Azure Logic Apps](/connectors/connector-reference/connector-reference-logicapps-connectors)

-* [Built-in connectors for Azure Logic Apps](../connectors/built-in.md)

-Azure Logic Apps uses [Azure Storage](../storage/index.yml) for any storage operations. In traditional *multi-tenant* Azure Logic Apps, any storage usage and costs are attached to the logic app. Now, in *single-tenant* Azure Logic Apps, you can use your own storage account. These storage costs are listed separately in your Azure billing invoice. This capability gives you more flexibility and control over your logic app data.

-> This article applies to workflows in the single-tenant Azure Logic Apps environment. These workflows exist in the same logic app and in a single tenant that share the same storage. For more information, see [Single-tenant versus multi-tenant and integration service environment](single-tenant-overview-compare.md).

-Some scenarios might require that you create a workflow that you can call through a URL or that can receive and inbound requests from other services or workflows. For this task, you can natively expose a synchronous HTTPS endpoint for your workflow by using any of the following request-based trigger types:

-* Managed connector triggers that have the [ApiConnectionWebhook type](../logic-apps/logic-apps-workflow-actions-triggers.md#apiconnectionwebhook-trigger) and can receive inbound HTTPS requests

-This how-to guide shows how to create a callable endpoint for your workflow by using the Request trigger and call that endpoint from another workflow. All principles identically apply to the other request-based trigger types that can receive inbound requests.

-For information about security, authorization, and encryption for inbound calls to your workflow, such as [Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security), previously known as Secure Sockets Layer (SSL), [OAuth with Microsoft Entra ID](../active-directory/develop/index.yml), exposing your logic app with Azure API Management, or restricting the IP addresses that originate inbound calls, see [Secure access and data - Access for inbound calls to request-based triggers](logic-apps-securing-a-logic-app.md#secure-inbound-requests).

-* The logic app workflow where you want to use the trigger to create the callable endpoint. You can start with either a blank workflow or an existing logic app workflow where you can replace the current trigger. This example starts with a blank workflow. If you're new to logic apps, see [What is Azure Logic Apps](../logic-apps/logic-apps-overview.md) and [Create an example Consumption logic app workflow in multi-tenant Azure Logic Apps](../logic-apps/quickstart-create-example-consumption-workflow.md).

-1. In the [Azure portal](https://portal.azure.com), create a logic app resource and blank workflow in the designer.

-1. [Follow these general steps to add the **Request** trigger named **When a HTTP request is received**](create-workflow-with-trigger-or-action.md?tabs=consumption#add-trigger).

- For this example, enter this schema:

- {

- 

- 

- * Copy the callback URL from your logic app's **Overview** pane.

- 1. On your logic app's menu, select **Overview**.

- 1. On the **Overview** pane, select **Trigger history**. Under **Callback url [POST]**, copy the URL:

- 

-1. In the Request trigger, open the **Add new parameter** list, and select **Method**, which adds this property to the trigger.

- 

- 

-### Accept values through GET parameters

-1. In the designer, [follow these general steps to add the action where you want to use the parameter value](../logic-apps/create-workflow-with-trigger-or-action.md?tabs=consumption#add-action). For this example, select the action named **Response**.

- 1. Select inside the Response action's **Body** property so that the dynamic content list appears, and select **Expression**.

- 1. In the **Expression** box, enter this expression, replacing `parameter-name` with your parameter name, and select **OK**.

- 

- 

- 

- 

-1. To test your callable endpoint, copy the callback URL from the Request trigger, and paste the URL into another browser window. In the URL, add the parameter name and value following the question mark (`?`) to the URL in the following format, and press Enter.

- `...?{parameter-name=parameter-value}&api-version=2016-10-01...`

- 

-### Accept values through a relative path

-1. In the Request trigger, open the **Add new parameter** list, and select **Relative path**, which adds this property to the trigger.

- 

- 

-1. Under the Request trigger, add the action where you want to use the parameter value. For this example, add the **Response** action.

- 1. Under the Request trigger, select **New step** > **Add an action**.

- 1. Under **Choose an action**, in the search box, enter `response` as your filter. From the actions list, select the **Response** action.

- 1. In the dynamic content list, from the **When a HTTP request is received** section, select the **postalCode** token.

- 

- 

- 

-After you create the endpoint, you can trigger the workflow by sending an HTTPS request to the endpoint's full URL. Logic app workflows have built-in support for direct-access endpoints.

-For example, if you add more properties, such as `"suite"`, to your JSON schema, tokens for those properties are available for you to use in the later steps for your workflow. Here is the complete JSON schema:

- {

-## Create nested workflows

-You can nest a workflow inside the current workflow by adding calls to other workflows that can receive requests. To call these workflows, follow these steps:

-1. In the designer, [follow these general steps to add the action named **Choose a Logic Apps workflow**](../logic-apps/create-workflow-with-trigger-or-action.md?tabs=consumption#add-action).

- The designer shows the eligible workflows for you to select.

-1. Select the workflow to call from your current workflow.

- 

-## Reference content from an incoming request

-For example, if you're passing content that has `application/xml` type, you can use the [`@xpath()` expression](../logic-apps/workflow-definition-language-functions-reference.md#xpath) to perform an XPath extraction, or use the [`@json()` expression](../logic-apps/workflow-definition-language-functions-reference.md#json) for converting XML to JSON. Learn more about working with supported [content types](../logic-apps/logic-apps-content-type.md).

-To get the output from an incoming request, you can use the [`@triggerOutputs` expression](../logic-apps/workflow-definition-language-functions-reference.md#triggerOutputs). For example, suppose you have output that looks like this example:

-To access specifically the `body` property, you can use the [`@triggerBody()` expression](../logic-apps/workflow-definition-language-functions-reference.md#triggerBody) as a shortcut.

-For the original caller to successfully get the response, all the required steps for the response must finish within the [request timeout limit](./logic-apps-limits-and-config.md) unless the triggered workflow is called as a nested workflow. If no response is returned within this limit, the incoming request times out and receives the **408 Client timeout** response.

-In the response body, you can include multiple headers and any type of content. For example, this response's header specifies that the response's content type is `application/json` and that the body contains values for the `town` and `postalCode` properties, based on the JSON schema described earlier in this topic for the Request trigger.

-

-| **Status Code** | `statusCode` | The HTTPS status code to use in the response for the incoming request. This code can be any valid status code that starts with 2xx, 4xx, or 5xx. However, 3xx status codes are not permitted. |

-To view the JSON definition for the Response action and your workflow's complete JSON definition, on the designer toolbar, select **Code view**.

-#### Q: What about URL security?

-**A**: Azure securely generates logic app callback URLs by using [Shared Access Signature (SAS)](/rest/api/storageservices/delegate-access-with-shared-access-signature). This signature passes through as a query parameter and must be validated before your workflow can run. Azure generates the signature using a unique combination of a secret key per logic app, the trigger name, and the operation that's performed. So unless someone has access to the secret logic app key, they cannot generate a valid signature.

-For more information about security, authorization, and encryption for inbound calls to your workflow, such as [Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security), previously known as Secure Sockets Layer (SSL), [Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)](../active-directory/develop/index.yml), exposing your logic app workflow with Azure API Management, or restricting the IP addresses that originate inbound calls, see [Secure access and data - Access for inbound calls to request-based triggers](../logic-apps/logic-apps-securing-a-logic-app.md#secure-inbound-requests).

-* [Secure access and data in Azure Logic Apps - Access for inbound calls to request-based triggers](../logic-apps/logic-apps-securing-a-logic-app.md#secure-inbound-requests)

-description: Learn about how Azure Machine Learning uses MLflow to log metrics and artifacts from machine learning models, and to deploy your machine learning models to an endpoint.

-[MLflow](https://www.mlflow.org) is an open-source framework that's designed to manage the complete machine learning lifecycle. Its ability to train and serve models on different platforms allows you to use a consistent set of tools regardless of where your experiments are running: locally on your computer, on a remote compute target, on a virtual machine, or on an Azure Machine Learning compute instance.

-Azure Machine Learning **workspaces are MLflow-compatible**, which means you can use Azure Machine Learning workspaces in the same way that you'd use an MLflow server. Such compatibility has the following advantages:

-* We don't host MLflow server instances under the hood. The workspace can talk the MLflow API language.

-> Unlike the Azure Machine Learning SDK v1, there's no logging functionality in the SDK v2 and we recommend using MLflow for logging. Such strategy allows your training routines to become cloud-agnostic and portable, removing any dependency in your code with Azure Machine Learning.

-Azure Machine Learning uses MLflow Tracking for metric logging and artifact storage for your experiments. When connected to Azure Machine Learning, all tracking performed using MLflow is materialized in the workspace you are working on. To learn more about how to instrument your experiments for tracking experiments and training routines, see [Log metrics, parameters, and files with MLflow](how-to-log-view-metrics.md). You can also use MLflow to [Query & compare experiments and runs with MLflow](how-to-track-experiments-mlflow.md).

-### Centralize tracking

-You can connect MLflow to Azure Machine Learning workspaces even when you are running locally or in a different cloud. The workspace provides a centralized, secure, and scalable location to store training metrics and models.

-Capabilities include:

-* [Track machine learning experiments and models running locally or in the cloud](how-to-use-mlflow-cli-runs.md) with MLflow in Azure Machine Learning.

-* [Track Azure Databricks machine learning experiments](how-to-use-mlflow-azure-databricks.md) with MLflow in Azure Machine Learning.

-* [Track Azure Synapse Analytics machine learning experiments](how-to-use-mlflow-azure-synapse.md) with MLflow in Azure Machine Learning.

-* [Training and tracking an XGBoost classifier with MLflow using service principal authentication](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-and-log/xgboost_service_principal.ipynb): Demonstrates how to track experiments by using MLflow from compute that's running outside Azure Machine Learning. It shows how to authenticate against Azure Machine Learning services by using a service principal.

-* [Hyper-parameter optimization using Hyperopt and nested runs in MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-and-log/xgboost_nested_runs.ipynb): Demonstrates how to use child runs in MLflow to do hyper-parameter optimization for models by using the popular library Hyperopt. It shows how to transfer metrics, parameters, and artifacts from child runs to parent runs.

-* [Logging models with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-and-log/logging_and_customizing_models.ipynb): Demonstrates how to use the concept of models instead of artifacts with MLflow, including how to construct custom models.

-> [!IMPORTANT]

-> - MLflow in R support is limited to tracking experiment's metrics, parameters and models on Azure Machine Learning jobs. Interactive training on RStudio, Posit (formerly RStudio Workbench) or Jupyter Notebooks with R kernels is not supported. Model management and registration is not supported using the MLflow R SDK. As an alternative, use Azure Machine Learning CLI or [Azure Machine Learning studio](https://ml.azure.com) for model registration and management. View the following [R example about using the MLflow tracking client with Azure Machine Learning](https://github.com/Azure/azureml-examples/tree/main/cli/jobs/single-step/r).

-> - MLflow in Java support is limited to tracking experiment's metrics and parameters on Azure Machine Learning jobs. Artifacts and models can't be tracked using the MLflow Java SDK. As an alternative, use the `Outputs` folder in jobs along with the method `mlflow.save_model` to save models (or artifacts) you want to capture. View the following [Java example about using the MLflow tracking client with the Azure Machine Learning](https://github.com/Azure/azureml-examples/tree/main/cli/jobs/single-step/java/iris).

-Azure Machine Learning supports MLflow for model management. This support represents a convenient way to support the entire model lifecycle for users who are familiar with the MLflow client.

-### Example notebooks

-You can [deploy MLflow models to Azure Machine Learning](how-to-deploy-mlflow-models.md) and take advantage of the improved experience when you use this type of models. Azure Machine Learning supports deploying MLflow models to both real-time and batch endpoints without having to indicate and environment or a scoring script. Deployment is supported using either MLflow SDK, Azure Machine Learning CLI, Azure Machine Learning SDK for Python, or the [Azure Machine Learning studio](https://ml.azure.com) portal.

-Learn more at [Guidelines for deploying MLflow models](how-to-deploy-mlflow-models.md).

-* [Deploy MLflow to Online Endpoints](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/mlflow_sdk_online_endpoints.ipynb): Demonstrates how to deploy models in MLflow format to online endpoints using MLflow SDK.

-* [Deploy MLflow to Online Endpoints with safe rollout](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/mlflow_sdk_online_endpoints_progresive.ipynb): Demonstrates how to deploy models in MLflow format to online endpoints using MLflow SDK with progressive rollout of models and the deployment of multiple model's versions in the same endpoint.

-* [Deploy MLflow to web services (V1)](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/mlflow_sdk_web_service.ipynb): Demonstrates how to deploy models in MLflow format to web services (ACI/AKS v1) using MLflow SDK.

-* [Deploying models trained in Azure Databricks to Azure Machine Learning with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/deploy/track_with_databricks_deploy_aml.ipynb): Demonstrates how to train models in Azure Databricks and deploy them in Azure Machine Learning. It also includes how to handle cases where you also want to track the experiments with the MLflow instance in Azure Databricks.

-## Training MLflow projects (preview)

-Learn more at [Train machine learning models with MLflow projects and Azure Machine Learning](how-to-train-mlflow-projects.md).

-* [Track an MLflow project in Azure Machine Learning workspaces](https://github.com/Azure/MachineLearningNotebooks/blob/master/how-to-use-azureml/track-and-monitor-experiments/using-mlflow/train-projects-local/train-projects-local.ipynb)

-The following table shows which operations are supported by each of the tools available in the machine learning lifecycle.

-> - ² Using MLflow projects (preview).

-> - ⁴ Deployment of MLflow models to batch inference by using the MLflow SDK is not possible at the moment. As an alternative, see [Deploy and run MLflow models in Spark jobs](how-to-deploy-mlflow-model-spark-jobs.md).

-## Next steps

-* [Concept: From artifacts to models in MLflow](concept-mlflow-models.md).

-* [How-to: Configure MLflow for Azure Machine Learning](how-to-use-mlflow-configure-tracking.md).

-* [How-to: Migrate logging from SDK v1 to MLflow](reference-migrate-sdk-v1-mlflow-tracking.md)

-* [How-to: Track ML experiments and models with MLflow](how-to-use-mlflow-cli-runs.md).

-* [How-to: Log MLflow models](how-to-log-mlflow-models.md).

-path_on_datastore '<path>'

- Install packages from a terminal window. Install Python packages into the **Python 3.8 - AzureML** environment. Install R packages into the **R** environment.

-> For package management within a notebook, use **%pip** or **%conda** magic functions to automatically install packages into the **currently-running kernel**, rather than **!pip** or **!conda** which refers to all packages (including packages outside the currently-running kernel)

-> While customizing the compute instance, make sure you do not delete the **azureml_py36** or **azureml_py38** conda environments. Also do not delete **Python 3.6 - AzureML** or **Python 3.8 - AzureML** kernels. These are needed for Jupyter/JupyterLab functionality.

-> While customizing the compute instance, make sure you do not delete the **azureml_py36** or **azureml_py38** conda environments. Also do not delete **Python 3.6 - AzureML** or **Python 3.8 - AzureML** kernels. These are needed for Jupyter/JupyterLab functionality.

-description: Learn how to create and manage runtimes in prompt flow with Azure Machine Learning studio.

-# Create and manage runtimes

-Prompt flow's runtime provides the computing resources required for the application to run, including a Docker image that contains all necessary dependency packages. This reliable and scalable runtime environment enables prompt flow to efficiently execute its tasks and functions, ensuring a seamless user experience for users.

-We support following types of runtimes:

-|automatic runtime (preview) |Serverless compute| Automatically | Customized by image + requirements.txt in `flow.dag.yaml`|

-|Compute instance runtime | Compute instance | Manually | Manually via Azure Machine Learning environment|

-For new users, we would recommend using the automatic runtime (preview) that can be used out of box, and you can easily customize the environment by adding packages in `requirements.txt` file in `flow.dag.yaml` in flow folder. For users, who already familiar with Azure Machine Learning environment and compute instance, your can use existing compute instance and environment to build your compute instance runtime.

-## Permissions/roles for runtime management

-To assign role, you need to have `owner` or have `Microsoft.Authorization/roleAssignments/write` permission on the resource.

-To use the runtime, assigning the `AzureML Data Scientist` role of workspace to user (if using Compute instance as runtime) or endpoint (if using managed online endpoint as runtime). To learn more, see [Manage access to an Azure Machine Learning workspace](../how-to-assign-roles.md?view=azureml-api-2&tabs=labeler&preserve-view=true)

-> [!NOTE]

-> Role assignment may take several minutes to take effect.

-## Permissions/roles for deployments

-After deploying a prompt flow, the endpoint must be assigned the `AzureML Data Scientist` role to the workspace for successful inferencing. This operation can be done at any point after the endpoint has been created.

-## Create runtime in UI

-### Prerequisites

-### Create automatic runtime (preview) in flow page

-Automatic is the default option for runtime, you can start automatic runtime (preview) in runtime dropdown in flow page.

-> Automatic runtime is currently in public preview. This preview is provided without a service-level agreement, and are not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.

-> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-create-automatic-init.png" alt-text="Screenshot of prompt flow on the start automatic with default settings on flow page. " lightbox = "./media/how-to-create-manage-runtime/runtime-create-automatic-init.png":::

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-automatic-settings.png" alt-text="Screenshot of prompt flow on the start automatic with advanced setting on flow page. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-automatic-settings.png":::

-### Create compute instance runtime in runtime page

-If you don't have a compute instance, create a new one: [Create and manage an Azure Machine Learning compute instance](../how-to-create-compute-instance.md).

-1. Select add runtime in runtime list page.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-runtime-list-add.png" alt-text="Screenshot of prompt flow on the runtime add with compute instance runtime selected. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-runtime-list-add.png":::

-1. Select compute instance you want to use as runtime.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-ci-runtime-select-ci.png" alt-text="Screenshot of add compute instance runtime with select compute instance highlighted. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-ci-runtime-select-ci.png":::

- Because compute instances is isolated by user, you can only see your own compute instances or the ones assigned to you. To learn more, see [Create and manage an Azure Machine Learning compute instance](../how-to-create-compute-instance.md).

-1. Authenticate on the compute instance. You only need to do auth one time per region in six months.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-authentication.png" alt-text="Screenshot of doing the authentication on compute instance. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-authentication.png":::

-1. Select create new custom application or existing custom application as runtime.

- 1. Select create new custom application as runtime.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-ci-runtime-select-custom-application.png" alt-text="Screenshot of add compute instance runtime with custom application highlighted. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-ci-runtime-select-custom-application.png":::

- This is recommended for most users of prompt flow. The prompt flow system creates a new custom application on a compute instance as a runtime.

- - To choose the default environment, select this option. This is the recommended choice for new users of prompt flow.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-runtime-list-add-default-env.png" alt-text="Screenshot of add compute instance runtime with environment highlighted. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-runtime-list-add-default-env.png":::

- - If you want to install other packages in your project, you should create a custom environment. To learn how to build your own custom environment, see [Customize environment with docker context for runtime](how-to-customize-environment-runtime.md#customize-environment-with-docker-context-for-runtime).

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-runtime-list-add-custom-env.png" alt-text="Screenshot of add compute instance runtime with customized environment and choose an environment highlighted. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-runtime-list-add-custom-env.png":::

- > [!NOTE]

- > - We are going to perform an automatic restart of your compute instance. Please ensure that you do not have any tasks or jobs running on it, as they may be affected by the restart.

- 1. To use an existing custom application as a runtime, choose the option "existing".

- This option is available if you have previously created a custom application on a compute instance. For more information on how to create and use a custom application as a runtime, learn more about [how to create custom application as runtime](how-to-customize-environment-runtime.md#create-a-custom-application-on-compute-instance-that-can-be-used-as-prompt-flow-compute-instance-runtime).

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-creation-ci-existing-custom-application-ui.png" alt-text="Screenshot of add compute instance runtime with custom application dropdown highlighted. " lightbox = "./media/how-to-create-manage-runtime/runtime-creation-ci-existing-custom-application-ui.png":::

-## Using runtime in prompt flow authoring

-When you're authoring your prompt flow, you can select and change the runtime from left top corner of the flow page.

-When performing evaluation, you can use the original runtime in the flow or change to a more powerful runtime.

-## Update runtime from UI

-### Update automatic runtime (preview) in flow page

-You can operate automatic runtime (preview) in flow page. Here are options you can use:

-You can also customize environment used to run this flow.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-create-automatic-save-install.png" alt-text="Screenshot of save and install packages for automatic runtime (preview) on flow page. " lightbox = "./media/how-to-create-manage-runtime/runtime-create-automatic-save-install.png":::

-> [!NOTE]

-> You can change the location and even file name of `requirements.txt` by change it in `flow.dag.yaml` file in flow folder as well.

-> Please don't pin version of promptflow and promptflow-tools in `requirements.txt`, as we already include them in runtime base image.

-#### Add packages in private feed in Azure DevOps

-If you want to use a private feed in Azure DevOps, you need follow these steps:

-1. Create user assigned managed identity and add this user assigned managed identity in the Azure DevOps organization. To learn more, see [Use service principals & managed identities](/azure/devops/integrate/get-started/authentication/service-principal-managed-identity).

- > [!NOTE]

- > If the 'Add Users' button isn't visible, it's likely you don't have the necessary permissions to perform this action.

-

-1. [Add or update user assigned identities to workspace](../how-to-identity-based-service-authentication.md#to-create-a-workspace-with-multiple-user-assigned-identities-use-one-of-the-following-methods).

-1. You need to add `{private}` to your private feed URL. For example, if you want to install `test_package` from `test_feed` in Azure devops, add `-i https://{private}@{test_feed_url_in_azure_devops}` in `requirements.txt`.

- ```txt

- -i https://{private}@{test_feed_url_in_azure_devops}

- test_package

- ```

-1. Specify the user assigned managed identity if `start with advanced setting` or **reset** automatic runtime in `edit`.

- :::image type="content" source="./media/how-to-create-manage-runtime/runtime-advanced-setting-msi.png" alt-text="Screenshot of specify user assigned managed identity. " lightbox = "./media/how-to-create-manage-runtime/runtime-advanced-setting-msi.png":::

-#### Change the base image used by automatic runtime (preview)

-By default, we use latest prompt flow image as base image. If you want to use a different base image, you can build custom base image learn more, see [Customize environment with docker context for runtime](how-to-customize-environment-runtime.md#customize-environment-with-docker-context-for-runtime), then you can use put it under `environment` in `flow.dag.yaml` file in flow folder. You need `reset` runtime to use the new base image, this takes several minutes as it pulls the new base image and install packages again.

-### Update compute instance runtime in runtime page

-Every time you open the runtime details page, we check whether there are new versions of the runtime. If there are new versions available, you see a notification at the top of the page. You can also manually check the latest version by selecting the **check version** button.

-Try to keep your runtime up to date to get the best experience and performance.

-Go to the runtime details page and select the "Update" button at the top. Here you can update the environment to use in your runtime. If you select **use default environment**, system attempts to update your runtime to the latest version.

-> [!NOTE]

-> If you used a custom environment, you need to rebuild it using the latest prompt flow image first, and then update your runtime with the new custom environment.

-Go to your workspace UI page, then go to the **environment** page, and locate the custom environment you created. You can now use it to create a compute instance runtime in your prompt flow. To learn more, see [Create compute instance runtime in UI](how-to-create-manage-runtime.md#create-compute-instance-runtime-in-runtime-page).

-If you want to use private feeds in Azure devops, see [Add packages in private feed in Azure devops](./how-to-create-manage-runtime.md#add-packages-in-private-feed-in-azure-devops).

-> If you are using private feeds in Azure devops, you need [build the image with private feeds](./how-to-create-manage-runtime.md#add-packages-in-private-feed-in-azure-devops) first and select custom environment to deploy in UI.

-This type of error related to runtime lacks required packages. If you're using a default environment, make sure the image of your runtime is using the latest version. For more information, see [Runtime update](../how-to-create-manage-runtime.md#update-runtime-from-ui). If you're using a custom image and you're using a conda environment, make sure you installed all the required packages in your conda environment. For more information, see [Customize a prompt flow environment](../how-to-customize-environment-runtime.md#customize-environment-with-docker-context-for-runtime).

-**Appliance** | You need a server to run the Azure Migrate appliance. The server should have:<br/><br/> - Windows Server 2022 installed.<br/> _(Currently the deployment of appliance is only supported on Windows Server 2022.)_<br/><br/> - 16-GB RAM, 8 vCPUs, around 80 GB of disk storage<br/><br/> - A static or dynamic IP address, with internet access, either directly or through a proxy.<br/><br/> - Outbound internet connectivity to the required [URLs](migrate-appliance.md#url-access) from the appliance.

-1. **Install the VDDK**: The appliance checks that VMware vSphere Virtual Disk Development Kit (VDDK) is installed. If the VDDK isn't installed, download VDDK 6.7 from VMware. Extract the downloaded zip file contents to the specified location on the appliance, the default path is *C:\Program Files\VMware\VMware Virtual Disk Development Kit* as indicated in the *Installation instructions*.

-In this article, we'll provide an overview and introduction to core concepts of the flexible server deployment model. For information on how to decide what deployment option is appropriate for your workload, see [choosing the right MySQL server option in Azure](./../select-right-deployment-type.md).

-* **750 hours of Burstable B1MS instance**, enough hours to run a database instance continuously each month.

-* **32 GB** storage and **32 GB** backup storage.

-You can take advantage of this offer to develop and deploy applications that use Azure Database for MySQL flexible server. To learn how to create and use Azure Database for MySQL flexible server for free using Azure free account, refer [this tutorial](how-to-deploy-on-azure-free-account.md).

-Azure Database for MySQL flexible server allows configuring high availability with automatic failover. The high availability solution is designed to ensure that committed data is never lost due to failures, and improve overall uptime for your application. When high availability is configured, flexible server automatically provisions and manages a standby replica. You're billed for the provisioned compute and storage for both the primary and secondary replica. There are two high availability-architectural models:

-The service performs automated patching of the underlying hardware, OS, and database engine. The patching includes security and software updates. For MySQL engine, minor version upgrades are also included as part of the planned maintenance release. Users can configure the patching schedule to be system managed or define their custom schedule. During the maintenance schedule, the patch is applied and server may require a restart as part of the patching process to complete the update. With the custom schedule, users can make their patching cycle predictable and choose a maintenance window with minimum impact to the business. In general, the service follows monthly release schedule as part of the continuous integration and release.

-See [Scheduled Maintenance](concepts-maintenance.md) for more details.

-You have two networking options to connect to Azure Database for MySQL flexible server. The options are **private access (VNet integration)** and **public access (allowed IP addresses)**.

-Azure Database for MySQL flexible server is available in three SKU tiers: Burstable, General Purpose, and Business Critical. The Burstable tier is best suited for low-cost development and low concurrency workloads that don't need full-compute capacity continuously. General Purpose and Business Critical are better suited for production workloads requiring high concurrency, scale, and predictable performance. You can build your first app on a small database for a few dollars a month, and then seamlessly adjust the scale to meet the needs of your solution. The storage scaling is online and supports storage autogrowth. Azure Database for MySQL flexible server enables you to provision additional IOPS up to 80K IOPs above the complimentary IOPS limit independent of storage. Using this feature, you can increase or decrease the number of IOPS provisioned based on your workload requirements at any time. Dynamic scalability enables your database to transparently respond to rapidly changing resource requirements. You only pay for the resources you consume.

-On the applications side, the application is typically developed in Java or PHP and migrated to run on [Azure virtual machine scale sets](../../virtual-machine-scale-sets/overview.md) or [Azure App Services](../../app-service/overview.md) or are containerized to run on [Azure Kubernetes Service (AKS)](../../aks/intro-kubernetes.md). With virtual machine scale set, App Service or AKS as underlying infrastructure, application scaling is simplified by instantaneously provisioning new VMs and replicating the stateless components of applications to cater to the requests but often, database ends up being a bottleneck as centralized stateful component.

-The read replica feature allows you to replicate data from an Azure Database for MySQL flexible server instance to a read-only server. You can replicate from the source server to **up to 10 replicas**. Replicas are updated asynchronously using the MySQL engine's native [binary log (binlog) file position-based replication technology](https://dev.mysql.com/doc/refman/5.7/en/replication-features.html). You can use a load balancer proxy solution like [ProxySQL](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/load-balance-read-replicas-using-proxysql-in-azure-database-for/ba-p/880042) to seamlessly scale out your application workload to read replicas without any application refactoring cost.

-* Hybrid Data Synchronization

-* Multicloud Synchronization

-* [Minimal downtime migration to Azure Database for MySQL flexible server](../../mysql/howto-migrate-single-flexible-minimum-downtime.md)

-For more information, see [Data-in replication concepts](concepts-data-in-replication.md).

-Azure Database for MySQL flexible server encrypts data in-motion with transport layer security enforced by default. Azure Database for MySQL flexible server by default supports encrypted connections using Transport Layer Security (TLS 1.2) and all incoming connections with TLS 1.0 and TLS 1.1 will be denied. SSL enforcement can be disabled by setting the require_secure_transport server parameter and you can set the minimum tls_version for your server.

-Azure Database for MySQL flexible server allows full-private access to the servers using [Azure virtual network](../../virtual-network/virtual-networks-overview.md) (VNet) integration. Servers in Azure virtual network can only be reached and connected through private IP addresses. With VNet integration, public access is denied and servers canΓÇÖt be reached using public endpoints.

-Azure Database for MySQL flexible server is equipped with built-in performance monitoring and alerting features. All Azure metrics have a one-minute frequency, and each metric provides 30 days of history. You can configure alerts on the metrics. Azure Database for MySQL flexible serverexposes host server metrics to monitor resources utilization, allows configuring slow query logs. Using these tools, you can quickly optimize your workloads, and configure your server for best performance. Azure Database for MySQL flexible server allows you to visualize the slow query and audit logs data using Azure Monitor workbooks. With workbooks, you get a flexible canvas for analyzing data and creating rich visual reports within the Azure portal. Azure Database for MySQL flexible server provides three available workbook templates out of the box viz Server Overview, [Auditing](tutorial-configure-audit.md) and [Query Performance Insights](tutorial-query-performance-insights.md). [Query Performance Insights](tutorial-query-performance-insights.md) workbook is designed to help you spend less time troubleshooting database performance by providing such information as:

-* Top N long-running queries and their trends.

-* The query details: view the query text as well as the history of execution with minimum, maximum, average, and standard deviation query time.

-* The resource utilizations (CPU, memory, and storage).

-* Using Azure Data Migration Service when network bandwidth between source and Azure is good (for example: High-speed ExpressRoute). Learn more with step-by-step instructions - [Migrate MySQL to Azure Database for MySQL flexible server offline using DMS - Azure Database Migration Service](../../dms/tutorial-mysql-azure-mysql-offline-portal.md)

-* Use mydumper/myloader to take advantage of compression settings to efficiently move data over low speed networks (such as public internet). Learn more with step-by-step instructions [Migrate large databases to Azure Database for MySQL flexible server using mydumper/myloader](../../mysql/concepts-migrate-mydumper-myloader.md)

-| West US 3 | :heavy_check_mark: | :heavy_check_mark: | :x: | :x: |

-Now that you've read an introduction to Azure Database for MySQL flexible server deployment mode, you're ready to:

-| Disk | 30 GB |

-Azure Operator Service Manager is an Azure service designed to assist telecom operators in managing their network services. It provides management capabilities for multi-vendor applications across hybrid cloud sites, encompassing Azure regions, edge platforms, and Arc-connected sites. Azure Operator Service Manager caters to the needs of telecom operators who are in the process of migrating their workloads to Azure and Arc-connected cloud environments.

-Contact your Microsoft account team to register your Azure subscription for access to Azure Operator Service Manager (AOSM) or express your interest through the [partner registration form](https://forms.office.com/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbR7lMzG3q6a5Hta4AIflS-llUMlNRVVZFS00xOUNRM01DNkhENURXU1o2TS4u).

-Azure Backup and Azure PostgreSQL Services have built an enterprise-class long-term backup solution for Azure Database for PostgreSQL Flexible servers that retain backups for up to 10 years. You can use long-term retention independently or in addition to the automated backup solution offered by Azure PostgreSQL, which offers retention of up to 35 days. Automated backups are physical backups suited for operational recoveries, especially when you want to restore from the latest backups. Long-term backups help you with your compliance needs, are more granular, and are taken as logical backups using native pg_dump. In addition to long-term retention, the solution offers the following capabilities:

-> [!IMPORTANT]

-> Promote operation is not automatic. In the event of a primary server failure, the system won't switch to the read replica independently. An user action is always required for the promote operation.

-* **Additional Considerations**: After a scaling event, there's an inherent DNS `Time-To-Live` (TTL) period of approximately 30 seconds. This period isn't directly controlled by the scaling process but is a standard part of DNS behavior. So, from a application perspective, the total downtime experienced during scaling could be in the range of **40 to 60 seconds**.

-#### Limitations

- - If you're using a route table, you need to create a rule with destination service tag `AzureActiveDirectory` and next hop `Internet`.

-| Brazil South | :heavy_check_mark: (v3 only) | :heavy_check_mark: | :heavy_check_mark: | :x: |

-| China North 3 | :heavy_check_mark: (v3/v4 only) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |

-! 2310 | 2309 | 2309 |

-|Microsoft Fabric|[Microsoft Fabric](reliability-fabric.md) |[Microsoft Fabric](reliability-fabric.md)

-Microsoft Sentinel's [Microsoft Defender XDR](/microsoft-365/security/mtp/microsoft-threat-protection) connector with incident integration allows you to stream all Microsoft Defender XDR incidents and alerts into Microsoft Sentinel, and keeps the incidents synchronized between both portals. Microsoft Defender XDR incidents include all their alerts, entities, and other relevant information, and they group together, and are enriched by, alerts from Microsoft Defender XDR's component services **Microsoft Defender for Endpoint**, **Microsoft Defender for Identity**, **Microsoft Defender for Office 365**, **Microsoft Defender for Cloud Apps**, and **Microsoft Defender for Cloud**, as well as alerts from other services such as **Microsoft Purview Data Loss Prevention** and **Microsoft Entra ID Protection**.

-Thanks to this integration, Microsoft Sentinel customers who have enabled [Defender XDR incident integration](microsoft-365-defender-sentinel-integration.md) will now be able to ingest and synchronize Defender for Cloud incidents, with all their alerts, through Microsoft Defender XDR.

-To support this integration, Microsoft Sentinel has added a new **Tenant-based Microsoft Defender for Cloud (Preview)** connector. This connector will allow Microsoft Sentinel customers to receive Defender for Cloud alerts and incidents across their entire tenants, without having to monitor and maintain the connector's enrollment to all their Defender for Cloud subscriptions.

-This connector can be used to ingest Defender for Cloud alerts, regardless of whether you have Defender XDR incident integration enabled.

-2. In **Operations**, select **Disaster recovery**.

-> [Set up disaster recovery after migration](azure-to-azure-quickstart.md)

- --jar-path app.jar \

- --jar-path app.jar \

- --jar-path app.jar \

- --jar-path ${CUSTOMERS_SERVICE_JAR} \

- --jar-path <path-to-jar-file>

-This article explains how to deploy microservice applications to Azure Spring Apps using the well-known sample app [PetClinic](https://github.com/spring-petclinic/spring-petclinic-microservices). The Pet Clinic sample demonstrates the microservice architecture pattern. The following diagram shows the architecture of the PetClinic application on Azure Spring Apps.

-> This article uses a simplified version of PetClinic, using an in-memory database that is not production-ready to quickly deploy to Azure Spring Apps.

->

-Using the URL information in the deployment log output, open the URL exposed by the app named `api-gateway` - for example, `https://<your-Azure-Spring-Apps-instance-name>-api-gateway.azuremicroservices.io`. The application should look similar to the following screenshot:

-Open the URL exposed by the app `admin-server` to manage the applications through the Spring Boot Admin Server, as shown in the following screenshot:

-1. Locate your resource group in the Azure portal. On the navigation menu, select **Resource groups**, and then select the name of your resource group.

- --jar-path target/asc-managed-identity-function-sample-0.1.0.jar

-./connnect.ps1 $rgname $esanname $vgname $vol1,$vol2,$vol3 32

-The machine learning models assume a uniformly sampled time series. If the time series isn't uniform, you may insert an aggregation step with a tumbling window prior to calling anomaly detection.

-The model's response time increases with history size because it needs to compare against a higher number of past events. It's recommended to only include the necessary number of events for better performance.

-An anomaly generator available [here](https://aka.ms/asaanomalygenerator) can be used to feed an Iot Hub with data with different anomaly patterns. An ASA job can be set up with these anomaly detection functions to read from this Iot Hub and detect anomalies.

-Persistent changes last much longer than spikes and dips and could indicate catastrophic event(s). Persistent changes aren't usually visible to the naked eye, but can be detected with the **AnomalyDetection_ChangePoint** operator.

-The following example query assumes a uniform input rate of one event per second in a 20-minute sliding window with a history size of 1200 events. The final SELECT statement extracts and outputs the score and anomaly status with a confidence level of 80%.

-The performance of these models depends on the history size, window duration, event load, and whether function level partitioning is used. This section discusses these configurations and provides samples for how to sustain ingestion rates of 1K, 5K and 10K events per second.

-* **History size** - These models perform linearly with **history size**. The longer the history size, the longer the models take to score a new event. This is because the models compare the new event with each of the past events in the history buffer.

-The following table includes the throughput observations for a single node (6 SU) for the non-partitioned case:

-The following table includes the throughput observations for a single node (6 SU) for the partitioned case:

-Sample code to run the non-partitioned configurations above is located in the [Streaming At Scale repo](https://github.com/Azure-Samples/streaming-at-scale/blob/f3e66fa9d8c344df77a222812f89a99b7c27ef22/eventhubs-streamanalytics-eventhubs/anomalydetection/create-solution.sh) of Azure Samples. The code creates a stream analytics job with no function level partitioning, which uses Event Hubs as input and output. The input load is generated using test clients. Each input event is a 1KB json document. Events simulate an IoT device sending JSON data (for up to 1K devices). The history size, window duration, and total event load are varied over 2 input partitions.

-Use the Metrics pane in your Azure Stream Analytics job to identify bottlenecks in your pipeline. Review **Input/Output Events** for throughput and ["Watermark Delay"](https://azure.microsoft.com/blog/new-metric-in-azure-stream-analytics-tracks-latency-of-your-streaming-pipeline/) or **Backlogged Events** to see if the job is keeping up with the input rate. For Event Hub metrics, look for **Throttled Requests** and adjust the Threshold Units accordingly. For Azure Cosmos DB metrics, review **Max consumed RU/s per partition key range** under Throughput to ensure your partition key ranges are uniformly consumed. For Azure SQL DB, monitor **Log IO** and **CPU**.

-To ensure compliance with latest security requirements, we are unable to accommodate requests to skip or delay these updates. However, you may have some options to adjust your maintenance window within the current cycle depending on your situation:

-The process covered in this article is an in-depth and adaptable approach to deploying Azure Virtual Desktop. If you want a more simple approach to deploy a sample Windows 11 desktop in Azure Virtual Desktop, see [Tutorial: Deploy a sample Azure Virtual Desktop infrastructure with a Windows 11 desktop](tutorial-try-deploy-windows-11-desktop.md) or use the [getting started feature](getting-started-feature.md).

-description: An overview of Azure Virtual Desktop.

-Azure Virtual Desktop is a desktop and app virtualization service that runs on the cloud.

-Here's what you can do when you run Azure Virtual Desktop on Azure:

-> [!IMPORTANT]

-> The user account must exist in the Microsoft Entra tenant you use for Azure Virtual Desktop. Azure Virtual Desktop doesn't support [B2B](../active-directory/external-identities/what-is-b2b.md), [B2C](../active-directory-b2c/overview.md), or personal Microsoft accounts.

->

-> When using hybrid identities, either the UserPrincipalName (UPN) or the Security Identifier (SID) must match across Active Directory Domain Services and Microsoft Entra ID. For more information, see [Supported identities and authentication methods](authentication.md#hybrid-identity).

-|Operating system |User access rights|

-|||

-|<ul><li>[Windows 11 Enterprise multi-session](/lifecycle/products/windows-11-enterprise-and-education)</li><li>[Windows 11 Enterprise](/lifecycle/products/windows-11-enterprise-and-education)</li><li>[Windows 10 Enterprise multi-session](/lifecycle/products/windows-10-enterprise-and-education)</li><li>[Windows 10 Enterprise](/lifecycle/products/windows-10-enterprise-and-education)</li><ul>|License entitlement:<ul><li>Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit</li><li>Windows Enterprise E3, E5</li><li>Windows VDA E3, E5</li><li>Windows Education A3, A5</li></ul>External users can use [per-user access pricing](https://azure.microsoft.com/pricing/details/virtual-desktop/) by enrolling an Azure subscription instead of license entitlement.</li></ul>|

-|<ul><li>[Windows Server 2022](/lifecycle/products/windows-server-2022)</li><li>[Windows Server 2019](/lifecycle/products/windows-server-2019)</li><li>[Windows Server 2016](/lifecycle/products/windows-server-2016)</li></ul>|License entitlement:<ul><li>Remote Desktop Services (RDS) Client Access License (CAL) with Software Assurance (per-user or per-device), or RDS User Subscription Licenses.</li></ul>Per-user access pricing isn't available for Windows Server operating systems.|

-> - Support for Windows Server 2012 R2 ended on October 10, 2023. For more information, view [SQL Server 2012 and Windows Server 2012/2012 R2 end of support](/lifecycle/announcements/sql-server-2012-windows-server-2012-2012-r2-end-of-support).

-description: Architecture recommendations for Azure Virtual Desktop for app developers.

-# Architecture recommendations

-Azure Virtual Desktop deployments come in many different shapes and sizes depending on many factors like end-user needs, the existing infrastructure of the organization deploying the service, and so on. How do you make sure you're using the right architecture that meets your organization's needs?

-This article will provide guidance for your Azure Virtual Desktop deployment structure. The examples listed in this article aren't the only possible ways you can deploy Azure Virtual Desktop. However, we do cover two of the most basic types of deployments for users inside and outside of your organization.

-## Deploying Azure Virtual Desktop for users within your organization

-If you're making an Azure Virtual Desktop deployment for users inside your organization, you can host all your users and resources in the same Azure tenant. You can also use Azure Virtual Desktop's currently supported identity management methods to keep your users secure.

-These are the most basic requirements for an Azure Virtual Desktop deployment that can serve desktops and applications to users within your organization:

-However, you can also build a deployment with multiple host pools that offer different apps to different groups of users.

-Some customers choose to create separate Azure subscriptions to store each Azure Virtual Desktop deployment in. This practice lets you distinguish the cost of each deployment from each other based on the sub-organizations they provide resources to. Others choose to use Azure billing scopes to distinguish costs at a more granular level. To learn more, see [Understand and work with scopes](../../cost-management-billing/costs/understand-work-scopes.md).

-## Deploying Azure Virtual Desktop for users outside your organization

-If your Azure Virtual Desktop deployment will serve end-users outside your organization, especially users that don't typically use Windows or don't have access to your organization's internal resources, you'll need to consider additional security recommendations.

-Azure Virtual Desktop doesn't currently support external identities, including business-to-business (B2B) or business-to-client (B2C) users. You'll need to create and manage these identities manually and provide the credentials to your users yourself. Users will then use these identities to access resources in Azure Virtual Desktop.

-To provide a secure solution to your customers, Microsoft strongly recommends creating a Microsoft Entra tenant and subscription for each customer with their own dedicated Active Directory. This separation means you'll have to create a separate Azure Virtual Desktop deployment for each organization that's totally isolated from the other deployments and their resources. The virtual machines that each organization uses shouldn't be able to access the resources of other companies to keep information secure. You can set up these separate deployments by using either a combination of Active Directory Domain Services (AD DS) and Microsoft Entra Connect or by using Microsoft Entra Domain Services.

-description: How to serve custom apps with Azure Virtual Desktop.

-# How to host custom apps with Azure Virtual Desktop

-Azure Virtual Desktop can host multiple types of Windows applications. We recommend you prepare your apps according to the type of app packages you plan to deploy your apps with. In this article, we'll explain what you need to do for each type of app package.

->[!NOTE]

->We recommend you host your apps on a multi-session host. We also recommend that you test your apps to make sure they behave as expected while running on your multi-session host. For example, run a test to see if two or more users on the same session host can successfully run the app at the same time.

-## MSIX

-MSIX is the recommended type of package for custom apps in Azure Virtual Desktop because they can take advantage of the service's built-in [MSIX app attach feature](../what-is-app-attach.md). To learn how to repackage existing Win32 applications in the MSIX format, visit [Repackage your existing Win32 applications to the MSIX format](/windows/application-management/msix-app-packaging-tool).

-Once you've packaged your app in the MSIX format, you can use Azure Virtual DesktopΓÇÖs MSIX app attach feature to deliver your apps to your customers. Learn how to use MSIX app attach for your apps at [Deploy apps with MSIX app attach](msix-app-attach.md).

-## Other options for Win32 applications

-You can also offer Win32 applications to your users without repackaging them in MSIX format by using the following options.

-### Include the application manually on session hosts

-Follow the instructions at [Prepare and customize a master VHD image](../set-up-customize-master-image.md) to include an app as part of the Windows image you use for your virtual machines. More specifically, follow the directions in the [Other applications and registry configuration](../set-up-customize-master-image.md#other-applications-and-registry-configuration) section to install the application for all users.

-### Use Microsoft Intune to deploy the application at scale

-If you use Microsoft Intune to manage your session hosts, you can deploy applications by following the instructions in [Install apps on Windows 10 devices](/mem/intune/apps/apps-windows-10-app-deploy#install-apps-on-windows-10-devices). Make sure you deploy your app in "device context" mode to all session hosts to make sure all users in your deployment can access the application.

-### Manual installation

-We don't recommend installing apps manually because it requires repeating the process for each session host. This method is more often used by IT professionals for testing purposes.

-If you must install your apps manually, you'll need to remote into your session host with an administrator account after you've set up your Azure Virtual Desktop host pool. After that, install the application like you would on a physical PC. You'll need to repeat this process to install the application on each session host in your host pool.

->[!NOTE]

->If the setup process gives you the option to install the application for all users, select that option.

-## Microsoft Store applications

-We don't recommend using Microsoft Store apps for RemoteApp streaming in Azure Virtual Desktop at this time.

-## Next steps

-To learn how to package and deploy apps using MSIX app attach, see [Deploy apps with MSIX app attach](msix-app-attach.md).

-description: How to create user accounts for RemoteApp streaming for your customers in Azure Virtual Desktop with Microsoft Entra ID, Microsoft Entra Domain Services, or AD DS.

-# Create user accounts for RemoteApp streaming

-Because Azure Virtual Desktop doesn't currently support external profiles, or "identities," your users won't be able to access the apps you host with their own corporate credentials. Instead, you'll need to create identities for them in the Active Directory Domain that you'll use for RemoteApp streaming and sync user objects to the associated Microsoft Entra tenant.

-In this article, we'll explain how you can manage user identities to provide a secure environment for your customers. We'll also talk about the different parts that make up an identity.

-## Requirements

-The identities you create need to follow these guidelines:

-> [!NOTE]

-> If you want to enable [single sign-on (SSO)](../configure-single-sign-on.md) and [Intune management](../management.md), you can do this for Microsoft Entra joined and Microsoft Entra hybrid joined VMs. Azure Virtual Desktop doesn't support SSO and Intune with VMs joined to Microsoft Entra Domain Services.

-The following two sections will tell you how to create identities with AD DS and Microsoft Entra Domain Services. To follow [the security guidelines for cross-organizational apps](security.md), you'll need to repeat the process for each customer.

-## Create users with Active Directory Domain Services

-In this method, you'll set up hybrid identities using an Active Directory Domain Controller to manage user identities and sync them to Microsoft Entra ID.

-This method involves setting up Active Directory Domain Controllers to manage the user identities and syncing the users to Microsoft Entra ID to create hybrid identities. These identities can then be used to access hosted applications in Azure Virtual Desktop. In this configuration, users are synced from Active Directory to Microsoft Entra ID and the session host VMs are joined to the AD DS domain.

-To set up an identity in AD DS:

-1. [Create a Microsoft Entra tenant](../../active-directory/fundamentals/active-directory-access-create-new-tenant.md) and a subscription for your customer.

-2. [Install Active Directory Domain Services](/windows-server/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-) on the Windows Server virtual machine (VM) you're using for the customer.

-3. Install and configure [Microsoft Entra Connect](../../active-directory/hybrid/how-to-connect-install-roadmap.md) on a separate domain-joined VM to sync the user accounts from Active Directory to Microsoft Entra ID.

-4. If you plan to manage the VMs using Intune, enable [Microsoft Entra hybrid joined devices](../../active-directory/devices/hybrid-join-plan.md) with Microsoft Entra Connect.

-5. Once you've configured the environment, [create new users](/previous-versions/windows/it-pro/windows-server-2003/cc755607(v=ws.10)) in the Active Directory. These users should automatically be synced with Microsoft Entra ID.

-6. When deploying session hosts in your host pool, use the Active Directory domain name to join the VMs and ensure the session hosts have line-of-sight to the domain controller.

-This configuration will give you more control over your environment, but its complexity can make it less easy to manage. However, this option lets you provide your users with Microsoft Entra ID-based apps. It also lets you manage your users' VMs with Intune.

-<a name='create-users-with-azure-active-directory-domain-services'></a>

-## Create users with Microsoft Entra Domain Services

-Microsoft Entra Domain Services identities are stored in a Microsoft managed Active Directory platform as a service (PaaS) where Microsoft manages two AD domain controllers that lets users use AD DS within their Azure subscriptions. In this configuration, users are synced from Microsoft Entra ID to Microsoft Entra Domain Services, and the session hosts are joined to the Microsoft Entra Domain Services domain. Microsoft Entra Domain Services identities are easier to manage, but don't offer as much control as regular AD DS identities. You can only join the Azure Virtual Desktop VMs to the Microsoft Entra Domain Services domain, and you can't manage them with Intune.

-To create an identity with Microsoft Entra Domain

-1. [Create a Microsoft Entra tenant](../../active-directory/fundamentals/active-directory-access-create-new-tenant.md) and subscription for your customer.

-2. [Deploy Microsoft Entra Directory Services](../../active-directory-domain-services/tutorial-create-instance.md) in the userΓÇÖs subscription.

-3. Once you've finished configuring the environment, [create new users](../../active-directory/fundamentals/add-users-azure-active-directory.md) in Microsoft Entra ID. These user objects will automatically sync with Microsoft Entra Domain Services.

-4. When deploying session hosts in a host pool, use the Microsoft Entra Domain Services domain name to join the VMs.

-## Next steps

-If you'd like to learn more about security considerations for setting up identities and tenants, see the [Security guidelines for cross-organizational apps](security.md).

-description: An overview of Azure Virtual Desktop licensing considerations for RemoteApp streaming.

-# Understanding licensing and per-user access pricing

-This article explains the licensing requirements for using Azure Virtual Desktop to stream applications remotely to external users. In this article, you'll learn how licensing Azure Virtual Desktop for external commercial purposes is different than for internal purposes, how per-user access pricing works in detail, and how to license other products you plan to use with Azure Virtual Desktop.

-## Internal and external purposes

-In the context of providing virtualized infrastructure with Azure Virtual Desktop, *internal users* refers to people who are members of your own organization, such as employees of a business or students of a school. *External users* aren't members of your organization, such as customers of a business.

->[!NOTE]

->Take care not to confuse external *users* with external *identities*. Azure Virtual Desktop doesn't currently support external identities, including guest accounts or business-to-business (B2B) identities. Whether you're serving internal users or external users with Azure Virtual Desktop, you'll need to create and manage identities for those users yourself. Per-user access pricing is not a way to enable guest user accounts with Azure Virtual Desktop. For more information, see [Architecture recommendations](architecture-recs.md).

-Licensing Azure Virtual Desktop works differently for internal and external commercial purposes. Consider the following examples:

-

-> [!IMPORTANT]

-> Per-user access pricing can only be used for external commercial purposes, not internal purposes. Check if your Azure Virtual Desktop solution is compatible with per-user access pricing by reviewing [our licensing documentation](https://www.microsoft.com/licensing/terms/productoffering/MicrosoftAzure/EAEAS#Documents).

-## Per-user access pricing for Azure Virtual Desktop

-Per-user access pricing lets you pay for Azure Virtual Desktop access rights on behalf of external users. You must enroll in per-user access pricing to build a compliant deployment for external users. To learn more, see [Enroll in per-user access pricing](per-user-access-pricing.md).

-You pay for per-user access pricing through your enrolled Azure subscription or subscriptions on top of your charges for virtual machines, storage, and other Azure services. Each billing cycle, you only pay for users who actually used the service. Only users that connect at least once to Azure Virtual Desktop that month incur an access charge.

-There are two price tiers for Azure Virtual Desktop per-user access pricing. Charges are determined automatically each billing cycle based on the type of [application groups](../environment-setup.md#app-groups) a user connected to.

-For more information about prices, see [Azure Virtual Desktop pricing](https://azure.microsoft.com/pricing/details/virtual-desktop/).

-Each price tier has flat per-user access charges. For example, a user incurs the same charge to your subscription no matter when or how many hours they used the service during that billing cycle.

-> [!IMPORTANT]

-> Azure Virtual Desktop will also charge users with separate assigned licenses that otherwise entitle them to Azure Virtual Desktop access. If you have internal users you're purchasing eligible licenses for, we recommend you give them access to Azure Virtual Desktop through a separate subscription that isn't enrolled in per-user access pricing to avoid effectively paying twice for those users.

-Azure Virtual Desktop will issue at most one access charge for a given user in a given billing period. For example, if your deployment grants user Alice access to Azure Virtual Desktop resources across two different Azure subscriptions in the same tenant, only the first subscription accessed by Alice will incur a usage charge.

-## Comparing licensing options

-Here's a summary of the two types of licenses for Azure Virtual Desktop you can choose from:

- - Grants Azure Virtual Desktop access rights for *internal purposes* only. It doesn't grant permission for external commercial purposes, not even identities you create in your own Microsoft Entra tenant.

- - Paid in advance through a subscription

- - Same cost per user each month regardless of user behavior

- - Includes entitlements to some other Microsoft products and services

- - Grants Azure Virtual Desktop access rights for *external commercial purposes* only. It doesn't grant access to members of your own organization or contractors for internal business purposes.

- - Pay-as-you-go through an Azure meter

- - Cost per user each month depends on user behavior

- - Only includes access rights to Azure Virtual Desktop

- - Includes use rights to leverage [FSlogix](/fslogix/overview-what-is-fslogix)

-> [!IMPORTANT]

-> Per-user access pricing only supports Windows Enterprise and Windows Enterprise multi-session client operating systems for session hosts. Windows Server session hosts are not supported with per-user access pricing.

-## Licensing other products and services for use with Azure Virtual Desktop

-The Azure Virtual Desktop per-user access license isn't a full replacement for a Windows or Microsoft 365 license. Per-user licenses only grant access rights to Azure Virtual Desktop and don't include Microsoft Office, Microsoft Defender XDR, or Universal Print. This means that if you choose a per-user license, you'll need to separately license other products and services to grant your users access to them in your Azure Virtual Desktop environment.

-There are a few ways to enable your external users to access Office:

-## Next steps

-Now that you're familiar with your licensing pricing options, you can start planning your Azure Virtual Desktop environment. Here are some articles that might help you:

-description: How to deploy apps with MSIX app attach for Azure Virtual Desktop.

-# Deploy apps with MSIX app attach

-This article is a basic outline of how to publish an application in Azure Virtual Desktop with the MSIX app attach feature. In this article, we'll also give you links to resources that can give you more in-depth explanations and instructions.

-## What is MSIX app attach?

-MSIX app attach is an application layering solution that lets you deliver applications to active user sessions in Azure Virtual Desktop. The MSIX package system separates apps from the operating system, making it easier to build images for virtual machines. MSIX packages also give you greater control over which apps your users can access in their virtual machines. You can even separate apps from the master image and give them to users later.

-To learn more, see [What is MSIX app attach?](../what-is-app-attach.md).

-## Requirements

-You'll need the following things to use MSIX app attach in Azure Virtual Desktop:

-## Create an MSIX package from an existing installer

-To start using MSIX app attach, you'll need to put your application inside of an MSIX package. Some apps already come in the MSIX format, but if you're using a legacy installer like MSI, ClickOnce, and so on, you'll need to convert the app into the MSIX package format. Learn how to convert your existing apps into MSIX format at our [MSIX overview article](/windows/msix/packaging-tool/create-an-msix-overview).

-## Test the application fidelity of your packaged app

-After you've repackaged your application as an MSIX package, you need to make sure your application fidelity is high. App fidelity is the application's behavior and performance before and after repackaging. An app package with high app fidelity has similar performance before and after.

-If you find that your app fidelity decreases after repackaging, your organization must test the app to make sure its performance meets user standards. If not, you may have to update your app to prevent the issue or try repackaging again.

-## Create an MSIX image

-Next, you'll need to create an MSIX image from your packaged app. An MSIX image is what happens when you expand an MSIX app package and store the resulting app in a VHD(X) or CIM storage. To learn how to create an MSIX image, see [Create an MSIX image](../app-attach-msixmgr.md#create-an-msix-image).

-## Configure an MSIX file share

-Next, you'll need to set up an MSIX network share to store MSIX images. Once configured, your session hosts will use the MSIX share to attach MSIX packages to active user sessions, delivering apps to your users. Learn how to set up an MSIX share at [Set up a file share for MSIX app attach](../app-attach-file-share.md).

-## Configure MSIX app attach for Azure Virtual Desktop host pool

-After you've uploaded an MSIX image to the MSIX share, you'll need to open up the Azure portal and configure the host pool you're going to use to accept MSIX app attach. Learn how to configure your host pool at [Set up MSIX app attach with the Azure portal](../app-attach-azure-portal.md).

-description: An overview of Azure Virtual Desktop RemoteApp streaming.

-# What is Azure Virtual Desktop RemoteApp streaming?

-Azure Virtual Desktop is a desktop and app virtualization service that runs on the cloud and lets you access your remote desktop anytime, anywhere. However, did you know you can also use Azure Virtual Desktop as a Platform as a Service (PaaS) to provide your organization's apps as Software as a Service (SaaS) to your customers? With Azure Virtual Desktop RemoteApp streaming, you can now use Azure Virtual Desktop to deliver apps to your customers over a secure network through virtual machines.

-If you're unfamiliar with Azure Virtual Desktop (or are new to app virtualization in general), we've gathered some resources here that can help you get your deployment up and running.

-## Requirements

-Before you get started, we recommend you take a look at the [overview for Azure Virtual Desktop](../overview.md) for a more in-depth list of system requirements for running Azure Virtual Desktop. While you're there, you can browse the rest of the Azure Virtual Desktop documentation if you want a more IT-focused look into the service, as most of the articles also apply to RemoteApp streaming for Azure Virtual Desktop. Once you understand the basics, you can use the RemoteApp streaming documentation more effectively.

-In order to set up an Azure Virtual Desktop deployment for your custom apps that's available to customers outside your organization, you'll need the following things:

-## Get started

-Now that you're ready, let's take a look at how you can set up your Azure Virtual Desktop deployment. You have two options to set yourself up for success. You can either set up your deployment manually or automatically. The next two sections will describe the differences between these two methods.

-### Set up Azure Virtual Desktop manually

-You can set up your deployment manually by following these tutorials:

-1. [Create a host pool with the Azure portal](../create-host-pools-azure-marketplace.md?toc=/azure/virtual-desktop/remote-app-streaming/toc.json&bc=/azure/virtual-desktop/breadcrumb/toc.json)

-2. [Manage application groups](../manage-app-groups.md?toc=/azure/virtual-desktop/remote-app-streaming/toc.json&bc=/azure/virtual-desktop/breadcrumb/toc.json)

-3. [Create a host pool to validate service updates](../create-validation-host-pool.md?toc=/azure/virtual-desktop/remote-app-streaming/toc.json&bc=/azure/virtual-desktop/breadcrumb/toc.json)

-4. [Set up service alerts](../set-up-service-alerts.md?toc=/azure/virtual-desktop/remote-app-streaming/toc.json&bc=/azure/virtual-desktop/breadcrumb/toc.json)

-### Set up Azure Virtual Desktop automatically

-If you'd prefer an automatic process, you can use the getting started feature to set up your deployment for you. For more information, check out these articles:

-## Customize and manage Azure Virtual Desktop

-Once you've set up Azure Virtual Desktop, you have lots of options to customize your deployment to meet your organization or customers' needs. These articles can help you get started:

-## Get to know your Azure Virtual Desktop deployment

-Read the following articles to understand concepts essential to creating and managing Azure Virtual Desktop deployments:

-## Next steps

-If you're ready to start setting up your deployment manually, head to the following tutorial.

-> [!div class="nextstepaction"]

-> [Create a host pool with the Azure portal](../create-host-pools-azure-marketplace.md?toc=/azure/virtual-desktop/remote-app-streaming/toc.json&bc=/azure/virtual-desktop/breadcrumb/toc.json)

-description: How to enroll in per-user access pricing for Azure Virtual Desktop.

-# Enroll your subscription in per-user access pricing

-Before external users can connect to your deployment, you need to enroll your subscription in per-user access pricing. Per-user access pricing entitles users outside of your organization to access apps and desktops in your subscription using identities that you provide and manage. Your enrolled subscription will be charged each month based on the number of distinct users that connect to Azure Virtual Desktop resources.

-> [!IMPORTANT]

-> Per-user access pricing with Azure Virtual Desktop doesn't currently support Citrix DaaS and VMware Horizon Cloud.

->[!NOTE]

->Take care not to confuse external *users* with external *identities*. Azure Virtual Desktop doesn't currently support external identities, including guest accounts or business-to-business (B2B) identities. Whether you're serving internal users or external users with Azure Virtual Desktop, you'll need to create and manage identities for those users yourself. Per-user access pricing is not a way to enable guest user accounts with Azure Virtual Desktop. For more information, see [Understanding licensing and per-user access pricing](licensing.md).

-## How to enroll

-To enroll your Azure subscription into per-user access pricing:

-1. Sign in to the Azure portal at [https://portal.azure.com](https://portal.azure.com/).

-2. Enter **Azure Virtual Desktop** into the search bar, then find and select **Azure Virtual Desktop** under Services.

-3. In the **Azure Virtual Desktop** overview page, select **Per-user access pricing**.

-4. In the list of subscriptions, select the subscription where you'll deploy Azure Virtual Desktop resources.

-5. Select **Enroll**.

-6. Review the Product Terms, then select **Enroll** to begin enrollment. It may take up to an hour for the enrollment process to finish.

-7. After enrollment is done, check the value in the **Per-user access pricing** column of the subscriptions list to make sure it's changed from ΓÇ£EnrollingΓÇ¥ to ΓÇ£Enrolled.ΓÇ¥

-## Next steps

-To learn more about per-user access pricing, see [Understanding licensing and per-user access pricing](licensing.md). If you want to learn how to estimate per-user app streaming costs for your deployment, see [Estimate per-user app streaming costs for Azure Virtual Desktop](streaming-costs.md). For estimating total deployment costs, see [Understanding total Azure Virtual Desktop deployment costs](total-costs.md).

-description: A guide for how to keep the apps you host in Azure Virtual Desktop secure across multiple organizations.

-# Security guidelines for cross-organizational apps

-When you host or stream apps on Azure Virtual Desktop, you reach a wide variety of users inside and outside of your organization. As a result, it's extremely important to know how to keep your deployment secure so that you can keep your organization and your customers safe. This guide will give you a basic understanding of possible safety concerns and how to address them.

-## Shared responsibility

-Before Azure Virtual Desktop, on-premises virtualization solutions like Remote Desktop Services require granting users access to roles like Gateway, Broker, Web Access, and so on. These roles had to be fully redundant and able to handle peak capacity. Admins would install these roles as part of the Windows Server OS, and they had to be domain-joined with specific ports accessible to public connections. To keep deployments secure, admins had to constantly make sure everything in the infrastructure was maintained and up-to-date.

-Meanwhile, Azure Virtual Desktop manages portions of the services on the customer's behalf. Specifically, Microsoft hosts and manages the infrastructure parts as part of the service. Partners and customers no longer have to manually manage the required infrastructure to let users access session host virtual machines (VMs). The service also has built-in advanced security capabilities like reverse connect, which reduces the risk involved with allowing users to access their remote desktops from anywhere.

-To keep the service flexible, the session hosts are hosted in the partner or customers' Azure subscription. This lets customers integrate the service with other Azure services and lets them connect on-premises network infrastructure with ExpressRoute or a virtual private network (VPN).

-Like many cloud services, there's a [shared set of security responsibilities](../../security/fundamentals/shared-responsibility.md) between you and Microsoft. When you use Azure Virtual Desktop, it's important to understand that while some parts of the service are secured for you, there are others you'll need to configure yourself according to your organization's security needs.

-You'll need to configure security in the following areas:

-For more information about how to configure each of these areas, check out our [security best practices](./../security-guide.md).

-## Combined Microsoft security platform

-You can protect workloads by using security features and controls from Microsoft 365, Azure, and Azure Virtual Desktop.

-When the user connects to the service over the internet, Microsoft Entra authenticates the user's credentials, enabling protective features like [multifactor authentication](../../active-directory/authentication/concept-mfa-howitworks.md) to help greatly reduce the risk of user identities being compromised.

-Azure Virtual Desktop has features like [Reverse Connect](../network-connectivity.md#reverse-connect-transport) that allow users to access the session host without having to open inbound ports. This feature is designed with scalability and service in mind, so it shouldn't limit your ability to expand session hosts, either. You can also use existing GPOs with this feature to apply additional security with support for Active Directory-joined VMs or, for Windows 10 session hosts that might involve Microsoft Entra join scenarios, [Microsoft Intune](/mem/intune/fundamentals/windows-virtual-desktop-multi-session).

-## Defense in depth

-Today's threat landscape requires designs with security approaches in mind. Ideally, you'll want to build a series of security mechanisms and controls layered throughout your computer network to protect your data and network from being compromised or attacked. This type of security design is what the United States Cybersecurity and Infrastructure Security Agency (CISA) calls "defense in depth".

-## Security boundaries

-Security boundaries separate the code and data of security domains with different levels of trust. For example, there's usually a security boundary between kernel mode and user mode. Most Microsoft software and services depend on multiple security boundaries to isolate devices on networks, VMs, and applications on devices. The following table lists each security boundary for Windows and what they do for overall security.

-| Security boundary | What the boundary does |

-|--|--|

-| Network boundary | An unauthorized network endpoint can't access or tamper with code and data on a customerΓÇÖs device. |

-| Kernel boundary | A non-administrative user mode process can't access or tamper with kernel code and data. Administrator-to-kernel is not a security boundary. |

-| Process boundary | An unauthorized user mode process can't access or tamper with the code and data of another process. |

-| AppContainer sandbox boundary | An AppContainer-based sandbox process can't access or tamper with code and data outside of the sandbox based on the container capabilities. |

-| User boundary | A user can't access or tamper with the code and data of another user without being authorized. |

-| Session boundary | A user session can't access or tamper with another user session without being authorized. |

-| Web browser boundary | An unauthorized website can't violate the same-origin policy, nor can it access or tamper with the native code and data of the Microsoft Edge web browser sandbox. |

-| Virtual machine boundary | An unauthorized Hyper-V guest virtual machine can't access or tamper with the code and data of another guest virtual machine; this includes Hyper-V isolated containers. |

-| Virtual Secure Mode (VSM) boundary | Code running outside of the VSM trusted process or enclave can't access or tamper with data and code within the trusted process. |

-## Security features

-Security features build upon security boundaries to strengthen protection against specific threats. However, in some cases, there can be by-design limitations that prevent the security feature from fully protecting the deployment.

-Azure Virtual Desktop supports most security features available in Windows. Security features that rely on hardware features, such as (v)TPM or nested virtualization, might require a separate support statement from the Azure Virtual Desktop team.

-To learn more about security feature support and servicing, see our [Microsoft Security Servicing Criteria for Windows](https://www.microsoft.com/msrc/windows-security-servicing-criteria).

-## Recommended security boundaries for Azure Virtual Desktop scenarios

-You'll also need to make certain choices about security boundaries on a case-by-case basis. For example, if a user in your organization needs local administrative privileges to install apps, you'll need to give them a personal desktop instead of a shared RDSH. We don't recommend giving users local admin privileges in multi-session pooled scenarios because these users can cross security boundaries for sessions or NTFS data permissions, shut down multi-session VMs, or do other things that could interrupt service or cause data losses.

-Users from the same organization, like knowledge workers with apps that don't require admin privileges, are great candidates for multi-session Remote Desktop session hosts like Windows 10 Enterprise multi-session. These session hosts reduce costs for your organization because multiple users can share a single VM, with only the overhead costs of a single OS. With profile technology like FSLogix, users can be assigned any VM in a host pool without noticing any service interruptions. This feature also lets you optimize costs by doing things like shutting down VMs during off-peak hours.

-If your situation requires users from different organizations to connect to your deployment, we recommend you have a separate tenant for identity services like Active Directory and Microsoft Entra ID. We also recommend you have a separate subscription for hosting Azure resources like Azure Virtual Desktop and VMs.

-The following table lists our recommendations for each scenario.

-| Trust level scenario | Recommended solution |

-||-|

-| Users from one organization with standard privileges | Windows 10 Enterprise multi-session |

-| Users require administrative privileges | Personal Desktops (VDI) |

-| Users from different organizations connecting | Separate Azure subscription |

-Let's take a look at our recommendations for some example scenarios.

-### Should I share Identity resources to reduce costs?

-We don't currently recommend using a shared identity system in Azure Virtual Desktop. We recommend that you have separate Identity resources that you deploy in a separate Azure subscription. These resources include Active Directories, Microsoft Entra ID, and VM workloads. Every user working for an individual organization will need additional infrastructure and associated maintenance costs, but this is currently the most feasible solution for security purposes.

-### Should I share a multi-session Remote Desktop (RD) session host VM to reduce costs?

-Multi-session RD session hosts save costs by sharing hardware resources like CPU and memory among users. This resource sharing lets you design for peak capacity, even if itΓÇÖs unlikely all users will need maximum resources at the same time. In a shared multi-session environment, hardware resources are shared and allocated so that they reduce the gap between usage and costs.

-In many cases, using multi-session is an acceptable way to reduce costs, but whether we recommend it depends on the trust level between users with simultaneous access to a shared multi-session instance. Typically, users that belong to the same organization have a sufficient and agreed-upon trust relationship. For example, a department or workgroup where people collaborate and can access each otherΓÇÖs personal information is an organization with a high trust level.

-Windows uses security boundaries and controls to ensure user processes and data are isolated between sessions. However, Windows still provides access to the instance the user is working on.

-This deployment would benefit from a security in depth strategy that adds more security boundaries that prevent users within and outside of the organization from getting unauthorized access to other users' personal information. Unauthorized data access happens because of an error in the configuration process by the system admin, such as an undisclosed security vulnerability or a known vulnerability that hasn't been patched out yet.

-On the other hand, Microsoft doesn't support granting users that work for different or competing companies access to the same multi-session environment. These scenarios have several security boundaries that can be attacked or abused, like network, kernel, process, user, or sessions. A single security vulnerability could cause unauthorized data and credential theft, personal information leaks, identity theft, and other issues. Virtualized environment providers are responsible for offering well-designed systems with multiple strong security boundaries and extra safety features enabled wherever possible.

-Reducing these potential threats requires a fault-proof configuration, patch management design process, and regular patch deployment schedules. It's better to follow the principles of defense in depth and keep environments separate.

-## Next steps

-Find our recommended guidelines for configuring security for your Azure Virtual Desktop deployment at our [security best practices](./../security-guide.md).

-description: How to estimate per-user billing costs for Azure Virtual Desktop.

-# Estimate per-user app streaming costs for Azure Virtual Desktop

-Per-user access pricing for Azure Virtual Desktop lets you grant access to apps and desktops hosted with Azure Virtual Desktop to users outside of your organization. To learn more about per-user access pricing for Azure Virtual Desktop, see [Understanding licensing and per-user access pricing](licensing.md). This article will show you how to estimate user access costs for your deployment, assuming full pricing.

->[!NOTE]

->The prices in this article are based on full price per-user subscriptions without promotional offers or discounts. Also, keep in mind that there are additional costs associated with an Azure Virtual Desktop deployment, such as infrastructure consumption costs. To learn more about these other costs, see [Understanding total Azure Virtual Desktop deployment costs](total-costs.md).

-## Requirements

-Before you can estimate per-user access costs for an existing deployment, youΓÇÖll need the following things:

-## Measure monthly user activity in a host pool

-In order to estimate total costs for running a host pool, you'll first need to know the number of active users over the past month. You can use Azure Virtual Desktop Insights to find this number.

-To check monthly active users on Azure Virtual Desktop Insights:

-1. Open the Azure portal, then search for and select **Azure Virtual Desktop**. After that, select **Insights** to open Azure Virtual Desktop Insights.

-2. Select the name of the subscription or host pool that you want to measure.

-3. On the **Overview** tab, find the **Monthly users (MAU)** chart in the **Utilization** section.

-4. Check the monthly active users (MAU) value for the most recent date. The MAU shows how many users connected to this host pool within the last 28 days before that date.

-## Estimate per-user access costs for an Azure Virtual Desktop host pool

-Next, we'll check the amount billed per billing cycle. This number is determined by how many users connected to at least one session host in your enrolled subscription.

-Additionally, there are two price tiers for users:

-You can estimate the total cost by checking how many users in each pricing tier connected to session hosts in your subscription.

-To check the number of users in each tier:

-1. Go to the [Azure Virtual Desktop pricing page](https://azure.microsoft.com/pricing/details/virtual-desktop/#pricing) and look for the "Apps" and "Desktops + apps" prices for your region.

-2. Use the connection volume number you found in step 4 of [Measure monthly activity in a host pool](#measure-monthly-user-activity-in-a-host-pool) to calculate the total user access cost.

-

- If your host pool uses a RemoteApp application group, you'll need to multiply the connection volume by the price value you see in "Apps." In other words, you'll need to use this equation:

- Connection volume x "Apps" price per user = total cost

- If your host pool uses a Desktop application group, multiply it by the "Apps + Desktops" price per user instead, like this:

- Connection volume x "Apps + Desktops" price per user = total cost

->[!IMPORTANT]

->Depending on your environment, the actual price may be very different from the estimate following these instructions will give you. For example, the estimate might be higher than the real cost because your users access resources from multiple host pools but you're only charged once per user each billing cycle. The estimate might also underestimate the costs if the user activity during the 28-day time window you're basing your data on doesn't match your typical monthly user activity. For example, a month with a week-long holiday or a major service outage will have lower-than-average user activity and won't give you an accurate estimate.

-## Next steps

-If you're interested in learning about estimating total costs for an entire Azure Virtual Desktop deployment, see [Understanding total Azure Virtual Desktop deployment costs](total-costs.md). To learn about licensing requirements and costs, see [Understanding licensing and per-user access pricing](licensing.md).

-description: How to estimate the total cost of your Azure Virtual Desktop deployment.

-# Understanding total Azure Virtual Desktop deployment costs

-Azure Virtual Desktop costs come from two sources: underlying Azure resource consumption and licensing. Azure Virtual Desktop costs are charged to the organization that owns the Azure Virtual Desktop deployment, not the end-users accessing the deployment resources. Some licensing charges must be paid in advance. Other licenses and the underlying resource consumption charges are based on meters that track your usage.

-In this article, we'll explain consumption and licensing costs, and how to estimate service costs before deploying Azure Virtual Desktop using the Azure Pricing Calculator. This article also includes instructions for how to use Azure Cost Management to view costs after deploying Azure Virtual Desktop.

->[!NOTE]

->The customer who pays for the Azure Virtual Desktop deployment is responsible for handling their deployment's lifetime resource management and costs. If the owner no longer needs resources connected to their Azure Virtual Desktop deployment, they should ensure those resources are properly removed. For more information, see [How to manage Azure resources by using the Azure portal](../../azure-resource-manager/management/manage-resources-portal.md).

-## Consumption costs

-Consumption costs are the sum of all Azure resource usage charges for users accessing an Azure Virtual Desktop host pool. These charges come from the session host virtual machines (VMs) inside the host pools, including resources shared by other products across Azure and any identity management systems that require running additional infrastructure to keep the service available, such as a domain controller for Active Directory Domain Services (AD DS).

-### Session host VM costs

-In Azure Virtual Desktop, session host VMs use the following three Azure

-These charges can be viewed at the Azure Resource Group level where the host pool-specific resources including session host VMs are assigned. If one or more host pools are also configured to use the paid Log Analytics service to send VM data to the optional Azure Virtual Desktop Insights feature, then the bill will also charge you for the Log Analytics for the corresponding Azure Resource Groups. For more information, see [Estimate Azure Virtual Desktop monitoring costs](../insights-costs.md).

-Of the three primary VM session host usage costs that are listed at the beginning of this section, compute usually costs the most. To mitigate compute costs and optimize resource demand with availability, many customers choose to [scale session hosts automatically](../set-up-scaling-script.md).

-### Domain controller costs for Active Directories

-Domain controller VMs use the following four Azure services at a minimum:

-If your Azure Virtual Desktop deployment relies on a domain controller to run its Active Directory, then you should include it in the total Azure Virtual Desktop deployment cost. Domain controllers that are hosted in Azure will also share the three Azure services for session host VMs described in [Session host VM costs](#session-host-vm-costs), because a standard Azure VM must also keep the Active DirectoryΓÇÖs identities available.

-However, domain controllers have a few key differences from session host VMs:

-### Shared service costs

-Depending on which features your Azure Virtual Desktop deployment uses, you may also have to pay for Azure storage for any combination of the following optional features:

-These features use Azure storage options like [Azure Files](../../storage/files/storage-files-introduction.md) and [Azure NetApp Files](../../azure-netapp-files/azure-netapp-files-introduction.md), so that means they can share their storage with other Azure services beyond Azure Virtual Desktop. We recommend creating a separate storage account for the storage you buy for your Azure Virtual Desktop features to make sure you can tell the difference between its costs and the costs for other Azure services you're using.

-### User access costs

-You pay user access costs each month for each user who connects to apps or desktops in your Azure Virtual Desktop deployment. To learn more about how Azure Virtual DesktopΓÇÖs per-user access pricing works, see [Understanding licensing and per-user access pricing](licensing.md).

-## Predicting costs before deploying Azure Virtual Desktop

-Now that you understand the basics, let's start estimating. To do this, we'll need to estimate both the consumption and user access costs.

-### Predicting consumption costs

-You can use the [Azure Pricing Calculator](https://azure.microsoft.com/pricing/calculator/) to estimate Azure Virtual Desktop consumption costs before creating a deployment. Here's how to predict consumption costs:

-1. In the pricing calculator, select the **Compute** tab to show the Azure Pricing Calculator compute options.

-2. Select **Azure Virtual Desktop**. The Azure Virtual Desktop calculator module should appear.

-3. Enter the values for your deployment into the fields to estimate your monthly Azure bill based on your expected compute, storage, and networking usage.

->[!NOTE]

->Currently, the Azure Pricing Calculator Azure Virtual Desktop module can only estimate consumption costs for session host VMs and the aggregate additional storage of any optional Azure Virtual Desktop features requiring storage that you choose to deploy. Your total cost may also include egress network traffic to Microsoft 365 services, such as OneDrive for Business or Exchange Online. However, you can add estimates for other Azure Virtual Desktop features in separate modules within the same Azure Pricing calculator page to get a more complete or modular cost estimate.

->

->You can add extra Azure Pricing Calculator modules to estimate the cost impact of other components of your deployment, including but not limited to:

->

->- Domain controllers

->- Other storage-dependent features, such as custom OS images, MSIX app attach, and Azure Virtual Desktop Insights

-### Predicting user access costs

-User access costs depend on the number of users that connect to your deployment each month. To learn how to estimate the total user access costs you can expect, see [Estimate per-user app streaming costs for Azure Virtual Desktop](streaming-costs.md).

-## Viewing costs after deploying Azure Virtual Desktop

-Once you deploy Azure Virtual Desktop, you can use [Azure Cost Management](../../cost-management-billing/cost-management-billing-overview.md) to view your billing invoices. This section will tell you how to look up prices for your current services.

-### Viewing bills for consumption costs

-With the proper [Azure RBAC](../../role-based-access-control/rbac-and-directory-admin-roles.md) permissions, users in your organization like billing admins can use [cost analysis tools](../../cost-management-billing/costs/cost-analysis-common-uses.md) and find Azure billing invoices through [Azure Cost Management](../../cost-management-billing/cost-management-billing-overview.md) to track monthly Azure Virtual Desktop consumption costs under your Azure subscription or subscriptions.

-### Viewing bills for user access costs

-User access costs will appear each billing cycle on the Azure billing invoice for any enrolled subscription, alongside consumption costs and other Azure charges.

-## Next steps

-If you'd like to get a clearer idea of how much specific parts of your deployment will cost, take a look at these articles:

-Azure Virtual Desktop is designed to provide a resilient, reliable, and secure service for organizations and users. The architecture of Azure Virtual Desktop comprises many components that make up the service connecting users to their desktops and apps. Most components are Microsoft-managed, but some are customer-managed.

- > - Support for Windows Server 2012 R2 ended on October 10, 2023. For more information, view [SQL Server 2012 and Windows Server 2012/2012 R2 end of support](/lifecycle/announcements/sql-server-2012-windows-server-2012-2012-r2-end-of-support).

-| Public | 1.2.4763 | [Windows 64-bit](https://go.microsoft.com/fwlink/?linkid=2139369) *(most common)*<br />[Windows 32-bit](https://go.microsoft.com/fwlink/?linkid=2139456)<br />[Windows ARM64](https://go.microsoft.com/fwlink/?linkid=2139370) |

-| Insider | 1.2.5102 | [Windows 64-bit](https://go.microsoft.com/fwlink/?linkid=2139233) *(most common)*<br />[Windows 32-bit](https://go.microsoft.com/fwlink/?linkid=2139144)<br />[Windows ARM64](https://go.microsoft.com/fwlink/?linkid=2139368) |

-## Updates for version 1.2.5102 (Insider)

-*Published: December 19, 2023*

-Download: [Windows 64-bit](https://go.microsoft.com/fwlink/?linkid=2139233), [Windows 32-bit](https://go.microsoft.com/fwlink/?linkid=2139144), [Windows ARM64](https://go.microsoft.com/fwlink/?linkid=2139368)

-## Updates for version 1.2.5018 (Insider)

-> We replaced this Insiders version with [version 1.2.5102](#updates-for-version-125102-insider). As a result, version 1.2.5018 is no longer available for download.

-Download: [Windows 64-bit](https://go.microsoft.com/fwlink/?linkid=2139369), [Windows 32-bit](https://go.microsoft.com/fwlink/?linkid=2139456), [Windows ARM64](https://go.microsoft.com/fwlink/?linkid=2139370)

-Download: [Windows 64-bit](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RW1d1KN), [Windows 32-bit](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RW1d1KO), [Windows ARM64](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RW1cRm0)

-Ultra disks are designed to provide submillisecond latencies and target IOPS and throughput described in the preceding table 99.99% of the time.

-Ultra disks feature a flexible performance configuration model that allows you to independently configure IOPS and throughput both before and after you provision the disk. Ultra disks come in several fixed sizes, ranging from 4 GiB up to 64 TiB.

-With Premium SSD v2 disks, you can individually set the capacity, throughput, and IOPS of a disk based on your workload needs, providing you with more flexibility and reduced costs. Each of these values determines the cost of your disk.

-description: Learn how to configure private IP addresses for virtual machines (Classic) using the Azure portal.

-# Configure private IP addresses for a virtual machine (Classic) using the Azure portal

-This article covers the classic deployment model. You can also [manage a static private IP address in the Resource Manager deployment model](virtual-networks-static-private-ip-arm-pportal.md).

-The sample steps that follow expect an environment already created. If you want to run the steps as they're displayed in this document, first build the test environment described in [create a vnet](/previous-versions/azure/virtual-network/virtual-networks-create-vnet-classic-pportal).

-## How to specify a static private IP address when creating a VM

-To create a VM named *DNS01* in the *FrontEnd* subnet of a VNet named *TestVNet* with a static private IP of *192.168.1.101*, complete the following steps:

-1. From a browser, navigate to the [Azure portal](https://portal.azure.com) and, if necessary, sign in with your Azure account.

-1. Select **NEW** > **Compute** > **Windows Server 2012 R2 Datacenter**, notice that the **Select a deployment model** list already shows **Classic**, and then select **Create**.

-

- :::image type="content" source="./media/virtual-networks-static-ip-classic-pportal/figure01.png" alt-text="Screenshot that shows the Azure portal with the New > Compute > Windows Server 2012 R2 Datacenter tile highlighted.":::

-1. In **Create VM**, enter the name of the VM to be created (*DNS01* in the scenario), the local administrator account, and password.

-

- :::image type="content" source="./media/virtual-networks-static-ip-classic-pportal/figure02.png" alt-text="Screenshot that shows how to create a VM by entering the name of the VM, local administrator user name, and password.":::

-1. Select **Optional Configuration** > **Network** > **Virtual Network**, and then select **TestVNet**. If **TestVNet** isn't available, make sure you're using the *Central US* location and have created the test environment described at the beginning of this article.

- :::image type="content" source="./media/virtual-networks-static-ip-classic-pportal/figure03.png" alt-text="Screenshot that shows the Optional Configuration > Network > Virtual Network > TestVNet option highlighted.":::

-1. In **Network**, make sure the subnet currently selected is *FrontEnd*, then select **IP addresses**, under **IP address assignment** select **Static**, and then enter *192.168.1.101* for **IP Address** as seen in the following screenshot.

- :::image type="content" source="./media/virtual-networks-static-ip-classic-pportal/figure04.png" alt-text="Screenshot that highlights the IP Addresses field where you type the static IP address.":::

-

-1. Select **OK** under **IP addresses**, select **OK** under **Network**, and then select **OK** under **Optional config**.

-1. Under **Create VM**, select **Create**. Notice the following tile displayed in your dashboard:

- :::image type="content" source="./media/virtual-networks-static-ip-classic-pportal/figure05.png" alt-text="Screenshot that shows the Creating Windows Server 2012 R2 Datacenter tile.":::

-## How to retrieve static private IP address information for a VM

-To view the static private IP address information for the VM created with the previous steps, execute the following steps.

-1. From the Azure portal, select **BROWSE ALL** > **Virtual machines (classic)** > **DNS01** > **All settings** > **IP addresses** and notice the following IP address assignment and IP address information:

- :::image type="content" source="./media/virtual-networks-static-ip-classic-pportal/figure06.png" alt-text=" Screenshot of create VM in Azure portal.":::

-## How to remove a static private IP address from a VM

-Under **IP addresses**, select **Dynamic** to the right of **IP address assignment**, select **Save**, and then select **Yes**, as shown in the following picture:

-## How to add a static private IP address to an existing VM

-1. Under **IP addresses**, shown previously, select **Static** to the right of **IP address assignment**.

-1. Type *192.168.1.101* for **IP address**, select **Save**, and then select **Yes**.

-## Set IP addresses within the operating system

-ItΓÇÖs recommended that you don't statically assign the private IP assigned to the Azure virtual machine within the operating system of a VM, unless necessary. If you do manually set the private IP address within the operating system, ensure that it's the same address as the private IP address assigned to the Azure VM. Failure to match the IP address could result in loss of connectivity to the virtual machine.

-## Next steps

-* Learn about [reserved public IP](/previous-versions/azure/virtual-network/virtual-networks-reserved-public-ip) addresses.

-* Learn about [instance-level public IP (ILPIP)](/previous-versions/azure/virtual-network/virtual-networks-instance-level-public-ip) addresses.

-* Consult the [Reserved IP REST APIs](/previous-versions/azure/reference/dn722420(v=azure.100)).

-description: Learn how to configure private IP addresses for virtual machines (Classic) using PowerShell.

-# Configure private IP addresses for a virtual machine (Classic) using PowerShell

-This article covers the classic deployment model. You can also [manage a static private IP address in the Resource Manager deployment model](virtual-networks-static-private-ip-arm-ps.md).

-The following sample PowerShell commands expect a simple environment already created. If you want to run the commands as they're displayed in this document, first build the test environment described in [Create a VNet](/previous-versions/azure/virtual-network/virtual-networks-create-vnet-classic-netcfg-ps).

-## How to verify if a specific IP address is available

-To verify if the IP address *192.168.1.101* is available in a VNet named *TestVNet*, run the following PowerShell command and verify the value for *IsAvailable*:

-```azurepowershell

-$tstip = @{

- VNetName = "TestVNet"

- IPAddress = "192.168.1.101"

-}

-Test-AzureStaticVNetIP @tstip

-```

-Expected output:

-```output

-IsAvailable : True

-AvailableAddresses : {}

-OperationDescription : Test-AzureStaticVNetIP

-OperationId : fd3097e1-5f4b-9cac-8afa-bba1e3492609

-OperationStatus : Succeeded

-```

-## How to specify a static private IP address when creating a VM

-The following PowerShell script creates a new cloud service named *TestService*. The script then retrieves an image from Azure and creates a VM named *DNS01* in the new cloud service. Finally, the script using the sets the VM to be in a subnet named *FrontEnd*, and sets *192.168.1.7* as a static private IP address for the VM:

-```azurepowershell

-$azsrv = @{

- ServiceName = "TestService"

- Location = "Central US"

-}

-New-AzureService @azsrv

-$image = Get-AzureVMImage | where {$_.ImageName -like "*RightImage-Windows-2012R2-x64*"}

-$azcfg = @{

- Name = "DNS01"

- InstanceSize = "Small"

- ImageName = $image.ImageName

-}

-$azprv = @{

- AdminUsername = "adminuser"

-}

-$azsub = @{

- SubnetNames = "FrontEnd"

-}

-$azip = @{

- IPAddress = "192.168.1.7"

-}

-$azvm = @{

- ServiceName = "TestService"

- VNetsName = "TestVNet"

-}

-New-AzureVMConfig @azcfg | Add-AzureProvisioningConfig @azprv -Windows | Set-AzureSubnet @azsub | Set-AzureStaticVNetIP @azip | New-AzureVM @azvm

-```

-Expected output:

-```output

-WARNING: No deployment found in service: 'TestService'.

-OperationDescription OperationId OperationStatus

-New-AzureService fcf705f1-d902-011c-95c7-b690735e7412 Succeeded

-New-AzureVM 3b99a86d-84f8-04e5-888e-b6fc3c73c4b9 Succeeded

-```

-## How to retrieve static private IP address information for a VM

-To view the static private IP address information for the VM created with the previous script, run the following PowerShell command and observe the values for *IpAddress*:

-```azurepowershell

-$vm = @{

- Name = "DNS01"

- ServiceName = "TestService"

-}

-Get-AzureVM @vm

-```

-Expected output:

-```output

-DeploymentName : TestService

-Name : DNS01

-Label :

-VM : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVM

-InstanceStatus : Provisioning

-IpAddress : 192.168.1.7

-InstanceStateDetails : Windows is preparing your computer for first use...

-PowerState : Started

-InstanceErrorCode :

-InstanceFaultDomain : 0

-InstanceName : DNS01

-InstanceUpgradeDomain : 0

-InstanceSize : Small

-HostName : rsR2-797

-AvailabilitySetName :

-DNSName : http://testservice000.cloudapp.net/

-Status : Provisioning

-GuestAgentStatus : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.GuestAgentStatus

-ResourceExtensionStatusList : {Microsoft.Compute.BGInfo}

-PublicIPAddress :

-PublicIPName :

-NetworkInterfaces : {}

-ServiceName : TestService

-OperationDescription : Get-AzureVM

-OperationId : 34c1560a62f0901ab75cde4fed8e8bd1

-OperationStatus : OK

-```

-## How to remove a static private IP address from a VM

-To remove the static private IP address added to the VM in the previous script, run the following PowerShell command:

-```azurepowershell

-$vm = @{

- Name = "DNS01"

- ServiceName = "TestService"

-}

-Get-AzureVM -ServiceName @vm | Remove-AzureStaticVNetIP | Update-AzureVM

-```

-Expected output:

-```output

-OperationDescription OperationId OperationStatus

-Update-AzureVM 052fa6f6-1483-0ede-a7bf-14f91f805483 Succeeded

-```

-## How to add a static private IP address to an existing VM

-To add a static private IP address to the VM created using the previous script, run the following command:

-```azurepowershell

-$vm = {

- Name = "DNS01"

- ServiceName = "TestService"}

-$ip = {

- IPAddress = "192.168.1.7"

-}

-Get-AzureVM @vm | Set-AzureStaticVNetIP @ip | Update-AzureVM

-```

-Expected output:

-```output

-OperationDescription OperationId OperationStatus

-Update-AzureVM 77d8cae2-87e6-0ead-9738-7c7dae9810cb Succeeded

-```

-## Set IP addresses within the operating system

-ItΓÇÖs recommended that you don't statically assign the private IP assigned to the Azure virtual machine within the operating system of a VM, unless necessary. If you do manually set the private IP address within the operating system, ensure that it's the same address as the private IP address assigned to the Azure VM. Failure to match the IP address could result in loss of connectivity to the virtual machine.

-## Next steps

-* Learn about [reserved public IP](/previous-versions/azure/virtual-network/virtual-networks-reserved-public-ip) addresses.

-* Learn about [instance-level public IP (ILPIP)](/previous-versions/azure/virtual-network/virtual-networks-instance-level-public-ip) addresses.

-* Consult the [Reserved IP REST APIs](/previous-versions/azure/reference/dn722420(v=azure.100)).

-description: Use Azure Resource Manager template to move Azure network security group from one Azure region to another using the Azure portal.

-# Move Azure network security group (NSG) to another region using the Azure portal

-There are various scenarios in which you'd want to move your existing NSGs from one region to another. For example, you may want to create an NSG with the same configuration and security rules for testing. You may also want to move an NSG to another region as part of disaster recovery planning.

-Azure security groups can't be moved from one region to another. You can however, use an Azure Resource Manager template to export the existing configuration and security rules of an NSG. You can then stage the resource in another region by exporting the NSG to a template, modifying the parameters to match the destination region, and then deploy the template to the new region. For more information on Resource Manager and templates, see [Quickstart: Create and deploy Azure Resource Manager templates by using the Azure portal](../azure-resource-manager/templates/quickstart-create-templates-use-the-portal.md).

-## Prerequisites

-## Prepare and move

-The following steps show how to prepare the network security group for the configuration and security rule move using a Resource Manager template, and move the NSG configuration and security rules to the target region using the portal.

-### Export the template and deploy from the portal

-1. Login to the [Azure portal](https://portal.azure.com) > **Resource Groups**.

-2. Locate the Resource Group that contains the source NSG and click on it.

-3. Select > **Settings** > **Export template**.

-4. Choose **Deploy** in the **Export template** blade.

-5. Click **TEMPLATE** > **Edit parameters** to open the **parameters.json** file in the online editor.

-6. To edit the parameter of the NSG name, change the **value** property under **parameters**:

- ```json

- {

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "networkSecurityGroups_myVM1_nsg_name": {

- "value": "<target-nsg-name>"

- }

- }

- }

- ```

-7. Change the source NSG value in the editor to a name of your choice for the target NSG. Ensure you enclose the name in quotes.

-8. Click **Save** in the editor.

-9. Click **TEMPLATE** > **Edit template** to open the **template.json** file in the online editor.

-10. To edit the target region where the NSG configuration and security rules will be moved, change the **location** property under **resources** in the online editor:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/networkSecurityGroups",

- "apiVersion": "2019-06-01",

- "name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",

- "location": "<target-region>",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",

- }

- }

- ]

- ```

-11. To obtain region location codes, see [Azure Locations](https://azure.microsoft.com/global-infrastructure/locations/). The code for a region is the region name with no spaces, **Central US** = **centralus**.

-12. You can also change other parameters in the template if you choose, and are optional depending on your requirements:

- * **Security rules** - You can edit which rules are deployed into the target NSG by adding or removing rules to the **securityRules** section in the **template.json** file:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/networkSecurityGroups",

- "apiVersion": "2019-06-01",

- "name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",

- "location": "<target-region>",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",

- "securityRules": [

- {

- "name": "RDP",

- "etag": "W/\"c630c458-6b52-4202-8fd7-172b7ab49cf5\"",

- "properties": {

- "provisioningState": "Succeeded",

- "protocol": "TCP",

- "sourcePortRange": "*",

- "destinationPortRange": "3389",

- "sourceAddressPrefix": "*",

- "destinationAddressPrefix": "*",

- "access": "Allow",

- "priority": 300,

- "direction": "Inbound",

- "sourcePortRanges": [],

- "destinationPortRanges": [],

- "sourceAddressPrefixes": [],

- "destinationAddressPrefixes": []

- }

- },

- ]

- }

- ```

- To complete the addition or the removal of the rules in the target NSG, you must also edit the custom rule types at the end of the **template.json** file in the format of the example below:

- ```json

- {

- "type": "Microsoft.Network/networkSecurityGroups/securityRules",

- "apiVersion": "2019-06-01",

- "name": "[concat(parameters('networkSecurityGroups_myVM1_nsg_name'), '/Port_80')]",

- "dependsOn": [

- "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_myVM1_nsg_name'))]"

- ],

- "properties": {

- "provisioningState": "Succeeded",

- "protocol": "*",

- "sourcePortRange": "*",

- "destinationPortRange": "80",

- "sourceAddressPrefix": "*",

- "destinationAddressPrefix": "*",

- "access": "Allow",

- "priority": 310,

- "direction": "Inbound",

- "sourcePortRanges": [],

- "destinationPortRanges": [],

- "sourceAddressPrefixes": [],

- "destinationAddressPrefixes": []

- }

- ```

-13. Click **Save** in the online editor.

-14. Click **BASICS** > **Subscription** to choose the subscription where the target NSG will be deployed.

-15. Click **BASICS** > **Resource group** to choose the resource group where the target NSG will be deployed. You can click **Create new** to create a new resource group for the target NSG. Ensure the name isn't the same as the source resource group of the existing NSG.

-16. Verify **BASICS** > **Location** is set to the target location where you wish for the NSG to be deployed.

-17. Verify under **SETTINGS** that the name matches the name that you entered in the parameters editor above.

-18. Check the box under **TERMS AND CONDITIONS**.

-19. Click the **Purchase** button to deploy the target network security group.

-## Discard

-If you wish to discard the target NSG, delete the resource group that contains the target NSG. To do so, select the resource group from your dashboard in the portal and select **Delete** at the top of the overview page.

-## Clean up

-To commit the changes and complete the move of the NSG, delete the source NSG or resource group. To do so, select the network security group or resource group from your dashboard in the portal and select **Delete** at the top of each page.

-## Next steps

-In this tutorial, you moved an Azure network security group from one region to another and cleaned up the source resources. To learn more about moving resources between regions and disaster recovery in Azure, refer to:

-description: Use Azure Resource Manager template to move Azure network security group from one Azure region to another using Azure PowerShell.

-# Move Azure network security group (NSG) to another region using Azure PowerShell

-There are various scenarios in which you'd want to move your existing NSGs from one region to another. For example, you may want to create an NSG with the same configuration and security rules for testing. You may also want to move an NSG to another region as part of disaster recovery planning.

-Azure security groups can't be moved from one region to another. You can however, use an Azure Resource Manager template to export the existing configuration and security rules of an NSG. You can then stage the resource in another region by exporting the NSG to a template, modifying the parameters to match the destination region, and then deploy the template to the new region. For more information on Resource Manager and templates, see [Export resource groups to templates](../azure-resource-manager/management/manage-resource-groups-powershell.md#export-resource-groups-to-templates).

-## Prerequisites

-

-## Prepare and move

-The following steps show how to prepare the network security group for the configuration and security rule move using a Resource Manager template, and move the NSG configuration and security rules to the target region using Azure PowerShell.

-### Export the template and deploy from a script

-1. Sign in to your Azure subscription with the [Connect-AzAccount](/powershell/module/az.accounts/connect-azaccount) command and follow the on-screen directions:

-

- ```azurepowershell-interactive

- Connect-AzAccount

- ```

-2. Obtain the resource ID of the NSG you want to move to the target region and place it in a variable using [Get-AzNetworkSecurityGroup](/powershell/module/az.network/get-aznetworksecuritygroup):

- ```azurepowershell-interactive

- $sourceNSGID = (Get-AzNetworkSecurityGroup -Name <source-nsg-name> -ResourceGroupName <source-resource-group-name>).Id

- ```

-3. Export the source NSG to a .json file into the directory where you execute the command [Export-AzResourceGroup](/powershell/module/az.resources/export-azresourcegroup):

-

- ```azurepowershell-interactive

- Export-AzResourceGroup -ResourceGroupName <source-resource-group-name> -Resource $sourceNSGID -IncludeParameterDefaultValue

- ```

-4. The file downloaded will be named after the resource group the resource was exported from. Locate the file that was exported from the command named **\<resource-group-name>.json** and open it in an editor of your choice:

-

- ```azurepowershell

- notepad <source-resource-group-name>.json

- ```

-5. To edit the parameter of the NSG name, change the property **defaultValue** of the source NSG name to the name of your target NSG, ensure the name is in quotes:

-

- ```json

- {

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "networkSecurityGroups_myVM1_nsg_name": {

- "defaultValue": "<target-nsg-name>",

- "type": "String"

- }

- }

- ```

-6. To edit the target region where the NSG configuration and security rules will be moved, change the **location** property under **resources**:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/networkSecurityGroups",

- "apiVersion": "2019-06-01",

- "name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",

- "location": "<target-region>",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",

- }

- }

- ```

-

-7. To obtain region location codes, you can use the Azure PowerShell cmdlet [Get-AzLocation](/powershell/module/az.resources/get-azlocation) by running the following command:

- ```azurepowershell-interactive

- Get-AzLocation | format-table

-

- ```

-8. You can also change other parameters in the **\<resource-group-name>.json** if you choose, and are optional depending on your requirements:

- * **Security rules** - You can edit which rules are deployed into the target NSG by adding or removing rules to the **securityRules** section in the **\<resource-group-name>.json** file:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/networkSecurityGroups",

- "apiVersion": "2019-06-01",

- "name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",

- "location": "TARGET REGION",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",

- "securityRules": [

- {

- "name": "RDP",

- "etag": "W/\"c630c458-6b52-4202-8fd7-172b7ab49cf5\"",

- "properties": {

- "provisioningState": "Succeeded",

- "protocol": "TCP",

- "sourcePortRange": "*",

- "destinationPortRange": "3389",

- "sourceAddressPrefix": "*",

- "destinationAddressPrefix": "*",

- "access": "Allow",

- "priority": 300,

- "direction": "Inbound",

- "sourcePortRanges": [],

- "destinationPortRanges": [],

- "sourceAddressPrefixes": [],

- "destinationAddressPrefixes": []

- }

- ]

- }

-

- ```

- To complete the addition or the removal of the rules in the target NSG, you must also edit the custom rule types at the end of the **\<resource-group-name>.json** file in the format of the example below:

- ```json

- {

- "type": "Microsoft.Network/networkSecurityGroups/securityRules",

- "apiVersion": "2019-06-01",

- "name": "[concat(parameters('networkSecurityGroups_myVM1_nsg_name'), '/Port_80')]",

- "dependsOn": [

- "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_myVM1_nsg_name'))]"

- ],

- "properties": {

- "provisioningState": "Succeeded",

- "protocol": "*",

- "sourcePortRange": "*",

- "destinationPortRange": "80",

- "sourceAddressPrefix": "*",

- "destinationAddressPrefix": "*",

- "access": "Allow",

- "priority": 310,

- "direction": "Inbound",

- "sourcePortRanges": [],

- "destinationPortRanges": [],

- "sourceAddressPrefixes": [],

- "destinationAddressPrefixes": []

- }

- ```

-9. Save the **\<resource-group-name>.json** file.

-10. Create a resource group in the target region for the target NSG to be deployed using [New-AzResourceGroup](/powershell/module/az.resources/new-azresourcegroup):

-

- ```azurepowershell-interactive

- New-AzResourceGroup -Name <target-resource-group-name> -location <target-region>

- ```

-

-11. Deploy the edited **\<resource-group-name>.json** file to the resource group created in the previous step using [New-AzResourceGroupDeployment](/powershell/module/az.resources/new-azresourcegroupdeployment):

- ```azurepowershell-interactive

- New-AzResourceGroupDeployment -ResourceGroupName <target-resource-group-name> -TemplateFile <source-resource-group-name>.json

-

- ```

-12. To verify the resources were created in the target region, use [Get-AzResourceGroup](/powershell/module/az.resources/get-azresourcegroup) and [Get-AzNetworkSecurityGroup](/powershell/module/az.network/get-aznetworksecuritygroup):

-

- ```azurepowershell-interactive

- Get-AzResourceGroup -Name <target-resource-group-name>

- ```

- ```azurepowershell-interactive

- Get-AzNetworkSecurityGroup -Name <target-nsg-name> -ResourceGroupName <target-resource-group-name>

- ```

-## Discard

-After the deployment, if you wish to start over or discard the NSG in the target, delete the resource group that was created in the target and the moved NSG will be deleted. To remove the resource group, use [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup):

-```azurepowershell-interactive

-Remove-AzResourceGroup -Name <target-resource-group-name>

-```

-## Clean up

-To commit the changes and complete the move of the NSG, delete the source NSG or resource group, use [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup) or [Remove-AzNetworkSecurityGroup](/powershell/module/az.network/remove-aznetworksecuritygroup):

-```azurepowershell-interactive

-Remove-AzResourceGroup -Name <source-resource-group-name>

-```

-``` azurepowershell-interactive

-Remove-AzNetworkSecurityGroup -Name <source-nsg-name> -ResourceGroupName <source-resource-group-name>

-```

-## Next steps

-In this tutorial, you moved an Azure network security group from one region to another and cleaned up the source resources. To learn more about moving resources between regions and disaster recovery in Azure, refer to:

-description: Use a template to move Azure Public IP configuration from one Azure region to another using the Azure portal.

-# Move Azure Public IP configuration to another region using the Azure portal

-There are various scenarios in which you'd want to move your existing Azure Public IP configurations from one region to another. For example, you may want to create a public IP with the same configuration and sku for testing. You may also want to move a public IP configuration to another region as part of disaster recovery planning.

-**Azure Public IPs are region specific and can't be moved from one region to another.** You can however, use an Azure Resource Manager template to export the existing configuration of a public IP. You can then stage the resource in another region by exporting the public IP to a template, modifying the parameters to match the destination region, and then deploy the template to the new region. For more information on Resource Manager and templates, see [Quickstart: Create and deploy Azure Resource Manager templates by using the Azure portal](../azure-resource-manager/templates/quickstart-create-templates-use-the-portal.md).

-## Prerequisites

-## Prepare and move

-The following steps show how to prepare the public IP for the configuration move using a Resource Manager template, and move the public IP configuration to the target region using the Azure portal.

-### Export the template and deploy from a script

-1. Login to the [Azure portal](https://portal.azure.com) > **Resource Groups**.

-2. Locate the Resource Group that contains the source public IP and click on it.

-3. Select > **Settings** > **Export template**.

-4. Choose **Deploy** in the **Export template** blade.

-5. Click **TEMPLATE** > **Edit parameters** to open the **parameters.json** file in the online editor.

-8. To edit the parameter of the public IP name, change the property under **parameters** > **value** from the source public IP name to the name of your target public IP, ensure the name is in quotes:

- ```json

- {

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "publicIPAddresses_myVM1pubIP_name": {

- "value": "<target-publicip-name>"

- }

- }

- }

- ```

-8. Click **Save** in the editor.

-9. Click **TEMPLATE** > **Edit template** to open the **template.json** file in the online editor.

-10. To edit the target region where the public IP will be moved, change the **location** property under **resources**:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/publicIPAddresses",

- "apiVersion": "2019-06-01",

- "name": "[parameters('publicIPAddresses_myPubIP_name')]",

- "location": "<target-region>",

- "sku": {

- "name": "Basic",

- "tier": "Regional"

- },

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",

- "ipAddress": "52.177.6.204",

- "publicIPAddressVersion": "IPv4",

- "publicIPAllocationMethod": "Dynamic",

- "idleTimeoutInMinutes": 4,

- "ipTags": []

- }

- }

- ]

- ```

-11. To obtain region location codes, see [Azure Locations](https://azure.microsoft.com/global-infrastructure/locations/). The code for a region is the region name with no spaces, **Central US** = **centralus**.

-12. You can also change other parameters in the template if you choose, and are optional depending on your requirements:

- * **Sku** - You can change the sku of the public IP in the configuration from standard to basic or basic to standard by altering the **sku** > **name** property in the **template.json** file:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/publicIPAddresses",

- "apiVersion": "2019-06-01",

- "name": "[parameters('publicIPAddresses_myPubIP_name')]",

- "location": "<target-region>",

- "sku": {

- "name": "Basic",

- "tier": "Regional"

- },

- ```

- For more information on the differences between basic and standard sku public ips, see [Create, change, or delete a public IP address](./ip-services/virtual-network-public-ip-address.md):

- * **Public IP allocation method** and **Idle timeout** - You can change both of these options in the template by altering the **publicIPAllocationMethod** property from **Dynamic** to **Static** or **Static** to **Dynamic**. The idle timeout can be changed by altering the **idleTimeoutInMinutes** property to your desired amount. The default is **4**:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/publicIPAddresses",

- "apiVersion": "2019-06-01",

- "name": "[parameters('publicIPAddresses_myPubIP_name')]",

- "location": "<target-region>",

- "sku": {

- "name": "Basic",

- "tier": "Regional"

- },

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",

- "ipAddress": "52.177.6.204",

- "publicIPAddressVersion": "IPv4",

- "publicIPAllocationMethod": "Dynamic",

- "idleTimeoutInMinutes": 4,

- "ipTags": []

- ```

- For more information on the allocation methods and the idle timeout values, see [Create, change, or delete a public IP address](./ip-services/virtual-network-public-ip-address.md).

-13. Click **Save** in the online editor.

-14. Click **BASICS** > **Subscription** to choose the subscription where the target public IP will be deployed.

-15. Click **BASICS** > **Resource group** to choose the resource group where the target public IP will be deployed. You can click **Create new** to create a new resource group for the target public IP. Ensure the name isn't the same as the source resource group of the existing source public IP.

-16. Verify **BASICS** > **Location** is set to the target location where you wish for the public IP to be deployed.

-17. Verify under **SETTINGS** that the name matches the name that you entered in the parameters editor above.

-18. Check the box under **TERMS AND CONDITIONS**.

-19. Click the **Purchase** button to deploy the target public IP.

-## Discard

-If you wish to discard the target public IP, delete the resource group that contains the target public IP. To do so, select the resource group from your dashboard in the portal and select **Delete** at the top of the overview page.

-## Clean up

-To commit the changes and complete the move of the public IP, delete the source public IP or resource group. To do so, select the public IP or resource group from your dashboard in the portal and select **Delete** at the top of each page.

-## Next steps

-In this tutorial, you moved an Azure Public IP from one region to another and cleaned up the source resources. To learn more about moving resources between regions and disaster recovery in Azure, refer to:

-description: Use Azure Resource Manager template to move Azure Public IP configuration from one Azure region to another using Azure PowerShell.

-# Move Azure Public IP configuration to another region using Azure PowerShell

-There are various scenarios in which you'd want to move your existing Azure Public IP configurations from one region to another. For example, you may want to create a public IP with the same configuration and sku for testing. You may also want to move a public IP configuration to another region as part of disaster recovery planning.

-**Azure Public IPs are region specific and can't be moved from one region to another.** You can however, use an Azure Resource Manager template to export the existing configuration of a public IP. You can then stage the resource in another region by exporting the public IP to a template, modifying the parameters to match the destination region, and then deploy the template to the new region. For more information on Resource Manager and templates, see [Export resource groups to templates](../azure-resource-manager/management/manage-resource-groups-powershell.md#export-resource-groups-to-templates)

-## Prerequisites

-

-## Prepare and move

-The following steps show how to prepare the public IP for the configuration move using a Resource Manager template, and move the public IP configuration to the target region using Azure PowerShell.

-### Export the template and deploy from a script

-1. Sign in to your Azure subscription with the [Connect-AzAccount](/powershell/module/az.accounts/connect-azaccount) command and follow the on-screen directions:

-

- ```azurepowershell-interactive

- Connect-AzAccount

- ```

-2. Obtain the resource ID of the public IP you want to move to the target region and place it in a variable using [Get-AzPublicIPAddress](/powershell/module/az.network/get-azpublicipaddress):

- ```azurepowershell-interactive

- $sourcePubIPID = (Get-AzPublicIPaddress -Name <source-public-ip-name> -ResourceGroupName <source-resource-group-name>).Id

- ```

-3. Export the source virtual network to a .json file into the directory where you execute the command [Export-AzResourceGroup](/powershell/module/az.resources/export-azresourcegroup):

-

- ```azurepowershell-interactive

- Export-AzResourceGroup -ResourceGroupName <source-resource-group-name> -Resource $sourceVNETID -IncludeParameterDefaultValue

- ```

-4. The file downloaded will be named after the resource group the resource was exported from. Locate the file that was exported from the command named **\<resource-group-name>.json** and open it in an editor of your choice:

-

- ```azurepowershell

- notepad <source-resource-group-name>.json

- ```

-5. To edit the parameter of the public IP name, change the property **defaultValue** of the source public IP name to the name of your target public IP, ensure the name is in quotes:

-

- ```json

- {

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "publicIPAddresses_myVM1pubIP_name": {

- "defaultValue": "<target-publicip-name>",

- "type": "String"

- }

- }

- ```

-6. To edit the target region where the public IP will be moved, change the **location** property under resources:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/publicIPAddresses",

- "apiVersion": "2019-06-01",

- "name": "[parameters('publicIPAddresses_myPubIP_name')]",

- "location": "<target-region>",

- "sku": {

- "name": "Basic",

- "tier": "Regional"

- },

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",

- "ipAddress": "52.177.6.204",

- "publicIPAddressVersion": "IPv4",

- "publicIPAllocationMethod": "Dynamic",

- "idleTimeoutInMinutes": 4,

- "ipTags": []

- }

- }

- ]

- ```

-

-7. To obtain region location codes, you can use the Azure PowerShell cmdlet [Get-AzLocation](/powershell/module/az.resources/get-azlocation) by running the following command:

- ```azurepowershell-interactive

- Get-AzLocation | format-table

- ```

-8. You can also change other parameters in the template if you choose, and are optional depending on your requirements:

- * **Sku** - You can change the sku of the public IP in the configuration from standard to basic or basic to standard by altering the **sku** > **name** property in the **\<resource-group-name>.json** file:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/publicIPAddresses",

- "apiVersion": "2019-06-01",

- "name": "[parameters('publicIPAddresses_myPubIP_name')]",

- "location": "<target-region>",

- "sku": {

- "name": "Basic",

- "tier": "Regional"

- },

- ```

- For more information on the differences between basic and standard sku public ips, see [Create, change, or delete a public IP address](./ip-services/virtual-network-public-ip-address.md).

- * **Public IP allocation method** and **Idle timeout** - You can change both of these options in the template by altering the **publicIPAllocationMethod** property from **Dynamic** to **Static** or **Static** to **Dynamic**. The idle timeout can be changed by altering the **idleTimeoutInMinutes** property to your desired amount. The default is **4**:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/publicIPAddresses",

- "apiVersion": "2019-06-01",

- "name": "[parameters('publicIPAddresses_myPubIP_name')]",

- "location": "<target-region>",

- "sku": {

- "name": "Basic",

- "tier": "Regional"

- },

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",

- "ipAddress": "52.177.6.204",

- "publicIPAddressVersion": "IPv4",

- "publicIPAllocationMethod": "Dynamic",

- "idleTimeoutInMinutes": 4,

- "ipTags": []

- }

- }

- ```

- For more information on the allocation methods and the idle timeout values, see [Create, change, or delete a public IP address](./ip-services/virtual-network-public-ip-address.md).

-9. Save the **\<resource-group-name>.json** file.

-10. Create a resource group in the target region for the target public IP to be deployed using [New-AzResourceGroup](/powershell/module/az.resources/new-azresourcegroup).

-

- ```azurepowershell-interactive

- New-AzResourceGroup -Name <target-resource-group-name> -location <target-region>

- ```

-11. Deploy the edited **\<resource-group-name>.json** file to the resource group created in the previous step using [New-AzResourceGroupDeployment](/powershell/module/az.resources/new-azresourcegroupdeployment):

- ```azurepowershell-interactive

- New-AzResourceGroupDeployment -ResourceGroupName <target-resource-group-name> -TemplateFile <source-resource-group-name>.json

- ```

-12. To verify the resources were created in the target region, use [Get-AzResourceGroup](/powershell/module/az.resources/get-azresourcegroup) and [Get-AzPublicIPAddress](/powershell/module/az.network/get-azpublicipaddress):

-

- ```azurepowershell-interactive

- Get-AzResourceGroup -Name <target-resource-group-name>

- ```

- ```azurepowershell-interactive

- Get-AzPublicIPAddress -Name <target-publicip-name> -ResourceGroupName <target-resource-group-name>

- ```

-## Discard

-After the deployment, if you wish to start over or discard the public ip in the target, delete the resource group that was created in the target and the moved public IP will be deleted. To remove the resource group, use [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup):

-```azurepowershell-interactive

-Remove-AzResourceGroup -Name <target-resource-group-name>

-```

-## Clean up

-To commit the changes and complete the move of the virtual network, delete the source virtual network or resource group, use [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup) or [Remove-AzPublicIPAddress](/powershell/module/az.network/remove-azpublicipaddress):

-```azurepowershell-interactive

-Remove-AzResourceGroup -Name <source-resource-group-name>

-```

-``` azurepowershell-interactive

-Remove-AzPublicIpAddress -Name <source-publicip-name> -ResourceGroupName <resource-group-name>

-```

-## Next steps

-In this tutorial, you moved an Azure Public IP from one region to another and cleaned up the source resources. To learn more about moving resources between regions and disaster recovery in Azure, refer to:

-description: Move an Azure virtual network from one Azure region to another by using a Resource Manager template and the Azure portal.

-# Move an Azure virtual network to another region by using the Azure portal

-There are various scenarios for moving an existing Azure virtual network from one region to another. For example, you might want to create a virtual network with the same configuration for testing and availability as your existing virtual network. Or you might want to move a production virtual network to another region as part of your disaster recovery planning.

-You can use an Azure Resource Manager template to complete the move of the virtual network to another region. You do this by exporting the virtual network to a template, modifying the parameters to match the destination region, and then deploying the template to the new region. For more information about Resource Manager templates, see [Quickstart: Create and deploy Azure Resource Manager templates by using the Azure portal](../azure-resource-manager/templates/quickstart-create-templates-use-the-portal.md).

-## Prerequisites

-## Prepare for the move

-In this section, you prepare the virtual network for the move by using a Resource Manager template. You then move the virtual network to the target region by using the Azure portal.

-To export the virtual network and deploy the target virtual network by using the Azure portal, do the following:

-1. Sign in to the [Azure portal](https://portal.azure.com), and then select **Resource Groups**.

-1. Locate the resource group that contains the source virtual network, and then select it.

-1. Select **Automation** > **Export template**.

-1. In the **Export template** pane, select **Deploy**.

-1. To open the *parameters.json* file in your online editor, select **Template** > **Edit parameters**.

-1. To edit the parameter of the virtual network name, change the **value** property under **parameters**:

- ```json

- {

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "virtualNetworks_myVNET1_name": {

- "value": "<target-virtual-network-name>"

- }

- }

- }

- ```

-1. In the editor, change the source virtual network name value in the editor to a name that you want for the target virtual network. Be sure to enclose the name in quotation marks.

-1. Select **Save** in the editor.

-1. To open the *template.json* file in the online editor, select **Template** > **Edit template**.

-1. In the online editor, to edit the target region where the virtual network will be moved, change the **location** property under **resources**:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/virtualNetworks",

- "apiVersion": "2019-06-01",

- "name": "[parameters('virtualNetworks_myVNET1_name')]",

- "location": "<target-region>",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",

- "addressSpace": {

- "addressPrefixes": [

- "10.0.0.0/16"

- ]

- },

- ```

-1. To obtain region location codes, see [Azure Locations](https://azure.microsoft.com/global-infrastructure/locations/). The code for a region is the region name, without spaces (for example, **Central US** = **centralus**).

-1. (Optional) You can also change other parameters in the template, depending on your requirements:

- * **Address Space**: Before you save the file, you can alter the address space of the virtual network by modifying the **resources** > **addressSpace** section and changing the **addressPrefixes** property:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/virtualNetworks",

- "apiVersion": "2019-06-01",

- "name": "[parameters('virtualNetworks_myVNET1_name')]",

- "location": "<target-region",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",

- "addressSpace": {

- "addressPrefixes": [

- "10.0.0.0/16"

- ]

- },

- ```

- * **Subnet**: You can change or add to the subnet name and the subnet address space by changing the template's **subnets** section. You can change the name of the subnet by changing the **name** property. And you can change the subnet address space by changing the **addressPrefix** property:

- ```json

- "subnets": [

- {

- "name": "subnet-1",

- "etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.0.0/24",

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- },

- {

- "name": "GatewaySubnet",

- "etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.1.0/29",

- "serviceEndpoints": [],

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- }

- ]

- ```

- To change the address prefix in the *template.json* file, edit it in two places: in the code in the preceding section and in the **type** section of the following code. Change the **addressPrefix** property in the following code to match the **addressPrefix** property in the code in the preceding section.

- ```json

- "type": "Microsoft.Network/virtualNetworks/subnets",

- "apiVersion": "2019-06-01",

- "name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/GatewaySubnet')]",

- "dependsOn": [

- "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_myVNET1_name'))]"

- ],

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.1.0/29",

- "serviceEndpoints": [],

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- },

- {

- "type": "Microsoft.Network/virtualNetworks/subnets",

- "apiVersion": "2019-06-01",

- "name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/subnet-1')]",

- "dependsOn": [

- "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_myVNET1_name'))]"

- ],

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.0.0/24",

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- }

- ]

- ```

-1. In the online editor, select **Save**.

-1. To choose the subscription where the target virtual network will be deployed, select **Basics** > **Subscription**.

-1. To choose the resource group where the target virtual network will be deployed, select **Basics** > **Resource group**.

- If you need to create a new resource group for the target virtual network, select **Create new**. Make sure that the name isn't the same as the source resource group name in the existing virtual network.

-1. Verify that **Basics** > **Location** is set to the target location where you want the virtual network to be deployed.

-1. Under **Settings**, verify that the name matches the name that you entered previously in the parameters editor.

-1. Select the **Terms and Conditions** check box.

-1. To deploy the target virtual network, select **Purchase**.

-## Delete the target virtual network

-To discard the target virtual network, you delete the resource group that contains the target virtual network. To do so:

-1. On the Azure portal dashboard, select the resource group.

-1. At the top of the **Overview** pane, select **Delete**.

-## Clean up

-To commit the changes and complete the virtual network move, you delete the source virtual network or resource group. To do so:

-1. On the Azure portal dashboard, select the virtual network or resource group.

-1. At the top of each pane, select **Delete**.

-## Next steps

-In this tutorial, you moved an Azure virtual network from one region to another by using the Azure portal and then cleaned up the unneeded source resources. To learn more about moving resources between regions and disaster recovery in Azure, see:

-description: Move an Azure virtual network from one Azure region to another by using a Resource Manager template and Azure PowerShell.

-# Move an Azure virtual network to another region by using Azure PowerShell

-There are various scenarios for moving an existing Azure virtual network from one region to another. For example, you might want to create a virtual network with the same configuration for testing and availability as your existing virtual network. Or you might want to move a production virtual network to another region as part of your disaster recovery planning.

-You can use an Azure Resource Manager template to complete the move of the virtual network to another region. You do this by exporting the virtual network to a template, modifying the parameters to match the destination region, and then deploying the template to the new region. For more information about Resource Manager templates, see [Export resource groups to templates](../azure-resource-manager/management/manage-resource-groups-powershell.md#export-resource-groups-to-templates).

-## Prerequisites

-

-## Prepare for the move

-In this section, you prepare the virtual network for the move by using a Resource Manager template. You then move the virtual network to the target region by using Azure PowerShell commands.

-To export the virtual network and deploy the target virtual network by using PowerShell, do the following:

-1. Sign in to your Azure subscription with the [Connect-AzAccount](/powershell/module/az.accounts/connect-azaccount) command, and then follow the on-screen directions:

-

- ```azurepowershell-interactive

- Connect-AzAccount

- ```

-1. Obtain the resource ID of the virtual network that you want to move to the target region, and then place it in a variable by using [Get-AzVirtualNetwork](/powershell/module/az.network/get-azvirtualnetwork):

- ```azurepowershell-interactive

- $sourceVNETID = (Get-AzVirtualNetwork -Name <source-virtual-network-name> -ResourceGroupName <source-resource-group-name>).Id

- ```

-1. Export the source virtual network to a .json file in the directory where you execute the command [Export-AzResourceGroup](/powershell/module/az.resources/export-azresourcegroup):

-

- ```azurepowershell-interactive

- Export-AzResourceGroup -ResourceGroupName <source-resource-group-name> -Resource $sourceVNETID -IncludeParameterDefaultValue

- ```

-1. The downloaded file has the same name as the resource group that the resource was exported from. Locate the *\<resource-group-name>.json* file, which you exported with the command, and then open it in your editor:

-

- ```azurepowershell

- notepad <source-resource-group-name>.json

- ```

-1. To edit the parameter of the virtual network name, change the **defaultValue** property of the source virtual network name to the name of your target virtual network. Be sure to enclose the name in quotation marks.

-

- ```json

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentmyResourceGroupVNET.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "virtualNetworks_myVNET1_name": {

- "defaultValue": "<target-virtual-network-name>",

- "type": "String"

- }

- ```

-1. To edit the target region where the virtual network will be moved, change the **location** property under resources:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/virtualNetworks",

- "apiVersion": "2019-06-01",

- "name": "[parameters('virtualNetworks_myVNET1_name')]",

- "location": "<target-region>",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",

- "addressSpace": {

- "addressPrefixes": [

- "10.0.0.0/16"

- ]

- },

- ```

-

-1. To obtain region location codes, you can use the Azure PowerShell cmdlet [Get-AzLocation](/powershell/module/az.resources/get-azlocation) by running the following command:

- ```azurepowershell-interactive

- Get-AzLocation | format-table

- ```

-1. (Optional) You can also change other parameters in the *\<resource-group-name>.json* file, depending on your requirements:

- * **Address Space**: Before you save the file, you can alter the address space of the virtual network by modifying the **resources** > **addressSpace** section and changing the **addressPrefixes** property:

- ```json

- "resources": [

- {

- "type": "Microsoft.Network/virtualNetworks",

- "apiVersion": "2019-06-01",

- "name": "[parameters('virtualNetworks_myVNET1_name')]",

- "location": "<target-region",

- "properties": {

- "provisioningState": "Succeeded",

- "resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",

- "addressSpace": {

- "addressPrefixes": [

- "10.0.0.0/16"

- ]

- },

- ```

- * **Subnet**: You can change or add to the subnet name and the subnet address space by changing the file's **subnets** section. You can change the name of the subnet by changing the **name** property. And you can change the subnet address space by changing the **addressPrefix** property:

- ```json

- "subnets": [

- {

- "name": "subnet-1",

- "etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.0.0/24",

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- },

- {

- "name": "GatewaySubnet",

- "etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.1.0/29",

- "serviceEndpoints": [],

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- }

- ]

- ```

- To change the address prefix, edit the file in two places: in the code in the preceding section and in the **type** section of the following code. Change the **addressPrefix** property in the following code to match the **addressPrefix** property in the code in the preceding section.

- ```json

- "type": "Microsoft.Network/virtualNetworks/subnets",

- "apiVersion": "2019-06-01",

- "name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/GatewaySubnet')]",

- "dependsOn": [

- "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_myVNET1_name'))]"

- ],

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.1.0/29",

- "serviceEndpoints": [],

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- },

- {

- "type": "Microsoft.Network/virtualNetworks/subnets",

- "apiVersion": "2019-06-01",

- "name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/subnet-1')]",

- "dependsOn": [

- "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_myVNET1_name'))]"

- ],

- "properties": {

- "provisioningState": "Succeeded",

- "addressPrefix": "10.0.0.0/24",

- "delegations": [],

- "privateEndpointNetworkPolicies": "Enabled",

- "privateLinkServiceNetworkPolicies": "Enabled"

- }

- }

- ]

- ```

-1. Save the *\<resource-group-name>.json* file.

-1. Create a resource group in the target region for the target virtual network to be deployed by using [New-AzResourceGroup](/powershell/module/az.resources/new-azresourcegroup):

-

- ```azurepowershell-interactive

- New-AzResourceGroup -Name <target-resource-group-name> -location <target-region>

- ```

-

-1. Deploy the edited *\<resource-group-name>.json* file to the resource group that you created in the previous step by using [New-AzResourceGroupDeployment](/powershell/module/az.resources/new-azresourcegroupdeployment):

- ```azurepowershell-interactive

- New-AzResourceGroupDeployment -ResourceGroupName <target-resource-group-name> -TemplateFile <source-resource-group-name>.json

- ```

-1. To verify that the resources were created in the target region, use [Get-AzResourceGroup](/powershell/module/az.resources/get-azresourcegroup) and [Get-AzVirtualNetwork](/powershell/module/az.network/get-azvirtualnetwork):

-

- ```azurepowershell-interactive

- Get-AzResourceGroup -Name <target-resource-group-name>

- ```

- ```azurepowershell-interactive

- Get-AzVirtualNetwork -Name <target-virtual-network-name> -ResourceGroupName <target-resource-group-name>

- ```

-## Delete the virtual network or resource group

-After you've deployed the virtual network, to start over or discard the virtual network in the target region, delete the resource group that you created in the target region, and the moved virtual network will be deleted.

-To remove the resource group, use [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup):

-```azurepowershell-interactive

-Remove-AzResourceGroup -Name <target-resource-group-name>

-```

-## Clean up

-To commit your changes and complete the virtual network move, do either of the following:

-* Delete the resource group by using [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup):

- ```azurepowershell-interactive

- Remove-AzResourceGroup -Name <source-resource-group-name>

- ```

-* Delete the source virtual network by using [Remove-AzVirtualNetwork](/powershell/module/az.network/remove-azvirtualnetwork):

- ``` azurepowershell-interactive

- Remove-AzVirtualNetwork -Name <source-virtual-network-name> -ResourceGroupName <source-resource-group-name>

- ```

-## Next steps

-In this tutorial, you moved a virtual network from one region to another by using PowerShell and then cleaned up the unneeded source resources. To learn more about moving resources between regions and disaster recovery in Azure, see:

-description: Create a virtual network for multi-tier applications - Azure PowerShell script sample.

-# Create a network for multi-tier applications script sample

-This script sample creates a virtual network with front-end and back-end subnets. Traffic to the front-end subnet is limited to HTTP and SSH, while traffic to the back-end subnet is limited to MySQL, port 3306. After running the script, you'll have two virtual machines, one in each subnet that you can deploy web server and MySQL software to.

-You can execute the script from the Azure [Cloud Shell](https://shell.azure.com/powershell), or from a local PowerShell installation. If you use PowerShell locally, this script requires the Azure PowerShell module version 1.0.0 or later. To find the installed version, run `Get-Module -ListAvailable Az`. If you need to upgrade, see [Install Azure PowerShell module](/powershell/azure/install-azure-powershell). If you're running PowerShell locally, you also need to run `Connect-AzAccount` to create a connection with Azure.

-## Sample script

-A subnet ID is assigned after you've created a virtual network; specifically, using the New-AzVirtualNetwork cmdlet with the -Subnet option. If you configure the subnet using the New-AzVirtualNetworkSubnetConfig cmdlet before the call to New-AzVirtualNetwork, you won't see the subnet ID until after you call New-AzVirtualNetwork.

-[!code-azurepowershell-interactive [main](../../../powershell_scripts/virtual-network/virtual-network-multi-tier-application/virtual-network-multi-tier-application.ps1 "Virtual network for multi-tier application")]

-## Clean up deployment

-Run the following command to remove the resource group, VM, and all related resources:

-```powershell

-Remove-AzResourceGroup -Name myResourceGroup -Force

-```

-## Script explanation

-This script uses the following commands to create a resource group, virtual network, and network security groups. Each command in the following table links to command-specific documentation:

-| Command | Notes |

-|||

-| [New-AzResourceGroup](/powershell/module/az.resources/new-azresourcegroup) | Creates a resource group in which all resources are stored. |

-| [New-AzVirtualNetwork](/powershell/module/az.network/new-azvirtualnetwork) | Creates an Azure virtual network and front-end subnet. |

-| [New-AzVirtualNetworkSubnetConfig](/powershell/module/az.network/new-azvirtualnetworksubnetconfig) | Creates a back-end subnet. |

-| [New-AzPublicIpAddress](/powershell/module/az.network/new-azpublicipaddress) | Creates a public IP address to access the VM from the internet. |

-| [New-AzNetworkInterface](/powershell/module/az.network/new-aznetworkinterface) | Creates virtual network interfaces and attaches them to the virtual network's front-end and back-end subnets. |

-| [New-AzNetworkSecurityGroup](/powershell/module/az.network/new-aznetworksecuritygroup) | Creates network security groups (NSG) that are associated to the front-end and back-end subnets. |

-| [New-AzNetworkSecurityRuleConfig](/powershell/module/az.network/new-aznetworksecurityruleconfig) |Creates NSG rules that allow or block specific ports to specific subnets. |

-| [New-AzVM](/powershell/module/az.compute/new-azvm) | Creates virtual machines and attaches a NIC to each VM. This command also specifies the virtual machine image to use and administrative credentials. |

-| [Remove-AzResourceGroup](/powershell/module/az.resources/remove-azresourcegroup) | Deletes a resource group and all resources it contains. |

-## Next steps

-For more information on the Azure PowerShell, see [Azure PowerShell documentation](/powershell/azure/).

-More virtual network PowerShell script samples can be found in [Virtual network PowerShell samples](../powershell-samples.md).

-A virtual hub can contain multiple gateways such as a site-to-site VPN gateway, ExpressRoute gateway, point-to-site gateway, and Azure Firewall. The routing capabilities in the virtual hub are provided by a router that manages all routing, including transit routing, between the gateways using Border Gateway Protocol (BGP). The virtual hub router also provides transit connectivity between virtual networks that connect to a virtual hub and can support up to an aggregate throughput of 50 Gbps. These routing capabilities apply to customers using **Standard** Virtual WANs. For more information, see [About virtual hub routing](about-virtual-hub-routing.md).

-1. In the Azure portal, navigate to the **virtual hub**.

-1. On the **Virtual HUB** page, in the left pane, select **Route Tables**. The **Route Tables** page will populate the current route tables for this hub.

-1. On the **Basics** page, complete the following fields, then click **Labels** to move to the Labels page.

-In the Azure portal, go to your **Virtual HUB -> Route Tables** page. To open the **Edit route table page**, click the name of the route table you want to edit. Edit the values you want to change, then click **Review + create** or **Create** (depending on the page that you are on) to save your settings.

-In the Azure portal, go to your **Virtual HUB -> Route Tables** page. Select the checkbox for route table that you want to delete. Click **"…"**, and then select **Delete**. You can't delete a Default or None route table. However, you can delete all custom route tables.