+> Document Intelligence Studio query field extraction is currently available with the Layout and Prebuilt models starting with the `2023-10-31-preview` API and later releases except for the ```us.tax.*``` models (W2, 1098s and 1099s models).

+Use of the shared quota pool is available for testing inferencing for Llama-2, Phi, Nemotron, Mistral, Dolly and Deci-DeciLM models from the Model Catalog. You should use the shared quota only for creating temporary test endpoints, not production endpoints. For endpoints in production, you should [request dedicated quota](#view-and-request-quotas-in-the-studio). Billing for shared quota is usage-based, just like billing for dedicated virtual machine families.

+# Set up a custom domain name and SSL certificate with the application routing add-on

+* Integration with an external DNS such as [Azure DNS][azure-dns-overview] for global and private zone management

+- Azure DNS if you want to configure global and private zone management and host them in Azure.

+* The app routing add-on can be configured to automatically create records on one or more Azure global and private DNS zones for hosts defined on Ingress resources. All global Azure DNS zones need to be in the same resource group, and all private Azure DNS zones need to be in the same resource group. If you don't have an Azure DNS zone, you can [create one][create-an-azure-dns-zone].

+ Title: Advanced ingress and NGINX ingress controller configuration

+description: Understand the advanced configuration options that are supported with the application routing add-on with the NGINX ingress controller for Azure Kubernetes Service.

+# Advanced NGINX ingress controller and ingress configurations with the application routing add-on

+The application routing add-on supports two ways to configure ingress controllers and ingress objects:

+- [Configuration of the NGINX ingress controller](#configuration-of-the-nginx-ingress-controller) such as creating multiple controllers, configuring private load balancers, and setting static IP addresses.

+- [Configuration per ingress resource](#configuration-per-ingress-resource-through-annotations) through annotations.

+## Prerequisites

+An AKS cluster with the [application routing add-on][app-routing-add-on-basic-configuration].

+## Connect to your AKS cluster

+To connect to the Kubernetes cluster from your local computer, you use `kubectl`, the Kubernetes command-line client. You can install it locally using the [az aks install-cli][az-aks-install-cli] command. If you use the Azure Cloud Shell, `kubectl` is already installed.

+Configure kubectl to connect to your Kubernetes cluster using the [`az aks get-credentials`][az-aks-get-credentials] command.

+```azurecli-interactive

+az aks get-credentials -g <ResourceGroupName> -n <ClusterName>

+```

+## Configuration of the NGINX ingress controller

+The application routing add-on uses a Kubernetes [custom resource definition (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) called [`NginxIngressController`](https://github.com/Azure/aks-app-routing-operator/blob/main/config/crd/bases/approuting.kubernetes.azure.com_nginxingresscontrollers.yaml) to configure NGINX ingress controllers. You can create more ingress controllers or modify existing configuration.

+`NginxIngressController` CRD has a `loadBalancerAnnotations` field to control the behavior of the NGINX ingress controller's service by setting [load balancer annotations](load-balancer-standard.md#customizations-via-kubernetes-annotations).

+### The default NGINX ingress controller

+When you enable the application routing add-on with NGINX, it creates an ingress controller called `default` in the `app-routing-namespace` configured with a public facing Azure load balancer. That ingress controller uses an ingress class name of `webapprouting.kubernetes.azure.com`.

+You can modify the configuration of the default ingress controller by editing its configuration.

+```bash

+kubectl edit nginxingresscontroller default -n app-routing-system

+```

+### Create another public facing NGINX ingress controller

+To create another NGINX ingress controller with a public facing Azure Load Balancer:

+1. Copy the following YAML manifest into a new file named **nginx-public-controller.yaml** and save the file to your local computer.

+ ```yml

+ apiVersion: approuting.kubernetes.azure.com/v1alpha1

+ kind: NginxIngressController

+ metadata:

+ name: nginx-public

+ spec:

+ ingressClassName: nginx-public

+ controllerNamePrefix: nginx-public

+ ```

+1. Create the NGINX ingress controller resources using the [`kubectl apply`][kubectl-apply] command.

+ ```bash

+ kubectl apply -f nginx-public-controller.yaml

+ ```

+ The following example output shows the created resource:

+ ```output

+ nginxingresscontroller.approuting.kubernetes.azure.com/nginx-public created

+ ```

+### Create an internal NGINX ingress controller with a private IP address

+To create an NGINX ingress controller with an internal facing Azure Load Balancer with a private IP address:

+1. Copy the following YAML manifest into a new file named **nginx-internal-controller.yaml** and save the file to your local computer.

+ ```yml

+ apiVersion: approuting.kubernetes.azure.com/v1alpha1

+ kind: NginxIngressController

+ metadata:

+ name: nginx-internal

+ spec:

+ ingressClassName: nginx-internal

+ controllerNamePrefix: nginx-internal

+ loadBalancerAnnotations:

+ service.beta.kubernetes.io/azure-load-balancer-internal: "true"

+ ```

+1. Create the NGINX ingress controller resources using the [`kubectl apply`][kubectl-apply] command.

+ ```bash

+ kubectl apply -f nginx-internal-controller.yaml

+ ```

+ The following example output shows the created resource:

+ ```output

+ nginxingresscontroller.approuting.kubernetes.azure.com/nginx-internal created

+ ```

+### Create an NGINX ingress controller with a static IP address

+To create an NGINX ingress controller with a static IP address on the Azure Load Balancer:

+1. Create an Azure resource group using the [`az group create`][az-group-create] command.

+ ```azurecli-interactive

+ az group create --name myNetworkResourceGroup --location eastus

+ ```

+1. Create a static public IP address using the [`az network public ip create`][az-network-public-ip-create] command.

+ ```azurecli-interactive

+ az network public-ip create \

+ --resource-group myNetworkResourceGroup \

+ --name myIngressPublicIP \

+ --sku Standard \

+ --allocation-method static

+ ```

+ > [!NOTE]

+ > If you're using a *Basic* SKU load balancer in your AKS cluster, use *Basic* for the `--sku` parameter when defining a public IP. Only *Basic* SKU IPs work with the *Basic* SKU load balancer and only *Standard* SKU IPs work with *Standard* SKU load balancers.

+1. Ensure the cluster identity used by the AKS cluster has delegated permissions to the public IP's resource group using the [`az role assignment create`][az-role-assignment-create] command.

+ > [!NOTE]

+ > Update *`<ClusterName>`* and *`<ClusterResourceGroup>`* with your AKS cluster's name and resource group name.

+ ```azurecli-interactive

+ CLIENT_ID=$(az aks show --name <ClusterName> --resource-group <ClusterResourceGroup> --query identity.principalId -o tsv)

+ RG_SCOPE=$(az group show --name myNetworkResourceGroup --query id -o tsv)

+ az role assignment create \

+ --assignee ${CLIENT_ID} \

+ --role "Network Contributor" \

+ --scope ${RG_SCOPE}

+ ```

+1. Copy the following YAML manifest into a new file named **nginx-staticip-controller.yaml** and save the file to your local computer.

+ > [!NOTE]

+ > You can either use `service.beta.kubernetes.io/azure-pip-name` for public IP name, or use `service.beta.kubernetes.io/azure-load-balancer-ipv4` for an IPv4 address and `service.beta.kubernetes.io/azure-load-balancer-ipv6` for an IPv6 address, as shown in the example YAML. Adding the `service.beta.kubernetes.io/azure-pip-name` annotation ensures the most efficient LoadBalancer creation and is highly recommended to avoid potential throttling.

+ ```yml

+ apiVersion: approuting.kubernetes.azure.com/v1alpha1

+ kind: NginxIngressController

+ metadata:

+ name: nginx-static

+ spec:

+ ingressClassName: nginx-static

+ controllerNamePrefix: nginx-static

+ loadBalancerAnnotations:

+ service.beta.kubernetes.io/azure-pip-name: "myIngressPublicIP"

+ service.beta.kubernetes.io/azure-load-balancer-resource-group: "myNetworkResourceGroup"

+ ```

+1. Create the NGINX ingress controller resources using the [`kubectl apply`][kubectl-apply] command.

+ ```bash

+ kubectl apply -f nginx-staticip-controller.yaml

+ ```

+ The following example output shows the created resource:

+ ```output

+ nginxingresscontroller.approuting.kubernetes.azure.com/nginx-static created

+ ```

+### Verify the ingress controller was created

+You can verify the status of the NGINX ingress controller using the [`kubectl get nginxingresscontroller`][kubectl-get] command.

+> [!NOTE]

+> Update *`<IngressControllerName>`* with name you used when creating the `NginxIngressController``.

+```bash

+kubectl get nginxingresscontroller -n <IngressControllerName>

+```

+The following example output shows the created resource. It may take a few minutes for the controller to be available:

+```output

+NAME INGRESSCLASS CONTROLLERNAMEPREFIX AVAILABLE

+nginx-public nginx-public nginx True

+```

+You can also view the conditions to troubleshoot any issues:

+```bash

+kubectl get nginxingresscontroller -n <IngressControllerName> -o jsonpath='{range .items[*].status.conditions[*]}{.lastTransitionTime}{"\t"}{.status}{"\t"}{.type}{"\t"}{.message}{"\n"}{end}'

+```

+The following example output shows the conditions of a healthy ingress controller:

+```output

+2023-11-29T19:59:24Z True IngressClassReady Ingress Class is up-to-date

+2023-11-29T19:59:50Z True Available Controller Deployment has minimum availability and IngressClass is up-to-date

+2023-11-29T19:59:50Z True ControllerAvailable Controller Deployment is available

+2023-11-29T19:59:25Z True Progressing Controller Deployment has successfully progressed

+```

+### Use the ingress controller in an ingress

+1. Copy the following YAML manifest into a new file named **ingress.yaml** and save the file to your local computer.

+ > [!NOTE]

+ > Update *`<Hostname>`* with your DNS host name.

+ > The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+ ```yml

+ apiVersion: networking.k8s.io/v1

+ kind: Ingress

+ metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - backend:

+ service:

+ name: aks-helloworld

+ port:

+ number: 80

+ path: /

+ pathType: Prefix

+ ```

+3. Create the cluster resources using the [`kubectl apply`][kubectl-apply] command.

+ ```bash

+ kubectl apply -f ingress.yaml -n hello-web-app-routing

+ ```

+ The following example output shows the created resource:

+ ```output

+ ingress.networking.k8s.io/aks-helloworld created

+ ```

+### Verify the managed Ingress was created

+You can verify the managed Ingress was created using the [`kubectl get ingress`][kubectl-get] command.

+```bash

+kubectl get ingress -n hello-web-app-routing

+```

+The following example output shows the created managed Ingress. The ingress class, host and IP address may be different:

+```output

+NAME CLASS HOSTS ADDRESS PORTS AGE

+aks-helloworld webapprouting.kubernetes.azure.com myapp.contoso.com 20.51.92.19 80, 443 4m

+```

+### Clean up of ingress controllers

+You can remove the NGINX ingress controller using the [`kubectl delete nginxingresscontroller`][kubectl-delete] command.

+> [!NOTE]

+> Update *`<IngressControllerName>`* with name you used when creating the `NginxIngressController`.

+```bash

+kubectl delete nginxingresscontroller -n <IngressControllerName>

+```

+## Configuration per ingress resource through annotations

+The NGINX ingress controller supports adding [annotations to specific Ingress objects](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/) to customize their behavior.

+You can [annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) the ingress object by adding the respective annotation in the `metadata.annotations` field.

+> [!NOTE]

+> Annotation keys and values can only be strings. Other types, such as boolean or numeric values must be quoted, i.e. `"true"`, `"false"`, `"100"`.

+Here are some examples annotations for common configurations. Review the [NGINX ingress annotations documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/) for a full list.

+### Custom max body size

+For NGINX, a 413 error is returned to the client when the size in a request exceeds the maximum allowed size of the client request body. To override the default value, use the annotation:

+```yml

+nginx.ingress.kubernetes.io/proxy-body-size: 4m

+```

+Here's an example ingress configuration using this annotation:

+> [!NOTE]

+> Update *`<Hostname>`* with your DNS host name.

+> The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+```yml

+apiVersion: networking.k8s.io/v1

+kind: Ingress

+metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ annotations:

+ nginx.ingress.kubernetes.io/proxy-body-size: 4m

+spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - backend:

+ service:

+ name: aks-helloworld

+ port:

+ number: 80

+ path: /

+ pathType: Prefix

+```

+### Custom connection timeout

+You can change the timeout that the NGINX ingress controller waits to close a connection with your workload. All timeout values are unitless and in seconds. To override the default timeout, use the following annotation to set a valid 120-seconds proxy read timeout:

+```yml

+nginx.ingress.kubernetes.io/proxy-read-timeout: "120"

+```

+Review [custom timeouts](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#custom-timeouts) for other configuration options.

+Here's an example ingress configuration using this annotation:

+> [!NOTE]

+> Update *`<Hostname>`* with your DNS host name.

+> The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+```yml

+apiVersion: networking.k8s.io/v1

+kind: Ingress

+metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ annotations:

+ nginx.ingress.kubernetes.io/proxy-read-timeout: "120"

+spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - backend:

+ service:

+ name: aks-helloworld

+ port:

+ number: 80

+ path: /

+ pathType: Prefix

+```

+### Backend protocol

+By default the NGINX ingress controller uses `HTTP` to reach the services. To configure alternative backend protocols such as `HTTPS` or `GRPC`, use the annotation:

+```yml

+nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

+```

+or

+```yml

+nginx.ingress.kubernetes.io/backend-protocol: "GRPC"

+```

+Review [backend protocols](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#backend-protocol) for other configuration options.

+Here's an example ingress configuration using this annotation:

+> [!NOTE]

+> Update *`<Hostname>`* with your DNS host name.

+> The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+```yml

+apiVersion: networking.k8s.io/v1

+kind: Ingress

+metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ annotations:

+ nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

+spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - backend:

+ service:

+ name: aks-helloworld

+ port:

+ number: 80

+ path: /

+ pathType: Prefix

+```

+### Cross-Origin Resource Sharing (CORS)

+To enable Cross-Origin Resource Sharing (CORS) in an Ingress rule, use the annotation:

+```yml

+nginx.ingress.kubernetes.io/enable-cors: "true"

+```

+Review [enable CORS](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors) for other configuration options.

+Here's an example ingress configuration using this annotation:

+> [!NOTE]

+> Update *`<Hostname>`* with your DNS host name.

+> The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+```yml

+apiVersion: networking.k8s.io/v1

+kind: Ingress

+metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ annotations:

+ nginx.ingress.kubernetes.io/enable-cors: "true"

+spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - backend:

+ service:

+ name: aks-helloworld

+ port:

+ number: 80

+ path: /

+ pathType: Prefix

+```

+### Disable SSL redirect

+By default the controller redirects (308) to HTTPS if TLS is enabled for an ingress. To disable this feature for specific ingress resources, use the annotation:

+```yml

+nginx.ingress.kubernetes.io/ssl-redirect: "false"

+```

+Review [server-side HTTPS enforcement through redirect](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-side-https-enforcement-through-redirect) for other configuration options.

+Here's an example ingress configuration using this annotation:

+> [!NOTE]

+> Update *`<Hostname>`* with your DNS host name.

+> The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+```yml

+apiVersion: networking.k8s.io/v1

+kind: Ingress

+metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ annotations:

+ nginx.ingress.kubernetes.io/ssl-redirect: "false"

+spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - backend:

+ service:

+ name: aks-helloworld

+ port:

+ number: 80

+ path: /

+ pathType: Prefix

+```

+### URL rewriting

+In some scenarios, the exposed URL in the backend service differs from the specified path in the Ingress rule. Without a rewrite any request returns 404. This is particularly useful with [path based routing](https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/) where you can serve two different web applications under the same domain. You can set path expected by the service using the annotation:

+```yml

+nginx.ingress.kubernetes.io/rewrite-target": /$2

+```

+Here's an example ingress configuration using this annotation:

+> [!NOTE]

+> Update *`<Hostname>`* with your DNS host name.

+> The *`<IngressClassName>`* is the one you defined when creating the `NginxIngressController`.

+```yml

+apiVersion: networking.k8s.io/v1

+kind: Ingress

+metadata:

+ name: aks-helloworld

+ namespace: hello-web-app-routing

+ annotations:

+ nginx.ingress.kubernetes.io/rewrite-target: /$2

+ nginx.ingress.kubernetes.io/use-regex: "true"

+spec:

+ ingressClassName: <IngressClassName>

+ rules:

+ - host: <Hostname>

+ http:

+ paths:

+ - path: /app-one(/|$)(.*)

+ pathType: Prefix

+ backend:

+ service:

+ name: app-one

+ port:

+ number: 80

+ - path: /app-two(/|$)(.*)

+ pathType: Prefix

+ backend:

+ service:

+ name: app-two

+ port:

+ number: 80

+```

+## Next steps

+Learn about monitoring the ingress-nginx controller metrics included with the application routing add-on with [with Prometheus in Grafana][prometheus-in-grafana] as part of analyzing the performance and usage of your application.

+<!-- LINKS - external -->

+[kubectl-apply]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply

+[kubectl-get]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get

+[kubectl-delete]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete

+<!-- LINKS - internal -->

+[az-network-public-ip-create]: /cli/azure/network/public-ip#az_network_public_ip_create

+[az-network-public-ip-list]: /cli/azure/network/public-ip#az_network_public_ip_list

+[az-group-create]: /cli/azure/group#az-group-create

+[summary-msi]: use-managed-identity.md#summary-of-managed-identities

+[rbac-owner]: ../role-based-access-control/built-in-roles.md#owner

+[rbac-classic]: ../role-based-access-control/rbac-and-directory-admin-roles.md#classic-subscription-administrator-roles

+[app-routing-add-on-basic-configuration]: app-routing.md

+[csi-secrets-store-autorotation]: csi-secrets-store-configuration-options.md#enable-and-disable-auto-rotation

+[azure-key-vault-overview]: ../key-vault/general/overview.md

+[az-aks-approuting-update]: /cli/azure/aks/approuting#az-aks-approuting-update

+[az-aks-approuting-zone]: /cli/azure/aks/approuting/zone

+[az-network-dns-zone-show]: /cli/azure/network/dns/zone#az-network-dns-zone-show

+[az-network-dns-zone-create]: /cli/azure/network/dns/zone#az-network-dns-zone-create

+[az-keyvault-certificate-import]: /cli/azure/keyvault/certificate#az-keyvault-certificate-import

+[az-keyvault-create]: /cli/azure/keyvault#az-keyvault-create

+[authorization-systems]: ../key-vault/general/rbac-access-policy.md

+[az-aks-install-cli]: /cli/azure/aks#az-aks-install-cli

+[az-aks-get-credentials]: /cli/azure/aks#az-aks-get-credentials

+[create-and-export-a-self-signed-ssl-certificate]: #create-and-export-a-self-signed-ssl-certificate

+[create-an-azure-dns-zone]: #create-a-global-azure-dns-zone

+[azure-dns-overview]: ../dns/dns-overview.md

+[az-keyvault-certificate-show]: /cli/azure/keyvault/certificate#az-keyvault-certificate-show

+[prometheus-in-grafana]: app-routing-nginx-prometheus.md

+For other configuration information related to SSL encryption and DNS integration, review [DNS and SSL configuration][dns-ssl-configuration] and [application routing add-on configuration][custom-ingress-configurations].

+- All global Azure DNS zones integrated with the add-on have to be in the same resource group.

+* [Configure custom ingress configurations][custom-ingress-configurations] shows how to create an advanced Ingress configuration and [configure a custom domain using Azure DNS to manage DNS zones and setup a secure ingress][dns-ssl-configuration].

+[dns-ssl-configuration]: app-routing-dns-ssl.md

+[custom-ingress-configurations]: app-routing-nginx-configuration.md

+Sharing data between containers is often a necessary component of container-based services and applications. You usually have various pods that need access to the same information on an external persistent volume. While [Azure Files][azure-files-overview] is an option, creating an NFS Server on an Azure VM is another form of persistent shared storage.

+This article assumes that you have the following to support this configuration:

+* An existing AKS cluster. If you don't have an AKS cluster, for guidance on a designing an enterprise-scale implementation of AKS, see [Plan your AKS design][plan-aks-design].

+If you deploy your AKS cluster first, Azure automatically populates the virtual network settings when deploying your Azure Ubuntu VM, associating the Ubuntu VM on the same VNet. If you want to work with peered networks instead, consult the documentation above.

+1. To deploy an NFS Server on the Azure Ubuntu virtual machine, copy the following Bash script and save it to your local machine. Replace the value for the variable **AKS_SUBNET** with the correct one from your AKS cluster, otherwise the default value specified opens your NFS Server to all ports and connections. In this article, the file is named `nfs-server-setup.sh`.

+You can connect to the NFS Server from your AKS cluster by provisioning a persistent volume and persistent volume claim that specifies how to access the volume. Connecting the two resources in the same or peered virtual networks is necessary. To learn how to set up the cluster in the same VNet, see: [Creating AKS Cluster in existing VNet][aks-virtual-network].

+Once both resources are on the same virtual or peered VNet, provision a persistent volume and a persistent volume claim in your AKS Cluster. The containers can then mount the NFS drive to their local directory.

+1. Create a YAML manifest named *pv-azurefilesnfs.yaml* with a *PersistentVolume*. For example:

+2. Create a YAML manifest named *pvc-azurefilesnfs.yaml* with a *PersistentVolumeClaim* that uses the *PersistentVolume*. For example:

+Check that both your export directory and its parent directory are granted 777 permissions.

+[plan-aks-design]: /azure/architecture/reference-architectures/containers/aks-start-here?toc=/azure/aks/toc.json&bc=/azure/aks/breadcrumb/toc.json

+[azure-files-overview]: ../storage/files/storage-files-introduction.md

+This article assumes that you have an existing AKS cluster. If you don't have an AKS cluster, for guidance on a designing an enterprise-scale implementation of AKS, see [Plan your AKS design][plan-aks-design].

+[plan-aks-design]: /azure/architecture/reference-architectures/containers/aks-start-here?toc=/azure/aks/toc.json&bc=/azure/aks/breadcrumb/toc.json

+Your AKS cluster has regular maintenance performed on it automatically. There are two types of regular maintenance - AKS initiated and those that you initiate. Planned Maintenance feature allows you to run both types of maintenance in a cadence of your choice, thereby minimizing any workload impact.

+This article describes the maintenance options availble and how to configure a maintenance schedule for your AKS clusters.

+## Overview

+There are currently three available maintenance schedule configuration types: `default`, `aksManagedAutoUpgradeSchedule`, `aksManagedNodeOSUpgradeSchedule`:

+We recommend using `aksManagedAutoUpgradeSchedule` for all cluster upgrade scenarios and `aksManagedNodeOSUpgradeSchedule` for all node OS security patching scenarios. The `default` option is meant exclusively for AKS weekly releases. You can switch the `default` configuration to the `aksManagedAutoUpgradeSchedule` or `aksManagedNodeOSUpgradeSchedule` configurations using the `az aks maintenanceconfiguration update` command.

+This article assumes that you have an existing AKS cluster. If you don't have an AKS cluster, for guidance on a designing an enterprise-scale implementation of AKS, see [Plan your AKS design][plan-aks-design].

+To create a maintenance window, you can use the `az aks maintenanceconfiguration add` command using the `--name` value `default`, `aksManagedAutoUpgradeSchedule`, or `aksManagedNodeOSUpgradeSchedule`. The name value should reflect the desired configuration type. Using any other name prevents your maintenance window from running.

+[plan-aks-design]: /azure/architecture/reference-architectures/containers/aks-start-here?toc=/azure/aks/toc.json&bc=/azure/aks/breadcrumb/toc.json

+This article assumes that you have an existing AKS cluster. If you don't have an AKS cluster, for guidance on a designing an enterprise-scale implementation of AKS, see [Plan your AKS design][plan-aks-design].

+[plan-aks-design]: /azure/architecture/reference-architectures/containers/aks-start-here?toc=/azure/aks/toc.json&bc=/azure/aks/breadcrumb/toc.json

+| 1.25 | Azure policy 1.0.1<br>Metrics-Server 0.6.3<br>KEDA 2.9.3<br>Open Service Mesh 1.2.3<br>Core DNS V1.9.4<br>Overlay VPA 0.11.0<br>Azure-Keyvault-SecretsProvider 1.4.1<br>Application Gateway Ingress Controller (AGIC) 1.5.3<br>Image Cleaner v1.1.1<br>Azure Workload identity v1.0.0<br>MDC Defender 1.0.56<br>Azure Active Directory Pod Identity 1.8.13.6<br>GitOps 1.7.0<br>KMS 0.5.0| Cilium 1.12.8<br>CNI 1.4.44<br> Cluster Autoscaler 1.8.5.3<br> | OS Image Ubuntu 18.04 Cgroups V1 <br>ContainerD 1.7<br>Azure Linux 2.0<br>Cgroups V1<br>ContainerD 1.6<br>| Ubuntu 22.04 by default with cgroupv2 and Overlay VPA 0.13.0 |CgroupsV2 - If you deploy Java applications with the JDK, prefer to use JDK 11.0.16 and later or JDK 15 and later, which fully support cgroup v2

+| 1.26 | Azure policy 1.0.1<br>Metrics-Server 0.6.3<br>KEDA 2.9.3<br>Open Service Mesh 1.2.3<br>Core DNS V1.9.4<br>Overlay VPA 0.11.0<br>Azure-Keyvault-SecretsProvider 1.4.1<br>Application Gateway Ingress Controller (AGIC) 1.5.3<br>Image Cleaner v1.1.1<br>Azure Workload identity v1.0.0<br>MDC Defender 1.0.56<br>Azure Active Directory Pod Identity 1.8.13.6<br>GitOps 1.7.0<br>KMS 0.5.0| Cilium 1.12.8<br>CNI 1.4.44<br> Cluster Autoscaler 1.8.5.3<br> | OS Image Ubuntu 22.04 Cgroups V2 <br>ContainerD 1.7<br>Azure Linux 2.0<br>Cgroups V1<br>ContainerD 1.6<br>|No breaking changes |None

+| 1.27 | Azure policy 1.1.0<br>Metrics-Server 0.6.3<br>KEDA 2.10.0<br>Open Service Mesh 1.2.3<br>Core DNS V1.9.4<br>Overlay VPA 0.11.0<br>Azure-Keyvault-SecretsProvider 1.4.1<br>Application Gateway Ingress Controller (AGIC) 1.7.2<br>Image Cleaner v1.1.1<br>Azure Workload identity v1.0.0<br>MDC Defender 1.0.56<br>Azure Active Directory Pod Identity 1.8.13.6<br>GitOps 1.7.0<br>KMS 0.5.0|Cilium 1.12.8<br>CNI 1.4.44<br> Cluster Autoscaler 1.8.5.3<br> | OS Image Ubuntu 22.04 Cgroups V2 <br>ContainerD 1.7 for Linux and 1.6 for Windows<br>Azure Linux 2.0<br>Cgroups V1<br>ContainerD 1.6<br>|Keda 2.10.0 |Because of Ubuntu 22.04 FIPS certification status, we'll switch AKS FIPS nodes from 18.04 to 20.04 from 1.27 onwards.

+| 1.28 | Azure policy 1.2.1<br>Metrics-Server 0.6.3<br>KEDA 2.11.2<br>Open Service Mesh 1.2.7<br>Core DNS V1.9.4<br>Overlay VPA 0.13.0<br>Azure-Keyvault-SecretsProvider 1.4.1<br>Application Gateway Ingress Controller (AGIC) 1.7.2<br>Image Cleaner v1.2.2<br>Azure Workload identity v1.2.0<br>MDC Defender Security Publisher 1.0.68<br>MDC Defender Old File Cleaner 1.3.68<br>MDC Defender Pod Collector 1.0.78<br>MDC Defender Low Level Collector 1.3.81<br>Azure Active Directory Pod Identity 1.8.13.6<br>GitOps 1.8.1|Cilium 1.13.5<br>CNI v1.4.43.1 (Default)/v1.5.11 (Azure CNI Overlay)<br> Cluster Autoscaler 1.27.3<br> | OS Image Ubuntu 22.04 Cgroups V2 <br>ContainerD 1.7.5 for Linux and 1.7.1 for Windows<br>Azure Linux 2.0<br>Cgroups V1<br>ContainerD 1.6<br>|No breaking changes|None

+ Title: Enable API Center portal - Azure API Center

+description: Enable the API Center portal, an automatically generated website that enables discovery of your API inventory.

+# Customer intent: As an API program manager, I want to enable a portal for developers and other API stakeholders in my organization to discover the APIs in my organization's API center.

+# Enable your API Center portal

+This article shows how to enable your *API Center portal*, an automatically generated website that developers and other stakeholders in your organization can use to discover the APIs in your [API center](overview.md). The portal is hosted by Azure at a unique URL and restricts user access based on Azure role-based access control.

+## Prerequisites

+* An API center in your Azure subscription. If you haven't created one already, see [Quickstart: Create your API center](set-up-api-center.md).

+* Permissions to create an app registration in a Microsoft Entra tenant associated with your Azure subscription, and permissions to grant access to data in your API center.

+## Create Microsoft Entra app registration

+First configure an app registration in your Microsoft Entra ID tenant. The app registration enables the API Center portal to access data from your API center on behalf of a signed-in user.

+1. In the [Azure portal](https://portal.azure.com), navigate to **Microsoft Entra ID** > **App registrations**.

+1. Select **+ New registration**.

+1. On the **Register an application** page, set the values as follows:

+

+ * Set **Name** to a meaningful name such as *api-center-portal*

+ * Under **Supported account types**, select **Accounts in this organizational directory (Single tenant)**.

+ * In **Redirect URI**, select **Single-page application (SPA)** and enter the following URI, substituting your API center name and region where indicated:

+ `https://<api-center-name>.portal.<region>.azure-apicenter.ms`

+ Example: `https://contoso.portal.westeurope.azure-apicenter.ms`

+ * Select **Register**.

+1. On the **Overview** page, copy the **Application (client) ID**. You use this value when you configure the identity provider for the portal in your API center.

+

+1. On the **API permissions** page, select **+ Add a permission**.

+ 1. On the **Request API permissions** page, select the **APIs my organization uses** tab. Search for and select **Azure API Center**.

+ 1. On the **Request permissions** page, select **user_impersonation**.

+ 1. Select **Add permissions**.

+ The Azure API Center permissions appear under **Configured permissions**.

+ :::image type="content" source="media/enable-api-center-portal/configure-app-permissions.png" alt-text="Screenshot of required permissions in Microsoft Entra ID app registration in the portal." lightbox="media/enable-api-center-portal/configure-app-permissions.png":::

+## Configure Microsoft Entra ID provider for API Center portal

+In your API center, configure the Microsoft Entra ID identity provider for the API Center portal.

+1. In the [Azure portal](https://portal.azure.com), navigate to your API center.

+1. In the left menu, under **API Center portal**, select **Portal settings**.

+1. Select **Identity provider** > **Start set up**.

+1. On the **Set up user sign-in with Microsoft Entra ID** page, in **Client ID**, enter the **Application (client) ID** of the app registration that you created in the previous section.

+ :::image type="content" source="media/enable-api-center-portal/set-up-sign-in-portal.png" alt-text="Screenshot of the Microsoft Entra ID provider settings in the API Center portal." lightbox="media/enable-api-center-portal/set-up-sign-in-portal.png":::

+1. Select **Save + publish**. The Microsoft Entra ID provider appears on the **Identity provider** page.

+1. To view the API Center portal, on the **Portal settings** page, select **View API Center portal**.

+The portal is published at the following URL that you can share with developers in your organization: `https://<api-center-name>.<region>.azure-apicenter.ms`.

+## Customize portal name

+By default, the name that appears on the upper left of the API Center portal is the name of your API center. You can customize this name.

+1. In the Azure portal, go to the **Portal settings** > **Site profile** page.

+1. Enter a new name in **Add a website name**.

+1. Select **Save + publish**.

+ :::image type="content" source="media/enable-api-center-portal/add-website-name.png" alt-text="Screenshot of adding a custom website name in the Azure portal.":::

+ The new name appears after you refresh the API Center portal.

+## Enable sign-in to portal by Microsoft Entra users and groups

+While the portal URL is publicly accessible, users must sign in to see the APIs in your API center. To enable sign-in, assign the **Azure API Center Data Reader** role to users or groups in your organization, scoped to your API center.

+> [!IMPORTANT]

+> By default, you and other administrators of the API center don't have access to APIs in the API Center portal. Be sure to assign the **Azure API Center Data Reader** role to yourself and other administrators.

+For detailed prerequisites and steps to assign a role to users and groups, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.md). Brief steps follow:

+1. In the [Azure portal](https://portal.azure.com), navigate to your API center.

+1. In the left menu, select **Access control (IAM)** > **+ Add role assignment**.

+1. In the **Add role assignment** pane, set the values as follows:

+ * On the **Role** page, search for and select **Azure API Center Data Reader**. Select **Next**.

+ * On the **Members** page, In **Assign access to**, select **User, group, or service principal** > **+ Select members**.

+ * On the **Select members** page, search for and select the users or groups to assign the role to. Click **Select** and then **Next**.

+ * Review the role assignment, and select **Review + assign**.

+> [!NOTE]

+> To streamline access configuration for new users, we recommend that you assign the role to a Microsoft Entra group and configure a dynamic group membership rule. To learn more, see [Create or update a dynamic group in Microsoft Entra ID](/entra/identity/users/groups-create-rule).

+After you configure access to the portal, configured users can sign in to the portal and view the APIs in your API center.

+> [!NOTE]

+> The first user to sign in to the portal is prompted to consent to the permissions requested by the API Center portal app registration. Thereafter, other configured users aren't prompted to consent.

+## Troubleshooting

+### Error: "You are not authorized to access this portal"

+Under certain conditions, a user might encounter the following error message after signing into the API Center portal with a configured user account:

+`You are not authorized to access this portal. Please contact your portal administrator for assistance.`

+`

+First, confirm that the user is assigned the **Azure API Center Data Reader** role in your API center.

+If the user is assigned the role, there might be a problem with the registration of the **Microsoft.ApiCenter** resource provider in your subscription, and you might need to re-register the resource provider. To do this, run the following command in the Azure CLI:

+```azurecli

+az provider register --namespace Microsoft.ApiCenter

+```

+For more information and steps to register the resource provider using other tools, see [Register resource provider](../azure-resource-manager/management/resource-providers-and-types.md#register-resource-provider).

+## Related content

+* [Azure CLI reference for API Center](/cli/azure/apic)

+* [What is Azure role-based access control (RBAC)?](../role-based-access-control/overview.md)

+* [Best practices for Azure RBAC](../role-based-access-control/best-practices.md)

+>[!NOTE]

+> You can only disable routing to a regional gateway when you are using API Management's default routing, not a custom routing solution.

+ az apim show --name contoso --resource-group apim-hello-world-resource \

+ az apim update --name contoso --resource-group apim-hello-world-resource \

+When a request is made to your app, the FROM address is evaluated against the rules in your access restriction list. If the FROM address is in a subnet configured with service endpoints to `Microsoft.Web`, the source subnet is compared against the virtual network rules in your access restriction list. If the address isn't allowed access based on the rules in the list, the service replies with an [HTTP 403](https://en.wikipedia.org/wiki/HTTP_403) status code.

+The ability to restrict access to your web app from an Azure virtual network uses [service endpoints][serviceendpoints]. With service endpoints, you can restrict access to a multitenant service from selected subnets. It doesn't work to restrict traffic to apps that are hosted in an App Service Environment. If you're in an App Service Environment, you can control access to your app by applying IP address rules.

+To add an access restriction rule to your app, do the following steps:

+1. On the left menu, select **Networking**.

+1. On the **Networking** page, under **Inbound traffic configuration**, select the **Public network access** setting.

+ :::image type="content" source="media/app-service-ip-restrictions/access-restrictions.png" alt-text="Screenshot of the App Service networking options page in the Azure portal.":::

+ The list displays all the current restrictions that are applied to the app. If you have a virtual network restriction on your app, the table shows whether the service endpoints are enabled for Microsoft.Web. If no restrictions are defined on your app and your unmatched rule isn't set to Deny, the app is accessible from anywhere.

+The following Role-based access control permissions on the subnet or at a higher level are required to configure access restrictions through Azure portal, CLI or when setting the site config properties directly:

+***only required if you're updating access restrictions through Azure portal.*

+If you're adding a service endpoint-based rule and the virtual network is in a different subscription than the app, you must ensure that the subscription with the virtual network is registered for the `Microsoft.Web` resource provider. You can explicitly register the provider [by following this documentation](../azure-resource-manager/management/resource-providers-and-types.md#register-resource-provider), but also automatically registered when creating the first web app in a subscription.

+To add an access restriction rule to your app, on the **Access Restrictions** page, select **Add**. The rule is only effective after saving.

+Rules are enforced in priority order, starting from the lowest number in the **Priority** column. If you don't configure unmatched rule, an implicit *deny all* is in effect after you add even a single rule.

+1. Under **Action**, select either **Allow** or **Deny**.

+1. Select **Add rule** after typing in the rule specific input to add the rule to the list.

+Finally select **Save** back in the **Access Restrictions** page.

+* For step 4, in the **Type** drop-down list, select **IPv4** or **IPv6**.

+By using service endpoints, you can restrict access to selected Azure virtual network subnets. If service endpoints aren't already enabled with `Microsoft.Web` for the subnet that you selected, they're automatically enabled unless you select the **Ignore missing `Microsoft.Web` service endpoints** check box. The scenario where you might want to enable service endpoints on the app but not the subnet depends mainly on whether you have the permissions to enable them on the subnet.

+If you need someone else to enable service endpoints on the subnet, select the **Ignore missing Microsoft.Web service endpoints** check box. Your app is configured for service endpoints in anticipation of having them enabled later on the subnet.

+> - Service endpoints aren't supported for web apps that use IP-based TLS/SSL bindings with a virtual IP (VIP).

+ > When you edit a rule, you can't switch between rule types.

+As part of any rule, you can add http header filters. The following http header names are supported:

+Multi-source rules allow you to combine up to eight IP ranges or eight Service Tags in a single rule. You use multi-source rules if you have more than 512 IP ranges or you want to create logical rules. Logical rules could be where multiple IP ranges are combined with a single http header filter.

+In addition to being able to control access to your app, you can restrict access to the SCM (Advanced tool) site used by your app. The SCM site is both the web deploy endpoint and the Kudu console. You can assign access restrictions to the SCM site from the app separately or use the same set of restrictions for both the app and the SCM site. When you select the **Use main site rules** check box, the rules list is hidden, and it uses the rules from the main site. If you clear the check box, your SCM site settings appear again.

+Traffic from Azure Front Door to your application originates from a well known set of IP ranges defined in the `AzureFrontDoor.Backend` service tag. Using a service tag restriction rule, you can restrict traffic to only originate from Azure Front Door. To ensure traffic only originates from your specific instance, you need to further filter the incoming requests based on the unique http header that Azure Front Door sends.

+### [Azure Resource Manager](#tab/arm)

+### [Azure Resource Manager](#tab/arm)

+### [Azure Resource Manager](#tab/arm)

+### [Azure Resource Manager](#tab/arm)

+App access allows you to configure if access is available through the default (public) endpoint. You configure this behavior to either be `Disabled` or `Enabled`. When access is enabled, you can add [Site access](#site-access) restriction rules to control access from select virtual networks and IP addresses. If the setting isn't configured, the default behavior is to enable access unless a private endpoint exists which changes the behavior to disable access.

+In the Azure Resource Manager API, app access is called `publicNetworkAccess`. For ILB App Service Environment, the default entry point for apps is always internal to the virtual network. Enabling app access (`publicNetworkAccess`) doesn't grant direct public access to the apps; instead, it allows access from the default entry point, which corresponds to the internal IP address of the App Service Environment. If you disable app access on an ILB App Service Environment, you can only access the apps through private endpoints added to the individual apps.

+App Service can [send various logging categories to Azure Monitor](./troubleshoot-diagnostic-logs.md#send-logs-to-azure-monitor). One of those categories is called `IPSecurity Audit logs` and represent the activities in access restrictions. All requests that match a rule (except the unmatched rule), both allow and deny, is logged and can be used to validate configuration of access restrictions. The logging capability is also a powerful tool when troubleshooting rules configuration.

+ Title: Use dynamic configuration in Python

+# Tutorial: Use dynamic configuration in Python

+The appliance VM hosts a management Kubernetes cluster. The kubeconfig is a low-privilege Kubernetes configuration file that is used to maintain the appliance VM. By default, it's generated in the current CLI directory when the `deploy` command completes. The kubeconfig should be saved in a secure location on the management machine, because it's required for maintaining the appliance VM. If the kubeconfig is lost, it can be retrieved by running the `az arcappliance get-credentials` command.

+### Cannot connect after updating CLI tool and Arc agent

+This issue occurs when the updated command creates a new service configuration before the Arc agent is updated. This will only impact Azure Arc versions older than 1.31 when updating to a version 1.31 or newer. Error:

+- Connection closed by UNKNOWN port 65535

+ Resolution:

+ - Delete the existing service configuration and allow it to be re-created by the CLI command at the next connection. Run ```az rest --method delete --uri https://management.azure.com/subscriptions/<SUB_ID>/resourceGroups/<RG_NAME>/providers/Microsoft.HybridCompute/machines/<VM_NAME>/providers/Microsoft.HybridConnectivity/endpoints/default/serviceconfigurations/SSH?api-version=2023-03-15```

+## Distributed Tracing

+Distributed Tracing tracks requests and shows how different services interact with each other. In Durable Functions, it also correlates orchestrations and activities together. This is helpful to understand how much time steps of the orchestration take relative to the entire orchestration. It is also useful to understand where an application is having an issue or where an exception was thrown. This feature is supported for all languages and storage providers.

+> [!NOTE]

+> Distributed Tracing V2 requires [Durable Functions v2.12.0](https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.DurableTask/2.12.0) or greater. Also, Distributed Tracing V2 is in a preview state and therefore some Durable Functions patterns are not instrumented. For example, Durable Entities operations are not instrumented and traces will not show up in Application Insights.

+### Setting up Distributed Tracing

+To set up distributed tracing, please update the host.json and set up an Application Insights resource.

+#### host.json

+```

+"durableTask": {

+ "tracing": {

+ "distributedTracingEnabled": true,

+ "Version": "V2"

+ }

+}

+```

+#### Application Insights

+If the Function app is not configured with an Application Insights resource, then please configure it following the instructions [here](../configure-monitoring.md#enable-application-insights-integration).

+### Inspecting the traces

+In the Application Insights resource, navigate to **Transaction Search**. In the results, check for `Request` and `Dependency` events that start with Durable Functions specific prefixes (e.g. `orchestration:`, `activity:`, etc.). Selecting one of these events will open up a Gantt chart that will show the end to end distributed trace.

+[](./media/durable-functions-diagnostics/app-insights-distributed-trace-gantt-chart.png#lightbox)

+### Troubleshooting

+If you don't see the traces in Application Insights, please make sure to wait about five minutes after running the application to ensure that all of the data is propagated to the Application Insights resource.

+|[NeoSystems LLC](https://www.neosystemscorp.com/)|

+|[RSM US, LLP](https://rsmus.com)|

+|[NeoSustems LLC](https://www.neosystemscorp.com/solutions-services/microsoft-licenses/microsoft-365-licenses/)|

+|[RSM US, LLP](https://rsmus.com)|

+ - Custom Logs / Log files ΓÇô to storage

+ Title: How to use the Linux Operating System (OS) Azure Monitor Agent Troubleshooter

+# How to use the Linux operating system (OS) Azure Monitor Agent Troubleshooter

+### Python requirement

+The Linux AMA Troubleshooter requires **Python 2.6+** or any **Python 3** version installed on the machine.

+To check if python is installed on your machine, copy the following command and run in Bash as root:

+```Bash

+sudo python -V

+sudo python3 -V

+```

+Multiple versions of Python can be installed and aliased ΓÇô if multiple versions are installed, use:

+```Bash

+ls -ls /usr/bing/python*

+```

+If your virtual machine is using a distro that doesn't include Python 3 by default, then you must install it. The following sample commands install Python 3 on different distros:

+# [Red Hat, CentOS, Oracle](#tab/redhat)

+```Bash

+sudo yum install -y python3

+```

+# [Ubuntu, Debian](#tab/ubuntu)

+```Bash

+sudo apt-get update

+sudo apt-get install -y python3

+```

+# [Suse](#tab/suse)

+```Bash

+sudo zypper install -y python3

+```

+In addition, the following Python packages are required to run (all should be present on a default install of Python 2 or Python 3):

+### Troubleshooter existence check

+Check for the existence of the AMA Agent Troubleshooter directory on the machine to be diagnosed to confirm the installation of the agent troubleshooter:

+To verify the Azure Monitor Agent Troubleshooter is presence, copy the following command and run in Bash as root:

+If directory doesn't exist or the installation is failed, follow [Basic troubleshooting steps](azure-monitor-agent-troubleshoot-linux-vm.md#basic-troubleshooting-steps).

+If the directory exists, proceed to [Run the Troubleshooter](#run-the-troubleshooter).

+On the machine to be diagnosed, run the Agent Troubleshooter.

+**Log Mode** enables the collection of logs, which can then be compressed into .tgz format for export or review. **Interactive Mode** allows users to actively engage in troubleshooting scenarios and view the output directly within the shell.

+- [Syslog troubleshooting guide for Azure Monitor Agent](../agents/azure-monitor-agent-troubleshoot-linux-vm-rsyslog.md) for Linux

+ Title: How to use the Windows operating system (OS) Azure Monitor Agent Troubleshooter

+# How to use the Windows operating system (OS) Azure Monitor Agent Troubleshooter

+> The Windows AMA Troubleshooter is a command line executable that is shipped with the agent for all versions newer than **1.12.0.0**.

+### Troubleshooter existence check

+Check for the existence of the AMA Agent Troubleshooter directory on the machine to be diagnosed to confirm the installation of the agent troubleshooter:

+If directory doesn't exist or the installation is failed, follow [Basic troubleshooting steps](../agents/azure-monitor-agent-troubleshoot-windows-vm.md#basic-troubleshooting-steps-installation-agent-not-running-configuration-issues).

+- [Troubleshooting guidance for the Azure Monitor agent](../agents/azure-monitor-agent-troubleshoot-windows-arc.md) on Windows Arc-enabled server

+For stateful alerts, while the alert itself is deleted after 30 days, and isn't viewable on the alerts page, the alert condition is stored until the alert is resolved, to prevent firing another alert, and so that notifications can be sent when the alert is resolved. For more information, see [Alerts and state](alerts-overview.md#alerts-and-state).

+## Access the Alerts page

+The **Alerts** summary pane summarizes the alerts fired in the last 24 hours. You can filter the list of alert instances by **Time range**, **Subscription**, **Alert condition**, **Severity**, and more. If you selected a specific alert severity to open the **Alerts** page, the list is prefiltered for that severity.

+ :::image type="content" source="media/alerts-managing-alert-instances/alerts-page.png" lightbox="media/alerts-managing-alert-instances/alerts-page.png" alt-text="Screenshot that shows the Alerts summary page in the Azure portal.":::

+You can see your alerts in a timeline view. In this view, you can see the number of alerts fired in a specific time range. The timeline shows you which resource the alerts were fired on to give you context of the alert in your Azure hierarchy. The alerts are grouped by the time they were fired. You can filter the alerts by severity, resource, and more. You can also select a specific time range to see the alerts fired in that time range.

+ :::image type="content" source="media/alerts-managing-alert-instances/alerts-timeline.png" lightbox="media/alerts-managing-alert-instances/alerts-timeline.png" alt-text="Screenshot that shows the Alerts timeline page in the Azure portal.":::

+To see the alerts in a timeline view, select **View as timeline** at the top of the Alerts summary page. You can choose to see the alerts timeline in with the severity of the alerts indicated by color, or a simplified view with critical or noncritical alerts.

+ :::image type="content" source="media/alerts-managing-alert-instances/alerts-view-timeline.png" lightbox="media/alerts-managing-alert-instances/alerts-view-timeline.png" alt-text="Screenshot that shows the view timeline button in the Alerts summary page in the Azure portal.":::

+You can drill down into a specific time range. Select one of the cards in the timeline to see the alerts fired in that time range.

+ :::image type="content" source="media/alerts-managing-alert-instances/alerts-timeline-details.png" lightbox="media/alerts-managing-alert-instances/alerts-timeline-details.png" alt-text="Screenshot that shows the drilldown into a specific time range in the Alerts timeline page in the Azure portal.":::

+### Customize the timeline view

+You can customize the timeline view to suit your needs by changing the grouping of your alerts.

+1. From the timeline view of the alerts page, select the **Edit** icon in the groups box at the top of the page.

+ :::image type="content" source="media/alerts-managing-alert-instances/alerts-timeline-edit-pencil.png" alt-text="Screenshot that shows the pencil icon to edit the timeline view of the alerts page in the Azure portal.":::

+1. In the **Edit group** pane, drag and drop the fields to group by. You can change the order of the groupings, and add new dimensions, tags, labels, and more. Validation is run on the grouping to make sure that the grouping is valid. If you are at the alerts page for a specific resource, the options for grouping are filtered by that resource, and you can only group by items related to the resource.

+ For AKS clusters, we provide suggested views based on popular groupings.

+1. Select **Save**.

+ :::image type="content" source="media/alerts-managing-alert-instances/alerts-edit-timeline-view.png" lightbox="media/alerts-managing-alert-instances/alerts-edit-timeline-view.png" alt-text="Screenshot that shows the edit group pane in the timeline view of the alerts page in the Azure portal.":::

+1. The timeline displays the alerts grouped by the fields you selected. Alerts that don't logically belong in the grouping you selected are listed in a group called **Other**.

+1. When you have the grouping you want, select **Save view** to save the view.

+### Manage timeline views

+You can save up to 10 views of the alerts timeline. The **default** view is the Azure default view.

+1. From the main **Alerts** page, select **Manage views** to see the list of views you saved.

+1. Select **Save view as** to save a new view.

+1. Mark a view as **Favorite** to see that view every time you come to the **Alerts** page.

+1. Select **Browse all views** to see all the views you saved, select a favorite view, or delete a view. You can only see all of the views from the main alerts page, not from the alerts of an individual resource.

+ - To change the user response to the alert, select the pencil near **User response**.

+ - To see the details of the alert, expand the **Additional details** section.

+ Webhook action groups generally follow these rules when called:

+ - When a webhook is invoked, if the first call fails, it is retried at least 1 more time, and up to 5 times (5 retries) at various delay intervals (5, 20, 40 seconds).

+ - The delay between 1st and 2nd attempt is 5 seconds

+ - The delay between 2nd and 3rd attempt is 20 seconds

+ - The delay between 3rd and 4th attempt is 5 seconds

+ - The delay between 4th and 5th attempt is 40 seconds

+ - The delay between 5th and 6th attempt is 5 seconds

+ - After retries attempted to call the webhook fail, no action group calls the endpoint for 15 minutes.

+ - The retry logic assumes that the call can be retried. The status codes: 408, 429, 503, 504, or `HttpRequestException`, `WebException`, or `TaskCancellationException` allow for the call to be retried.

+After you deploy your web app or website, you can set up recurring tests to monitor availability and responsiveness. [Application Insights](./app-insights-overview.md) sends web requests to your application at regular intervals from points around the world. It can alert you if your application isn't responding or responds too slowly.

+> [!IMPORTANT]

+> On September 30, 2026, URL ping tests in Application Insights will be retired. Existing URL ping tests will be removed from your resources. Review the [pricing](https://azure.microsoft.com/pricing/details/monitor/#pricing) for standard tests and [transition](https://aka.ms/availabilitytestmigration) to using them before September 30, 2026 to ensure you can continue to run single-step availability tests in your Application Insights resources.

+>

+>

+> * You can enable [diagnostic settings on classic Application Insights]() before you [migrate to a workspace-based Application Insights resource](convert-classic-resource.md).All [workspace-based Application Insights resources](./create-workspace-resource.md) must use [diagnostic settings](./create-workspace-resource.md#export-telemetry).

+>

+>

+To continue with automated exports, you will need to migrate to [diagnostic settings](/previous-versions/azure/azure-monitor/app/continuous-export-diagnostic-setting) before migrating to workspace-based resource. The diagnostic setting will carry over in the migration to workspace-based Application Insights.

+### How do I ensure a successful migration of my App Insights resource using Terraform?

+If you are using Terraform to manage your Azure resources, it is important to use the latest version of the Terraform azurerm provider before attempting to upgrade your App Insights resource. Using an older version of the provider, such as version 3.12, may result in the deletion of the classic component before creating the replacement workspace-based Application Insights resource. This can cause the loss of previous data and require updating the configurations in your monitored apps with new connection string and instrumentation key values.

+To avoid this issue, make sure to use the latest version of the Terraform [azurerm provider](https://registry.terraform.io/providers/hashicorp/azurerm/latest), version 3.89 or higher, which performs the proper migration steps by issuing the appropriate ARM call to upgrade the App Insights classic resource to a workspace-based resource while preserving all the old data and connection string/instrumentation key values.

+The legacy **Continuous export** functionality isn't supported for workspace-based resources. Prior to migrating, you need to enable diagnostic settings and disable continuous export.

+1. [Enable Diagnostic Settings](/previous-versions/azure/azure-monitor/app/continuous-export-diagnostic-setting) on you classic Application Insights resource.

+Autoscale does not support vertical scaling. In contrast, scaling up and down, or vertical scaling, keeps the same number of resource instances constant but gives them more capacity in terms of memory, CPU speed, disk space, and network. Vertical scaling is limited by the availability of larger hardware, which eventually reaches an upper limit. Hardware size availability varies in Azure by region. Vertical scaling might also require a restart of the VM during the scaling process.

+* [REST API reference: Autoscale settings](/rest/api/monitor/autoscale-settings)

+[Setup Alerts on Prometheus metrics](./container-insights-metric-alerts.md)<br>

+[Query Prometheus metrics](../essentials/prometheus-grafana.md)<br>

+(This functionality of reporting the benefits used in the `Operation` table started January 27, 2024.)

+> [!TIP]

+> If you [increase the data retention](logs/data-retention-archive.md) of the [Operation](/azure/azure-monitor/reference/tables/operation) table, you will be able to view these benefit trends over longer periods.

+>

+POST /subscriptions/<subscriptionId>/metrics:getBatch?metricNamespace=<resource type namespace>&api-version=2023-10-01

+POST /subscriptions/12345678-1234-1234-1234-123456789abc/metrics:getBatch?metricNamespace=microsoft.compute/virtualMachines&api-version=2023-10-01

+1. Switch from using the `timespan` query param to using `starttime` and `endtime`. For example, `?timespan=2023-04-20T12:00:00.000Z/2023-04-22T12:00:00.000Z` becomes `?startime=2023-04-20T12:00:00.000Z&endtime=2023-04-22T12:00:00.000Z`.

+1. Update the api-version query parameter as follows: `&api-version=2023-10-01`

+ POST https://westus2.metrics.monitor.azure.com/subscriptions/12345678-1234-1234-1234-123456789abc/metrics:getBatch?starttime=2023-04-20T12:00:00.000Z&endtime=2023-04-22T12:00:00.000Z&interval=PT6H&metricNamespace=microsoft.storage%2Fstorageaccounts&metricnames=Ingress,Egress&aggregation=total,average,minimum,maximum&top=10&orderby=total desc&filter=ApiName eq '*'&api-version=2023-10-01

+ "startime": "2023-04-20T12:00:00Z",

+ "endtime": "2023-04-22T12:00:00Z",

+ "starttime": "2023-04-20T12:00:00Z",

+ "endtime": "2023-04-22T12:00:00Z",

+ "starttime": "2023-04-20T12:00:00Z",

+ "endtime": "2023-04-22T12:00:00Z",

+ Cosmos DB | [CDBDataPlaneRequests](/azure/azure-monitor/reference/tables/cdbdataplanerequests)<br>[CDBPartitionKeyStatistics](/azure/azure-monitor/reference/tables/cdbpartitionkeystatistics)<br>[CDBPartitionKeyRUConsumption](/azure/azure-monitor/reference/tables/cdbpartitionkeyruconsumption)<br>[CDBQueryRuntimeStatistics](/azure/azure-monitor/reference/tables/cdbqueryruntimestatistics)<br>[CDBMongoRequests](/azure/azure-monitor/reference/tables/cdbmongorequests)<br>[CDBCassandraRequests](/azure/azure-monitor/reference/tables/cdbcassandrarequests)<br>[CDBGremlinRequests](/azure/azure-monitor/reference/tables/cdbgremlinrequests)<br>[CDBControlPlaneRequests](/azure/azure-monitor/reference/tables/cdbcontrolplanerequests) |

+### [1.4.6](https://www.nuget.org/packages/Microsoft.ApplicationInsights.SnapshotCollector/1.4.6)

+A point release to address a regression when using .NET 8 applications.

+#### Bug fixes

+- Exceptions thrown from dynamically generated methods (e.g. compiled expression trees) in .NET 8 are not being tracked correctly. Fixed.

+- [Deploy an Azure SQL Edge container in Kubernetes](deploy-Kubernetes.md)

+| VMware HCX version 4.8.0 Network Extension (NE) Appliance VMs running in High Availability (HA) mode may experience intermittent Standby to Active failover. For more information, see [HCX - NE appliances in HA mode experience intermittent failover (96352)](https://kb.vmware.com/s/article/96352) | Jan 2024 | Avoid upgrading to VMware HCX 4.8.0 if you are using NE appliances in a HA configuration. | N/A |

+

+ Title: Deploy VMware Cloud Director Availability in Azure VMware Solution

+description: Learn how to install and configure VMware Cloud Director Availability in Azure VMware Solution

+

+# Deploy VMware Cloud Director Availability in Azure VMware Solution

+In this article, learn how to deploy VMware Cloud Director Availability in Azure VMware Solution.

+Customers can use [VMware Cloud Director Availability](https://docs.vmware.com/en/VMware-Cloud-Director-Availability/https://docsupdatetracker.net/index.html), a Disaster Recovery as a Service (DRaaS) solution, to protect and migrate workloads both to and from the VMware Cloud Director service associated with Azure VMware Solution. The native integration of VMware Cloud Director Availability with VMware Cloud Director and VMware Cloud Director service (CDS) enables provider and their tenants to efficiently manage migration and disaster recovery for workloads through the VMware Cloud Director Availability provider and tenant portal.

+## VMware Cloud Director Availability scenarios on Azure VMware Solution

+You can use VMware Cloud Director Availability with Azure VMware Solution for the following two scenarios:

+- On-Premises to Azure VMware Solution

+ VMware Cloud Director Availability provides migration, protection, failover, and reverse failover of VMs, vApps, and templates across on-premises VMware vCenter, VMware Cloud Director, or VMware Cloud Director service (CDS) to VMware CDS on Azure VMware Solution.

+- Azure VMware Solution to Azure VMware Solution

+ VMware Cloud Director Availability provides a flexible solution for multitenant customers. The flexible solution enables smooth workload migration between Cloud Director service (CDS) instances hosted on Azure VMware Solution SDDC, which empowers efficient cloud-to-cloud migration at the tenant level when using CDs with Azure VMware Solution.

+## Key components of VMware Cloud Director Availability

+VMware Cloud Director Availability consists of the following types of appliances.

+### Replication Management Appliance

+This appliance, also known as the manager, enables communication with VMware Cloud Director. The enabled communication gives VMware Cloud Director Availability the capability to discover resources like: Organization Virtual datacenter (OrgVDC), storage policies, datastores, and networks managed by VMware Cloud director and used by tenants.

+The manager plays a vital role in identifying vApps and virtual machines (VMs) eligible for replication of migration and suitable destinations for incoming replications and migrations. It also provides user interface (UI) and API interfaces, which serve as a communication bridge for users interacting with VMware Cloud Director availability.

+The responsibility of the manager extends to communication with local and remote replicators and collecting data about each protected or migrated workload.

+### Replication appliance instances

+VMware Cloud Director Availability Cloud Replication appliance serves as the entity responsible for transferring replication data to and from ESXi hosts in the cloud. For outgoing replications or migrations, it communicates with the VM Kernel interface of an ESXi host; capturing, encrypting, and optionally compressing the replication data. The data is sent to a remote replicator, whether in the cloud or on-premises.

+For incoming replications or migrations, the cloud replicator receives data from a replicator (whether in the cloud or on-premises), decrypts and decompresses it, and then transfers it to ESXi to be written to a datastore. You can deploy more replicators to scale as number of migrations or protections increases.

+### Tunnel appliance

+Tunnel appliance is the single-entry point to VMware Cloud Director Availability instance in the cloud and its role is to manage incoming management and replication traffic. Tunnel handles both data and management traffic and forwards it respectively to cloud replicators and manager.

+### On-premises Cloud director replication appliance

+This appliance is deployed in tenant on-premises datacenters. It creates a pairing relation to VMware Cloud Director Availability in the cloud and can protect or migrate VMs running locally to the cloud and vice versa.

+VMware Cloud Director Availability installation in the Azure VMware Solution cloud site consists of one Replication Manager, one Tunnel Appliance, and two Replicator Appliances. You can deploy more replicators using Azure portal.

+The following diagram shows VMware Cloud Director Availability appliances installed in both on-premises and Azure VMware Solution.

+## Install and configure VMware Cloud Director Availability on Azure VMware Solution

+Verify the following prerequisites to ensure you're ready to install and configure VMware Cloud Director Availability using Run commands.

+### Prerequisites

+- Verify the Azure VMware Solution private cloud is configured.

+- Verify the VMware-Cloud-Director-Availability-Providerrelease.number.xxxxxxx-build_sha_OVF10.ova version 4.7 is uploaded under the correct datastore.

+- Verify the subnet, DNS zone and records for the VMware Cloud Director Availability appliances are configured.

+- Verify the subnet has outbound Internet connectivity to communicate with: VMware Cloud Director service, remote VMware Cloud Director Availability sites, and the upgrade repository.

+- Verify the DNS zone has a forwarding capability for the public IP addresses that need to be reached.

+For using VMware Cloud Director Availability outside of the local network segment, [turn on public IP addresses to an NSX-T Edge node for NSX-T Data Center](https://learn.microsoft.com/azure/azure-vmware/enable-public-ip-nsx-edge).

+- Verify the Cloud Director service is associated, and the Transport Proxy is configured with the Azure VMware Solution private cloud SDDC.

+## Install and manage VMware Cloud Directory Availability using Run commands

+Customers can deploy VMware Cloud Director Availability using Azure Run commands on Azure portal.

+> [!IMPORTANT]

+> Converting from manual installation of VMware Cloud Director Availability to Run command is not supported. Existing customers using VMware Cloud Director Availability can use Run commands and install VMware Cloud Director Availability to fully leverage the classic engine and Disaster Recovery capabilities.

+To access Run commands for VCDA:

+1. Navigate to Azure VMware Solution private cloud

+1. Under **Operations**, select **Run command**

+1. Select **VMware.VCDA.AVS package**

+The Azure VMware Solution private cloud portal provides a range of Run commands for VCDA as are shown in the following screenshot. The commands empower you to perform various operations, including installation, configuration, uninstallation, scaling, and more.

+The Run command **Install-VCDAAVS** installs and configures the VMware Cloud Director Availability instance in Azure VMware Solution. The instance includes VMware Cloud Director Replication Manager, Tunnel, and two Replicators. You can add more replicators by using **Install-VCDARepliactor** to scale.

+> [!NOTE]

+> Run the **Initialize-AVSSite** command before you run the install command.

+You can also use Run commands to perform many other functions such as start, stop VMware Cloud Director Availability VMs, uninstall VMware Cloud Director availability, and more.

+The following image shows the Run commands that are available under **VMware.VCDA.AVS** for VMware Cloud Director Availability on Azure VMware Solution.

+Refer to [VMware Cloud Director Availability in Azure VMware Soltion](https://docs.vmware.com/en/VMware-Cloud-Director-Availability/4.7/VMware-Cloud-Director-Availability-in-AVS/GUID-2BF88B54-5775-4414-8213-D3B41BCDE3EB.html) for detailed instructions on utilizing the Run commands to effectively install and manage VMware Cloud Director Availability within your Azure solution private cloud.

+## FAQs

+### How do I install and configure VMware Cloud Director Availability in Azure VMware Solution and what are the prerequisites?

+Deploy VMware Cloud Director Availability using Run commands to enable classic engines and to access Disaster Recovery functionality. See prerequisites and procedures in [Run command in Azure VMware Solution](https://docs.vmware.com/en/VMware-Cloud-Director-Availability/4.7/VMware-Cloud-Director-Availability-in-AVS/GUID-6D0E6E0B-74BC-4669-9A26-5ACC46B2B296.html).

+### How is VMware Cloud Director Availability supported?

+VMware Cloud Director Availability is a VMware owned and supported product on Azure VMware Solution. For any support queries on VMware Cloud Director availability, contact VMware support for assistance. Both VMware and Microsoft support teams collaborate as necessary to address and resolve VMware Cloud Director Availability issues within Azure VMware Solution.

+### What are Run commands in Azure VMware Solution?

+For more information, go to [Run Command in Azure VMware Solution](https://learn.microsoft.com/azure/azure-vmware/concepts-run-command).

+### How can I add more Replicators in my existing VMware Cloud Director Availability instance in Azure VMware Solution?

+You can use Run Command **Install-VCDAReplicator** to install and configure new VMware Cloud Director Availability replicator virtual machines in Azure VMware Solution.

+### How can I upgrade VMware Cloud Director availability?

+VMware Cloud Director Availability can be upgraded using [Appliances upgrade sequence and prerequisites](https://docs.vmware.com/en/VMware-Cloud-Director-Availability/4.7/VMware-Cloud-Director-Availability-Install-Config-Upgrade-Cloud/GUID-51B25D13-8224-43F1-AE54-65EDDA9E5FAD.html).

+## Next steps

+Learn more about VMware Cloud Director Availability Run commands in Azure VMware Solution, [VMware Cloud Director availability](https://docs.vmware.com/en/VMware-Cloud-Director-Availability/https://docsupdatetracker.net/index.html).

+ Title: Azure Business Continuity Center support matrix

+# Support matrix for Azure Business Continuity Center (preview)

+You can use [Azure Business Continuity Center](business-continuity-center-overview.md), a cloud-native unified business continuity and disaster recovery (BCDR) management platform in Azure to manage your protection estate across solutions and environments. This helps enterprises to govern, monitor, operate, and analyze backups and replication at scale. This article summarizes the solutions and scenarios that ABC center supports for each workload type.

+Azure Business Continuity Center supports all Azure regions.

+This table lists the solutions and scenarios that are unsupported in Azure Business Continuity Center for each workload type:

+| Monitor | Azure Site Recovery replication and failover health are not yet available in Azure Business Continuity Center. You can continue to access these views via the individual vault pane. |

+- [About Azure Business Continuity Center (preview)](business-continuity-center-overview.md).

+5. Click turn on to enable engagement tracking.

+> If you selected Operator Connect or Teams Phone Mobile when you [deployed Azure Communications Gateway](deploy.md), skip this step and go to [Add the Project Synergy application to your Azure tenant](#add-the-project-synergy-application-to-your-azure-tenant).

+## Add the Project Synergy application to your Azure tenant

+1. Specify the user who should set up Azure Communications Gateway and give them the **Admin** role.

+Azure Communications Gateway contains services that need to access the Operator Connect API on your behalf. To enable this access, you must grant specific application roles to the system-assigned managed identity for Azure Communications Gateway under the Project Synergy Enterprise Application. You created the Project Synergy Enterprise Application in [Add the Project Synergy application to your Azure tenant](#add-the-project-synergy-application-to-your-azure-tenant).

+|Calling profile |One of the `CommsGw` Calling Profiles we created for you.|

+ |[Operator Connect portal](https://operatorconnect.microsoft.com/) | `Admin` role or `PartnerSettings.Read` and `NumberManagement.Write` roles (configured on the Project Synergy enterprise application that you set up when [you connected to Operator Connect or Teams Phone Mobile](connect-operator-connect.md#add-the-project-synergy-application-to-your-azure-tenant))|

+1. Ask your onboarding team for the name of the Calling Profile that you must use for these test numbers. The name typically has the suffix `CommsGw`. We created this Calling Profile for you during the Azure Communications Gateway deployment process.

+- Canada Central

+>[! IMPORTANT]

+> ACR is temporarily pausing ACR Tasks runs from Azure free credits. This may affect existing Tasks runs. If you encounter problems, open a [support case](../azure-portal/supportability/how-to-create-azure-support-request.md) for our team to provide additional guidance. Please note that existing customers will not be affected by this pause. We will update our documentation notice here whenever the pause is lifted.

+> Geo-redundant backup can be enabled only during cluster creation or cluster restore.

+> You can't disable geo-redundant backup once cluster is created.

+1. Set **Geo-redundant backup** checkbox for geo-redundant backup *for the restored cluster* to be stored [in another Azure region](./resources-regions.md).

+1. Set **Geo-redundant backup** checkbox for geo-redundant backup *for the restored cluster* to be stored [in another Azure region](./resources-regions.md).

+ - Create & full control on all KMS keys with tag prefix *DefenderForDatabases*

+- KMS keys are created once for each region that contains RDS instances. The creation of a KMS key may incur a minimal additional cost, according to AWS KMS pricing.

+| Feature | Permissions |

+> Starting March 7, 2024, [Defender CSPM](concept-cloud-security-posture-management.md) must be enabled on at least one subscription or multicloud connector in the tenant to benefit from premium DevOps security capabilities which include code-to-cloud contextualization powering security explorer and attack paths and pull request annotations for Infrastructure-as-Code security findings. See details below to learn more.

+| [Attack path analysis](how-to-manage-attack-path.md) | |  |Enable Defender CSPM on an Azure Subscription, AWS Connector, or GCP Connector in the same tenant as the DevOps Connector |

+| [Cloud security explorer](how-to-manage-cloud-security-explorer.md) | |  |Enable Defender CSPM on an Azure Subscription, AWS Connector, or GCP connector in the same tenant as the DevOps Connector|

+| [Attack path analysis](how-to-manage-attack-path.md) | |  | Enable Defender CSPM on an Azure Subscription, AWS Connector, or GCP connector in the same tenant as the DevOps Connector |

+| [Cloud security explorer](how-to-manage-cloud-security-explorer.md) | |  | Enable Defender CSPM on an Azure Subscription, AWS Connector, or GCP connector in the same tenant as the DevOps Connector |

+| [Cloud security explorer](how-to-manage-cloud-security-explorer.md) | |  | Enable Defender CSPM on an Azure Subscription, AWS Connector, or GCP connector in the same tenant as the DevOps Connector |

+| [Enforcement of Defender CSPM for Premium DevOps Security Capabilities](#enforcement-of-defender-cspm-for-premium-devops-security-value) | January 29, 2024 | March 2024 |

+## Enforcement of Defender CSPM for Premium DevOps Security Value

+**Announcement date: January 29, 2023**

+**Estimated date for change: March 7, 2024**

+Defender for Cloud will begin enforcing the Defender CSPM plan check for premium DevOps security value beginning **March 7th, 2024**. If you have the Defender CSPM plan enabled on a cloud environment (Azure, AWS, GCP) within the same tenant your DevOps connectors are created in, you will continue to receive premium DevOps capabilities at no additional cost. If you are not a Defender CSPM customer, you have until **March 7th, 2024** to enable Defender CSPM before losing access to these security features. To enable Defender CSPM on a connected cloud environment before March 7th, 2024, follow the enablement documentation outlined [here](tutorial-enable-cspm-plan.md#enable-the-components-of-the-defender-cspm-plan).

+For more information about which DevOps security features are available across both the Foundational CSPM and Defender CSPM plans, see [our documentation outlining feature availability](devops-support.md#feature-availability).

+For more information about DevOps Security in Defender for Cloud, see the [overview documentation](defender-for-devops-introduction.md).

+For more information on the code to cloud security capabilities in Defender CSPM, see [how to protect your resources with Defender CSPM](tutorial-enable-cspm-plan.md).

+* A SQL Managed Instance. You can create a SQL Managed Instance by following the detail in the article [Create an Azure SQL Managed Instance](/azure/azure-sql/managed-instance/instance-create-quickstart).

+The next example shows creation of Connection Info for an Azure SQL Managed Instance named ΓÇÿtargetmanagedinstanceΓÇÖ:

+The following example is for migrating a single database from SQL Server to an Azure SQL Managed Instance:

+If an entire SQL Server instance needs a lift-and-shift into an Azure SQL Managed Instance, then a loop to take all databases from the source is provided below. In the following example, for $Server, $SourceUserName, and $SourcePassword, provide your source SQL Server details.

+- users.data.root becomes automatically the default and permanent owner of all the data records when the records get created in the system as explained in [OSDU validate owner access API](https://community.opengroup.org/osdu/platform/system/storage/-/blob/master/storage-core/src/main/java/org/opengroup/osdu/storage/service/DataAuthorizationService.java?ref_type=heads#L66) and [OSDU users data root check API](https://community.opengroup.org/osdu/platform/system/storage/-/blob/master/storage-core/src/main/java/org/opengroup/osdu/storage/service/EntitlementsAndCacheServiceImpl.java#L98). As a result, irrespective of the OSDU membership of the user, the system checks if the user is ΓÇ£DataManagerΓÇ¥, i.e., part of data.root group, to grant access of the data record.

+- The default membership in users.data.root is only the `app-id` that is used to set up the instance. You can add other users explicitly to this group to give them default access of data records.

+* Ashita Rastogi | Lead Principal Program Manager, Azure Messaging

+- [Learn about Event Domains](event-domains.md)

+**Change Data Capture (CDC)** is a technique used to track row-level changes in database tables in response to create, update, and delete operations. [Debezium](https://debezium.io/) is a distributed platform that builds on top of Change Data Capture features available in different databases (for example, [logical decoding in PostgreSQL](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html)). It provides a set of [Kafka Connect connectors](https://debezium.io/documentation/reference/stable/connectors/https://docsupdatetracker.net/index.html) that tap into row-level changes in database tables and convert them into event streams that are then sent to [Apache Kafka](https://kafka.apache.org/).

+This tutorial walks you through how to set up a change data capture based system on Azure using [Event Hubs](./event-hubs-about.md?WT.mc_id=devto-blog-abhishgu) (for Kafka), [Azure Database for PostgreSQL](../postgresql/overview.md) and Debezium. It uses the [Debezium PostgreSQL connector](https://debezium.io/documentation/reference/stable/connectors/postgresql.html) to stream database modifications from PostgreSQL to Kafka topics in Event Hubs.

+## Prerequisites

+To complete this walk through, you require:

+[Azure Database for PostgreSQL](../postgresql/overview.md) is a relational database service based on the community version of open-source PostgreSQL database engine, and is available in three deployment options: Single Server, Flexible Server, and Cosmos DB for PostgreSQL. [Follow these instructions](../postgresql/quickstart-create-server-database-portal.md) to create an Azure Database for PostgreSQL server using the Azure portal.

+This section covers the following topics:

+Follow the latest instructions in the [Debezium documentation](https://debezium.io/documentation/reference/stable/connectors/postgresql.html#postgresql-deployment) to download and set up the connector.

+Minimal reconfiguration is necessary when redirecting Kafka Connect throughput from Kafka to Event Hubs. The following `connect-distributed.properties` sample illustrates how to configure Connect to authenticate and communicate with the Kafka endpoint on Event Hubs:

+> `database.server.name` attribute is a logical name that identifies and provides a namespace for the particular PostgreSQL database server/cluster being monitored.

+To see change data capture in action, you need to create/update/delete records in the Azure PostgreSQL database.

+Start by connecting to your Azure PostgreSQL database (the following example uses [psql](https://www.postgresql.org/docs/12/app-psql.html)).

+The connector should now spring into action and send change data events to an Event Hubs topic with the following name `my-server.public.todos`, assuming you have `my-server` as the value for `database.server.name` and `public.todos` is the table whose changes you're tracking (as per `table.whitelist` configuration).

+Let's introspect the contents of the topic to make sure everything is working as expected. The below example uses [`kafkacat`](https://github.com/Azure/azure-event-hubs-for-kafk).

+Now that all the `todos` table changes are being captured in Event Hubs topic, you use the FileStreamSink connector (that is available by default in Kafka Connect) to consume these events.

+Create a configuration file (`file-sink-connector.json`) for the connector - replace the `file` attribute as per your file system.

+Kafka Connect creates Event Hubs topics to store configurations, offsets, and status that persist even after the Kafka Connect cluster has been taken down. Unless this persistence is desired, we recommend that you delete these topics. You might also want to delete the `my-server.public.todos` event hub that were created during this walk through.

+ Title: 'Link a virtual network to ExpressRoute circuits - Azure portal'

+description: This article shows you how to create a connection to link a virtual network to Azure ExpressRoute circuits using the Azure portal.

+zone_pivot_groups: expressroute-experience

+# Connect a virtual network to ExpressRoute circuits using the Azure portal

+This article helps you create a connection to link a virtual network (virtual network) to Azure ExpressRoute circuits using the Azure portal. The virtual networks that you connect to your Azure ExpressRoute circuit can either be in the same subscription or part of another subscription.

+1. Sign in to the Azure portal with this [Preview link](https://aka.ms/expressrouteguidedportal). This link is required to access the new preview connection create experience to an ExpressRoute circuit.

+2. Ensure that your ExpressRoute circuit and Azure private peering have been configured successfully. Follow the instructions in [Create an ExpressRoute circuit](expressroute-howto-circuit-arm.md) and [Create and modify peering for an ExpressRoute circuit](expressroute-howto-routing-arm.md). Your ExpressRoute circuit should look like the following image:

+3. You can now start provisioning a connection to link your virtual network gateway to your ExpressRoute circuit. Select **Connection** > **Add** to open the **Create connection** page.

+4. Select the **Connection type** as **ExpressRoute** and then select **Next: Settings >**.

+ :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/create-connection-basic-new.png" alt-text="Screenshot of create a connection basic page.":::

+5. Select the resiliency type for your connection. You can choose **Maximum resiliency** or **Standard resiliency**.

+ **Maximum resiliency** - This option provides the highest level of resiliency to your virtual network. It provides two redundant connections from the virtual network gateway to two different ExpressRoute circuits in different ExpressRoute locations.

+

+ :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/maximum-resiliency.png" alt-text="Diagram of a virtual network gateway connected to two different ExpressRoute circuits.":::

+ **Standard resiliency** - This option provides a single redundant connection from the virtual network gateway to a single ExpressRoute circuit.

+ :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/standard-resiliency.png" alt-text="Diagram of a virtual network gateway connected to a single ExpressRoute circuit.":::

+

+6. Enter the following information for the respective resiliency type and then select **Review + create**. Then select **Create** after validation completes.

+ :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/create-connection-configuration.png" alt-text="Screenshot of the settings page for maximum resiliency ExpressRoute connections to a virtual network gateway.":::

+ **Maximum resiliency**

+ | Setting | Value |

+ | | |

+ | Virtual network gateway | Select the virtual network gateway that you want to connect to the ExpressRoute circuit. |

+ | Use existing connection or create new | You can augment resiliency for an ExpressRoute connection you already created by selecting **Use existing**. Then select an existing ExpressRoute connection for the first connection. If you select **Use existing**, you only need to configure the second connection. If you select **Create new**, enter following information for both connections. |

+ | Name | Enter a name for the connection. |

+ | ExpressRoute circuit | Select the ExpressRoute circuit that you want to connect to. |

+ | Routing weight | Enter a routing weight for the connection. The routing weight is used to determine the primary and secondary connections. The connection with the higher routing weight is the preferred circuit. |

+ | FastPath | Select the checkbox to enable FastPath. For more information, see [About ExpressRoute FastPath](about-fastpath.md). |

+ Complete the same information for the second ExpressRoute connection. When selecting an ExpressRoute circuit for the second connection, you are provided with the distance from the first ExpressRoute circuit. This information appears in the diagram and can help you select the second ExpressRoute location.

+ > [!NOTE]

+ > To have maximum resiliency, you should select two circuits in different peering location. You'll be given the following warning if you select two circuits in the same peering location.

+ >

+ > :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/same-location-warning.png" alt-text="Screenshot of warning in the Azure portal when selecting two ExpressRoute circuits in the same peering location.":::

+ **Standard resiliency**

+ For standard resiliency, you only need to enter information for one connection.

+7. After your connection has been successfully configured, your connection object will show the information for the connection.

+ :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/connection-object.png" alt-text="Screenshot of a created connection resource.":::

+4. Enter a name for the connection and then select **Next: Settings >**.

+5. Select the gateway that belongs to the virtual network that you want to link to the circuit and select **Review + create**. Then select **Create** after validation completes.

+6. After your connection has been successfully configured, your connection object will show the information for the connection.

+> [!NOTE]

+> * Connecting virtual networks between Azure sovereign clouds and Public Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.

+> * Connectivity and bandwidth charges for the dedicated circuit will be applied to the ExpressRoute circuit owner. All virtual networks share the same bandwidth.

+> Connections redeemed in different subscriptions will not display in the circuit connection page. Navigate to the subscription where the authorization was redeemed and delete the top-level connection resource.

+Azure Firewall Premium provides signature-based IDPS to allow rapid detection of attacks by looking for specific patterns, such as byte sequences in network traffic, or known malicious instruction sequences used by malware. The IDPS signatures are applicable for both application and network-level traffic (Layers 3-7). They're fully managed and continuously updated. IDPS can be applied to inbound, spoke-to-spoke (East-West), and outbound traffic. Spoke-to-spoke (East-West) includes traffic that goes from/to an on-premises network. You can configure your IDPS private IP address ranges using the **Private IP ranges** feature. For more information, see [IDPS Private IP ranges](#idps-private-ip-ranges).

+## Run queries with Power BI connector

+> [!NOTE]

+> The Azure Resource Graph Power BI connector is in public preview.

+The Azure Resource Graph Power BI connector runs queries at the tenant level but you can change the scope to subscription or management group. The Power BI connector has an optional setting to return all records if your query results have more than 1,000 records. For more information, go to [Quickstart: Run queries with the Azure Resource Graph Power BI connector](./power-bi-connector-quickstart.md).

+ Title: Run queries with the Azure Resource Graph Power BI connector

+description: In this quickstart, you learn how to run queries with the Azure Resource Graph Power BI connector.

+# Quickstart: Run queries with the Azure Resource Graph Power BI connector

+In this quickstart, you learn how to run queries with the Azure Resource Graph Power BI connector. By default the Power BI connector runs queries at the tenant level but you can change the scope to subscription or management group. Resource Graph by default returns a maximum of 1,000 records but the Power BI connector has an optional setting to return all records if your query results have more than 1,000 records.

+> [!NOTE]

+> The Azure Resource Graph Power BI connector is in public preview.

+> [!TIP]

+> If you participated in the private preview, delete your _AzureResourceGraph.mez_ preview file. If the file isn't deleted, your custom connector might be used by Power Query instead of the certified connector.

+## Prerequisites

+- If you don't have an Azure account with an active subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

+- [Power BI Desktop](https://powerbi.microsoft.com/desktop/).

+- Azure role-based access control rights with at least _Reader_ role assignment to resources. Learn more about [how to assign roles](../../role-based-access-control/role-assignments-portal.md).

+## Connect Resource Graph with Power BI connector

+After Power BI Desktop is installed, you can connect Resource Graph with Power BI connector so that you can run a query. If you don't have a query to run, you can use the following sample that queries for storage accounts.

+```kusto

+resources

+| where type == 'microsoft.storage/storageaccounts'

+```

+The following example runs a query with the default settings.

+1. Open the Power BI Desktop app on your computer and close any dialog boxes that are displayed.

+1. Go to **Home** > **Get data** > **More** > **Azure** > **Azure Resource Graph** and select **Connect**.

+ :::image type="content" source="./media/power-bi-connector-quickstart/power-bi-get-data.png" alt-text="Screenshot of the get data dialog box in Power BI Desktop to select the Azure Resource Graph connector.":::

+1. On the **Azure Resource Graph** dialog box, enter your query into the **Query** box.

+ :::image type="content" source="./media/power-bi-connector-quickstart/query-dialog-box.png" alt-text="Screenshot of the Azure Resource Graph dialog box to enter a query and use the default settings.":::

+1. Select **OK** to run the query and if prompted, enter your credentials.

+1. Select **Connect** to run the query. The results are displayed in Power BI Desktop.

+1. Select **Load** or **Transform Data**.

+ - **Load** imports the query results into Power BI Desktop.

+ - **Transform Data** opens the Power Query Editor with your query results.

+## Use optional settings

+You can select optional values to change the Azure subscription or management group that the query runs against or to get query results of more than 1,000 records.

+| Option | Description |

+| - | - |

+| Scope | You can select subscription or management group. Tenant is the default scope when no selection is made. |

+| Subscription ID | Required if you select subscription scope. Specify the Azure subscription ID. Use a comma-separated list to query multiple subscriptions. |

+| Management group ID | Required if you select management group scope. Specify the Azure management group ID. Use a comma-separated list to query multiple management groups. |

+| Advanced options | To get more than 1,000 records change `$resultTruncated` to `FALSE`. By default Resource Graph returns a maximum of 1,000 records. |

+For example, to run a query for a subscription that returns more than 1,000 records:

+- Set the scope to subscription.

+- Enter a subscription ID.

+- Set `$resultTruncated` to `FALSE`.

+## Clean up resources

+When you're finished, close any Power BI Desktop or Power Query windows and save or discard your queries.

+## Related content

+For more information about the query language or how to explore resources, go to the following articles.

+- [Understanding the Azure Resource Graph query language](./concepts/query-language.md).

+- [Explore your Azure resources with Resource Graph](./concepts/explore-resources.md).

+- Sample queries listed by [table](./samples/samples-by-table.md) or [category](./samples/samples-by-category.md).

+[!code-powershell[main](../../azure_powershell_scripts/hdinsight/create-cluster/create-cluster.ps1?range=5-74)]

+- `*/*` (when transfer-syntax isn't specified, `*` is used as default and mediaType defaults to `application/dicom`)

+- `*/*` (when transfer-syntax isn't specified, `*` is used as default and mediaType defaults to `application/dicom`)

+- `*/*` (when transfer-syntax isn't specified, `*` is used as default and mediaType defaults to `application/octet-stream`)

+- `*/*` (when transfer-syntax isn't specified, `*` is used as default and mediaType defaults to `application/dicom`)

+- `*/*` (when transfer-syntax isn't specified, `*` is used as default and mediaType defaults to `application/dicom`)

+- `*/*` (when transfer-syntax isn't specified, `*` is used as default and mediaType defaults to `application/octet-stream`)

+### Attributes automatically changed in bulk updates

+When you perform a bulk update, the DICOM service updates the requested attributes and also two additional metadata fields. Here is the information that is updated automatically:

+| Tag | Attribute name | Description | Value

+| --| | | --|

+| (0002,0012) | Implementation Class UID | Uniquely identifies the implementation that wrote this file and its content. | 1.3.6.1.4.1.311.129 |

+| (0002,0013) | Implementation Version Name | Identifies a version for an Implementation Class UID (0002,0012) | Assembly version of the DICOM service (e.g. 0.1.4785) |

+Here, the UID `1.3.6.1.4.1.311.129` is a registered under [Microsoft OID arc](https://oidref.com/1.3.6.1.4.1.311) in IANA.

+1. On the **Automation** tab, the automation commands are populated based on your chosen cluster and key vault. Select an automation option:

+ * **Azure CLI enablement + UI deployment -- Visually guided configuration**: Generates an Azure CLI command that configures your cluster. If you choose this option, you'll return to the Azure portal to complete the Azure IoT Operations deployment.

+ * **Azure CLI deployment -- Efficiency unleashed**: Generates an Azure CLI command that configures your cluster and also deploys Azure IoT Operations.

+1. After choosing your automation option, copy the generated CLI command.

+ <!-- :::image type="content" source="../get-started/media/quickstart-deploy/install-extension-automation.png" alt-text="Screenshot of copying the CLI command from the automation tab for installing the Azure IoT Operations Arc extension in the Azure portal."::: -->

+ If you copied the **Azure CLI deployment** CLI command, then you're done with the cluster configuration and deployment.

+1. If you copied the **Azure CLI enablement + UI deployment** CLI command, return to the Azure portal and select **Review + Create**.

+1. Once you select a key vault, the **Automation** tab populates an Azure CLI command that configures your cluster with your deployment information. Copy the CLI command.

+ >Select the **Azure CLI deployment -- Efficiency unleashed** automation option to generate a CLI command that performs the configuration tasks on your cluster and then also deploys Azure IoT Operations.

+ <!-- :::image type="content" source="./media/quickstart-deploy/install-extension-automation.png" alt-text="Screenshot of copying the CLI command from the automation tab for installing the Azure IoT Operations Arc extension in the Azure portal."::: -->

+| `ServiceProviders.Sftp.ServerAliveInterval` | `00:30:00` <br>(30 min) | Sends a "keep alive" message to keep the SSH connection active if no data exchange with the server happens during the specified period. |

+| `TARGET_BASED_SCALING_ENABLED` | `1` | Sets Azure Logic Apps to use target-based scaling (`1`) or incremental scaling (`0`). By default, target-based scaling is automatically enabled. For more information see [Target-based scaling](#scaling). |

+<a name="scaling"></a>

+### Target-based scaling

+Single-tenant Azure Logic Apps gives you the option to select your preferred compute resources and set up your logic app resources to dynamically scale based on varying workload demands. The target-based scaling model used by Azure Logic Apps includes settings that you can use to fine-tune the model's underlying dynamic scaling mechanism, which can result in faster scale-out and scale-in times. For more information about the target-based scaling model, see the following articles:

+- [Target-based scaling support in single-tenant Azure Logic Apps](https://techcommunity.microsoft.com/t5/azure-integration-services-blog/announcement-target-based-scaling-support-in-azure-logic-apps/ba-p/3998712)

+- [Single-tenant Azure Logic Apps target-based scaling performance benchmark - Burst workloads](https://techcommunity.microsoft.com/t5/azure-integration-services-blog/logic-apps-standard-target-based-scaling-performance-benchmark/ba-p/3998807)

+#### Considerations

+- Target-based scaling isn't available or supported for Standard workflows running on an App Service Environment or Consumption plan.

+- If you have scale-in requests without any scale-out requests, Azure Logic Apps uses the maximum scale-in value. Target-based scaling can scale down unused worker instances faster, resulting in more efficient resource usage.

+#### Requirements

+- Your logic apps must use [Azure Functions runtime version 4.3.0 or later](../azure-functions/set-runtime-version.md).

+- Your logic app workflows must use single-tenant Azure Logic Apps runtime version 1.55.1 or later.

+#### Target-based scaling settings in host.json

+| Setting | Default value | Description |

+|||-|

+| `Runtime.TargetScaler.TargetConcurrency` | `null` | The number of target executions per worker instance. By default, the value is `null`. If you leave this value unchanged, your logic app defaults to using dynamic concurrency. You can set a targeted maximum value for concurrent job polling by using this setting. For an example, see the section following this table. |

+| `Runtime.TargetScaler.TargetScalingCPU` | `70` | The maximum percentage of CPU usage that you expect at target concurrency. You can change this default percentage for each logic app by using this setting. For an example, see the section following this table. |

+| `Runtime.TargetScaler.TargetScalingFactor` | `0.3` | A numerical value from `0.05` to `1.0` that determines the degree of scaling intensity. A higher target scaling factor results in more aggressive scaling. A lower target scaling factor results in more conservative scaling. You can fine-tune the target scaling factor for each logic app by using this setting. For an example, see the section following this table. |

+##### TargetConcurrency example

+```json

+{

+ "version": "2.0",

+ "extensionBundle": {

+ "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",

+ "version": "[1.*, 2.0.0)"

+ },

+ "extensions": {

+ "workflow": {

+ "Settings": {

+ "Runtime.TargetScaler.TargetConcurrency": "280"

+ }

+ }

+ }

+}

+```

+#### TargetScalingCPU example

+```json

+{

+ "version": "2.0",

+ "extensionBundle": {

+ "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",

+ "version": "[1.*, 2.0.0)"

+ },

+ "extensions": {

+ "workflow": {

+ "Settings": {

+ "Runtime.TargetScaler.TargetScalingCPU": "76"

+ }

+ }

+ }

+}

+```

+##### TargetScalingFactor example

+```json

+{

+ "version": "2.0",

+ "extensionBundle": {

+ "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",

+ "version": "[1.*, 2.0.0)"

+ },

+ "extensions": {

+ "workflow": {

+ "Settings": {

+ "Runtime.TargetScaler.TargetScalingFactor": "0.62"

+ }

+ }

+ }

+}

+```

+#### Disable target-based scaling

+By default, target-based scaling is automatically enabled. To opt out from using target-based scaling and revert back to incremental scaling, add the app setting named **TARGET_BASED_SCALING_ENABLED** and set the value set to **0** in your Standard logic app resource using the Azure portal or in your logic app project's **local.settings.json file** using Visual Studio Code. For more information, see [Manage app settings - local.settings.json](#manage-app-settings).

+* [SignedHttpRequest, also known as PoP (Proof of Possession)](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/wiki/SignedHttpRequest-aka-PoP-(Proof-of-Possession))

+* For Consumption logic app workflows in the multitenant Azure Logic Apps environment, HTTP operations don't permit self-signed TLS/SSL certificates. If your logic app makes an HTTP call to a server and presents a TLS/SSL self-signed certificate, the HTTP call fails with a `TrustFailure` error.

+| **Authentication** | `type` | Yes | **Client Certificate** <br>or <br>`ClientCertificate` | The authentication type to use. You can manage certificates with [Azure API Management](../api-management/api-management-howto-mutual-certificates.md). <br><br></p>**Note**: Custom connectors don't support certificate-based authentication for both inbound and outbound calls. |

+| **Pfx** | `pfx` | Yes | <*encoded-pfx-file-content*> | The base64-encoded content from a Personal Information Exchange (PFX) file <br><br>To convert the PFX file into base64-encoded format, you can use PowerShell 7 by following these steps: <br><br>1. Save the certificate content into a variable: <br><br> `$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')` <br><br>2. Convert the certificate content by using the `ToBase64String()` function and save that content to a text file: <br><br> `[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'` <br><br>**Troubleshooting**: If you use the `cert mmc/PowerShell` command, you might get this error: <br><br>`Could not load the certificate private key. Please check the authentication certificate password is correct and try again.` <br><br>To resolve this error, try converting the PFX file to a PEM file and back again by using the `openssl` command: <br><br>`openssl pkcs12 -in certificate.pfx -out certificate.pem` <br>`openssl pkcs12 -in certificate.pem -export -out certificate2.pfx` <br><br>Afterwards, when you get the base64-encoded string for the certificate's newly converted PFX file, the string now works in Azure Logic Apps. |

+> [!NOTE]

+>

+> If you try to authenticate with a client certificate using OpenSSL, you might get the following error:

+>

+> `BadRequest: Could not load private key`

+>

+> To resolve this error, follow these steps:

+>

+> 1. Uninstall all OpenSSL instances.

+> 2. Install OpenSSL version 1.1.1t.

+> 3. Resign your certificate using the new update.

+> 4. Add the new certificate to the HTTP operation when using client certificate authentication.

+>

+> If you have a Standard logic app resource in single-tenant Azure Logic Apps, and you want to use an HTTP

+> operation with a TSL/SSL certificate, client certificate, or Microsoft Entra ID Open Authentication

+> (Microsoft Entra ID OAuth) with the `Certificate` credential type, make sure to complete the extra setup

+> steps for this authentication type. Otherwise, the call fails. For more information, review

+>

+> If you have a Standard logic app resource in single-tenant Azure Logic Apps, and you want to use an HTTP

+> operation with a TSL/SSL certificate, client certificate, or Microsoft Entra ID Open Authentication

+> (Microsoft Entra ID OAuth) with the `Certificate` credential type, make sure to complete the extra setup

+> steps for this authentication type. Otherwise, the call fails. For more information, review

+* A Consumption logic app resource can use the system-assigned identity or a *single* manually created user-assigned identity.

+* A Standard logic app resource supports having the [system-assigned managed identity *and* multiple user-assigned managed identities](create-managed-service-identity.md) enabled at the same time, though you still can only select one identity to use at any time.

+ | **Audience** | `audience` | Yes | <*target-resource-ID*> | The resource ID for the target resource that you want to access. <br><br>For example, `https://storage.azure.com/` makes the [access tokens](../active-directory/develop/access-tokens.md) for authentication valid for all storage accounts. However, you can also specify a root service URL, such as `https://fabrikamstorageaccount.blob.core.windows.net` for a specific storage account. <br><br>**Note**: The **Audience** property might be hidden in some triggers or actions. To make this property visible, in the trigger or action, open the **Add new parameter** list, and select **Audience**. <br><br>**Important**: Make sure that this target resource ID *exactly matches* the value that Microsoft Entra ID expects, including any required trailing slashes. So, the `https://storage.azure.com/` resource ID for all Azure Blob Storage accounts requires a trailing slash. However, the resource ID for a specific storage account doesn't require a trailing slash. To find these resource IDs, review [Azure services that support Microsoft Entra ID](../active-directory/managed-identities-azure-resources/services-support-managed-identities.md#azure-services-that-support-azure-ad-authentication). |

+Data outputs refer to the location where the results of a batch job should be placed. Outputs are identified by name, and Azure Machine Learning automatically assigns a unique path to each named output. However, you can specify another path if required.

+> [!IMPORTANT]

+> Batch endpoints only support writing outputs in Azure Blob Storage datastores.

+Azure Machine Learning workspaces have built-in roles that are available by default. When adding users to a workspace, they can be assigned one of the following roles.

+| Create/manage online endpoints and deployments | Not required | To deploy on studio, `Microsoft.Resources/deployments/write` | Owner, contributor, or custom role allowing `Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*`. |

+### Deploy into a virtual network or subnet

+ > Notice that the resource scope for invoking a batch endpoints (`https://ml.azure.com) is different from the resource scope used to manage them. All management APIs in Azure use the resource scope `https://management.azure.com`, including Azure Machine Learning.

+> [!NOTE]

+> Once a managed VNet workspace is configured to __allow only approved outbound__, the workspace cannot be reconfigured to __allow internet outbound__. Please keep this in mind when configuring managed VNet for your workspace.

+ Blocked models| Select models you want to exclude from the training job. <br><br> Allowing models is only available for [SDK experiments](how-to-configure-auto-train.md#supported-algorithms). <br> See the [supported algorithms for each task type](/python/api/azureml-automl-core/azureml.automl.core.shared.constants.supportedmodels).

+ Positive class label| Label that Automated ML will use to calculate binary metrics.

+ 

+

+

+Drill down on any of the completed models to see training job details.

+You can see model specific performance metric charts on the **Metrics** tab. [Learn more about charts](how-to-understand-automated-ml.md).

+This is also where you can find details on all the properties of the model along with associated code, child jobs, and images.

+ 

+ - update-code

+ - update-code2

+ - update-code2

+* [Azure CLI (v2)](how-to-configure-cli.md)

+> Azure Machine Learning doesn't store or process your data outside of the region where you deploy.

+In Azure Machine Learning, you can run your training script in the cloud or build a model from scratch. Customers often bring models they've built and trained in open-source frameworks so that they can operationalize them in the cloud.

+Data scientists can use models in Azure Machine Learning that they've created in common Python frameworks, such as:

+To bring a model into production, you deploy the model. The Azure Machine Learning managed endpoints abstract the required infrastructure for both batch or real-time (online) model scoring (inferencing).

+* [Set up an Azure Machine Learning workspace](quickstart-create-resources.md)

+* [Tutorial: Build a first machine learning project](tutorial-1st-experiment-hello-world.md)

+* [Run training jobs](how-to-train-model.md)

+ - update-code

+## 2024-01-29

+### Azure Machine Learning SDK for Python v1.55.0

+ + **azureml-core**

+ + Enable Application Insights re-mapping for new region China East 3, since it doesn't support classic resource mode. Also fixed the missing update for China North 3.

+ + **azureml-defaults**

+ + Bumped azureml-inference-server-http pin to 1.0.0 in azureml-defaults.

+ + **azureml-interpret**

+ + updated azureml-interpret package to interpret-community 0.31.*

+ + **azureml-responsibleai**

+ + updated common environment and azureml-responsibleai package to raiwidgets and responsibleai 0.33.0

+ + Increase responsibleai and fairlearn dependency versions

+ "GeneralPurpose",

+ "GeneralPurpose",

+* South UK

+* West Europe

+ Title: Configure Azure Resource Health alerts for Azure Red Hat OpenShift (ARO) clusters

+description: Learn how to configure Azure Monitor alerts for Azure Red Hat OpenShift (ARO) clusters.

+keywords: openshift, red hat, monitor, cluster, alerts

+# Configure Azure Resource Health alerts for Azure Red Hat OpenShift (ARO) clusters

+[Azure Resource Health](/azure/service-health/resource-health-overview?WT.mc_id=Portal-Microsoft_Azure_Health) is a component of Azure Monitor that can be configured to generate alerts based on signals from Azure Red Hat OpenShift clusters. These alerts help you prepare for events such as planned and unplanned maintenance.

+Resource Health alert signals for ARO clusters include the following:

+- **Cluster maintenance operation pending:** This signal indicates that your Azure Red Hat OpenShift cluster will undergo a maintenance operation within the next two weeks. This may cause rolling reboots of nodes resulting in workload pod restarts.

+- **Cluster maintenance operation in progress:** This signal indicates one of the following operation types:

+ - **Planned:** A planned maintenance operation has started on your Azure Red Hat OpenShift cluster. This may cause rolling reboots of nodes resulting in workload pod restarts.

+ - **Unplanned:** An unplanned maintenance operation has started on your Azure Red Hat OpenShift cluster. This may cause rolling reboots of nodes resulting in workload pod restarts.

+- **Action needed to complete maintenance operation:** This signal indicates that action is needed to complete an ongoing maintenance operation of your Azure Red Hat OpenShift cluster. Contact Azure Support to complete the ongoing maintenance operation of your Azure Red Hat OpenShift cluster.

+- **Cluster API server is unreachable:** This signal indicates that the Azure Red Hat OpenShift service Resource Provider is unable to reach your cluster's API server. Your cluster is hence unable to be monitored and is unmanageable.

+Once the underlying condition causing an alert signal is remediated, the signal is cleared and the alert condition ends.

+## Creating alert rules

+Configuring Resource Health alerts for an ARO cluster requires an alert rule. Alert rules define the conditions in which alert signals are generated.

+1. In the [Azure portal](https://ms.portal.azure.com/), go to the ARO cluster for which you want to configure alerts.

+1. Select **Resource health**, then select **Add resource health alert**.

+1. Enter all applicable parameters for the alert rule in the various tabs of the window, including an **Alert rule name** in the **Details** tab.

+

+1. Select **Review + Create**.

+## Cluster alert notifications

+When Azure Monitor detects a signal related to the cluster, it generates an alert. For detailed instructions on using and creating alert rules, see [What are Azure Monitor alerts?](/azure/azure-monitor/alerts/alerts-overview)

+## View cluster alerts in Azure portal

+You can view the status of the cluster at any time from the Azure portal. Go the applicable cluster in the portal and select **Resource health** to see if the cluster is available or unavailable and any events associated with it. For more information, see [Resource Health overview](/azure/service-health/resource-health-overview).

+You can also view the alert rule you created for the cluster. Viewing the alert rule in the portal allows you to see any alerts fired against the rule.

+* General availability of UAE Central region.

+* General availability of Israel Central region.

+* General availability of Italy North region.

+- An Azure Database for PostgreSQL single server. Create one using [Azure CLI](./quickstart-create-server-database-azure-cli.md).

+4. To confirm, you can also connect to Azure Database for PostgreSQL [using psql](./quickstart-create-server-database-azure-cli.md#connect-to-the-azure-database-for-postgresql-server-by-using-psql) and run queries against the database, for example:

+> Please be aware that as part of the ongoing retirement process for Azure Database for PostgreSQL - Single Server, the option to create new instances via the Azure portal is no longer available.

+> While portal-based creation is discontinued, you can continue to create Single Server instances using methods such as [Azure CLI](quickstart-create-server-database-azure-cli.md), [Azure CLI up command](quickstart-create-server-up-azure-cli.md) or the [ARM template](quickstart-create-postgresql-server-database-using-arm-template.md). However, please note that as of March 2025, these methods will also no longer be used for creating new instances.

+

+A SIM policy takes effect on a UE when it attaches or re-attaches to the network. Therefore, changes to the policy are not dynamically implemented on existing UE sessions. However, if a SIM policy is removed from a UE's SIM, then Azure Private 5G Core will perform a network-initiated detach, disconnecting the UE from the network.

+A SIM policy takes effect on a UE when it attaches or re-attaches to the network. Therefore, changes to the policy are not dynamically implemented on existing UE sessions. However, if a SIM policy is removed from a UE's SIM, then Azure Private 5G Core will perform a network-initiated detach, disconnecting the UE from the network.

+###  Foundational services

+| [Azure NAT Gateway](../nat-gateway/nat-availability-zones.md) |  |

+> [!IMPORTANT]

+> When configuring the storage account, do **not** specify an allowed IP address range, even when it allow-lists all IP addresses:

+>

+> 

+>

+> With any IP range being specified, the SAS token may not work with ARR and model loading might fail.

+1. Under **Managed resource settings**, choose the network settings for the managed storage account deployed into your subscription. This storage account is required for ACSS to orchestrate the deployment of new SAP system and further power all the SAP management capabilities.

+ 1. For **Storage account network access**, select Enable access from specific virtual network for enhanced network security access for the managed storage account. This option ensures that this storage account is accessible only from the virtual network in which the SAP system exists.

+ > [!IMPORTANT]

+ > To use the secure network access option, you must enable Microsoft.Storage [service endpoint](../../virtual-network/virtual-network-service-endpoints-overview.md) on the Application and Database subnets. You can learn more about storage account network security in [this documentation](../../storage/common/storage-network-security.md). Private endpoint on managed storage account is not currently supported in this scenario.

+

+

+ When you choose to limit network access to specific virtual networks, Azure Center for SAP solutions service accesses this storage account using [**trusted access**](../../storage/common/storage-network-security.md?tabs=azure-portal#grant-access-to-trusted-azure-services) based on the managed identity associated with the VIS resource.

+In this how-to guide, you learn how to configure alerts in Azure Monitor for SAP solutions. You can configure alerts and notifications from the [Azure portal](https://azure.microsoft.com/features/azure-portal) using its browser-based interface.

+## View and manage alerts in a centralized experience (Preview)

+This enhanced view introduces powerful capabilities that streamline alert management, providing a unified view of all alerts and alert rules across various providers. This consolidated approach enables you to efficiently manage and monitor alerts, improving your overall experience with Azure Monitor for SAP Solutions.

+- **Centralized Alert Management**:

+Gain a holistic view of all alerts fired across different providers within a single, intuitive interface. With the new Alerts experience, you can easily track and manage alerts from various sources in one place, providing a comprehensive overview of your SAP landscape's health.

+- **Unified Alert Rules**:

+Simplify your alert configuration by centralizing all alert rules across different providers. This streamlined approach ensures consistency in rule management, making it easier to define, update, and maintain alert rules for your SAP solutions.

+- **Grid View for Rule Status and Bulk Operations**:

+Efficiently manage your alert rules using the grid view, allowing you to see the status of all rules and make bulk changes with ease. Enable or disable multiple rules simultaneously, providing a seamless experience for maintaining the health of your SAP environment.

+- **Alert Action Group Management**:

+Take control of your alert action groups directly from the new Alerts experience. Manage and configure alert action groups effortlessly, ensuring that the right stakeholders are notified promptly when critical alerts are triggered.

+- **Alert Processing Rules for Maintenance Periods**

+Enable alert processing rules, a powerful feature that allows you to take specific actions or suppress alerts during maintenance periods. Customize the behavior of alerts to align with your maintenance schedule, minimizing unnecessary notifications and disruptions.

+- **Export to CSV**:

+Facilitate data analysis and reporting by exporting fired alerts and alert rules to CSV format. This feature empowers you to share, analyze, and archive alert data seamlessly, supporting your organization's reporting and compliance requirements.

+To access the new Alerts experience in Azure Monitor for SAP Solutions:

+1. Navigate to the Azure portal.

+1. Select your Azure Monitor for SAP Solutions instance.

+ :::image type="content" source="./media/get-alerts-portal/new-alerts-view.png" alt-text="Screenshot showing central alerts view." lightbox="./media/get-alerts-portal/new-alerts-view.png":::

+1. Click on the "Alerts" tab to explore the enhanced alert management capabilities.

+1. Check **Add vector search to this search index.** This option tokenizes your content and generates embeddings.

+1. Select **Azure OpenaI - text-embedding-ada-002**. This embedding model accepts a maximum of 8192 tokens for each chunk. Data chunking is internal and nonconfigurable.

+1. In Upload files, select the four files and then select **Upload**. File size limit is 16 MB.

+The playground gives you options for configuring and monitoring chat. On the right, model configuration determines which model formulates an answer using the search results from Azure AI Search. The input token progress indicator keeps track of the token count of the question you submit.

+Advanced settings on the left determine how much flexibility the chat model has in supplementing the grounding data, and how many chunks are provided to the model to generate its response.

+ :::image type="content" source="media/search-get-started-rag/azure-openai-studio-advanced-settings.png" alt-text="Screenshot of the advanced settings.":::

+1. Start with these advanced settings:

+ + Retrieved documents set to 20. Maximum documents give the model more information to work with when generating responses. The tradeoff for maximum documents is increased query latency, but you can experiment with chat replay to find the right balance.

+ Queries that require deeper analysis or language understanding, such as "how many speeches are in the vector store", will probably fail. Remember that the search engine looks for chunks having exact or similar terms, phrases, or construction to the query. And while the model might understand the question, if search results are chunks from speeches, it's not the right information to answer that kind of question.

+ Finally, chats are constrained by the number of documents (chunks) returned in the response (limited to 3-20 in Azure OpenAI Studio playground). As you can imagine, posing a question about "all of the titles" requires a full scan of the entire vector store. You could modify the generated code (assuming you [deploy the solution](/azure/ai-services/openai/use-your-data-quickstart#deploy-your-model)) to allow for [service-side exhaustive search](vector-search-how-to-create-index.md#add-a-vector-search-configuration) on your queries.

+If you need customization and tuning that the playground can't provide, take a look at code samples that demonstrate the full range of APIs for RAG applications based on Azure AI Search. Samples are available in [Python](https://github.com/Azure/azure-search-vector-samples/tree/main/demo-python), [C#](https://github.com/Azure/azure-search-vector-samples/tree/main/demo-dotnet), and [JavaScript](https://github.com/Azure/azure-search-vector-samples/tree/main/demo-javascript).

+- **Review [MicrosoftΓÇÖs Enterprise access model](/security/privileged-access-workstations/privileged-access-access-model)**.

+> Ensure that any actions taken are performed from a trusted device, built from a [clean source](/security/privileged-access-workstations/privileged-access-access-model). For example, use a fresh, [privileged access workstation](/security/privileged-access-workstations/privileged-access-deployment).

+|**Remove unnecessary admin users** | Remove unnecessary members from Domain Admins, Backup Operators, and Enterprise Admin groups. For more information, see [Securing Privileged Access](/security/privileged-access-workstations/overview). |

+- This quickstart assumes that you already have an Azure Storage account. If you don't have one yet, [create an Azure Storage account](../storage/common/storage-account-create.md).

+> [!NOTE]

+[Use Application Insights Java In-Process Agent in Azure Spring Apps](./how-to-application-insights.md)

+[Use Application Insights Java In-Process Agent in Azure Spring Apps](how-to-application-insights.md)

+[Quickstart: Monitoring Azure Spring Apps with logs, metrics, and tracing](quickstart-logs-metrics-tracing.md)

+[Use Application Insights Java In-Process Agent in Azure Spring Apps](how-to-application-insights.md)

+> [!NOTE]

+Each of the example scenarios in this article uses the following configuration for the Elastic SAN:

+Customers using NFS Azure file shares can now take point-in-time snapshots of file shares. This enables users to roll back their entire filesystem to a previous point in time, or restore specific files that were accidentally deleted or corrupted. Customers using this feature can perform share-level snapshot management operations via the Azure portal, REST API, Azure PowerShell, and Azure CLI. This feature is now available in all Azure public cloud regions except West US 2. [Learn more](storage-files-how-to-mount-nfs-shares.md#nfs-file-share-snapshots).

+Customers using NFS Azure file shares can create, list, and delete NFS Azure file share snapshots. This capability allows users to roll back entire file systems or recover files that were accidentally deleted or corrupted.

+NFS Azure file share snapshots are available in all Azure public cloud regions except West US 2.

+ - [NFS file share snapshots](storage-files-how-to-mount-nfs-shares.md#nfs-file-share-snapshots)

+ Title: Write to a Delta Table in Dale Lake Storage Gen2 (Azure Stream Analytics)

+> * Deploy an event generator that sends sample data to your event hub

+> * Configure Azure Data Lake Storage Gen2 with a delta table

+Before you start, complete the following steps:

+* Deploy the TollApp event generator to Azure, use this link to [Deploy TollApp Azure Template](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-stream-analytics%2Fmaster%2FSamples%2FTollApp%2FVSProjects%2FTollAppDeployment%2Fazuredeploy.json). Set the 'interval' parameter to 1. Create and use a new resource group for this step.

+1. Select **All services** on the left menu.

+1. Move the mouse over **Stream Analytics jobs** in the **Analytics** section, and select **+ (plus)**.

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/all-services-stream-analytics.png" alt-text="Screenshot that shows the selection of Stream Analytics jobs in the All services page.":::

+1. Select **Create a resource** in the upper left-hand corner of the Azure portal.

+1. Select **Analytics** > **Stream Analytics job** from the results list.

+1. On the **New Stream Analytics job** page, follow these steps:

+

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/create-job.png" alt-text="Screenshot that shows the Create Stream Analytics job page.":::

+1. Select **Review + create** at the bottom of the page.

+1. On the **Review + create** page, review settings, and select **Create** to create a Stream Analytics page.

+1. On the deployment page, select **Go to resource** to navigate to the **Stream Analytics job** page.

+3. Select **+ Add input** and **Event hub**.

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/add-input.png" alt-text="Screenshot that shows the Inputs page.":::

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/select-event-hub.png" alt-text="Screenshot that shows the selection of the input event hub.":::

+2. Select **+ Add output** > **Blob storage/ADLS Gen2**.

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/output-type.png" alt-text="Screenshot that shows the Outputs page.":::

+1. Fill the output form with the following details and select **Save**:

+ 4. For **Storage account**, choose the ADLS Gen2 account (the one that starts with **tollapp**) you created.

+ 5. For **container**, select **Create new** and provide a unique **container name**.

+ 6. For **Event Serialization Format**, select **Delta Lake (Preview)**. Although Delta lake is listed as one of the options here, it isn't a data format. Delta Lake uses versioned Parquet files to store your data. To learn more about [Delta lake](write-to-delta-lake.md).

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/configure-output.png" alt-text="Screenshot that shows configuration of the output.":::

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/configure-query.png" alt-text="Screenshot that shows query for the job.":::

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/start-job-menu.png" alt-text="Screenshot that shows the selection of Start job button on the Overview page.":::

+1. On the **Start job** page, confirm that **Now** is selected for Job output start time, and then select **Start** at the bottom of the page.

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/start-job-page.png" alt-text="Screenshot that shows the selection of Start job page.":::

+1. After few minutes, in the portal, find the storage account & the container that you've configured as output for the job. You can now see the delta table in the folder specified in the container. The job takes a few minutes to start for the first time, after it's started, it will continue to run as the data arrives.

+ :::image type="content" source="./media/write-to-delta-table-data-lake-storage/output-data.png" alt-text="Screenshot that shows output data files in the container." lightbox="./media/write-to-delta-table-data-lake-storage/output-data.png":::

+If you haven't already enabled [single sign-on](#single-sign-on-sso) or saved your credentials locally, you'll also need to authenticate to the session host when launching a connection. The following list describes which types of authentication each Azure Virtual Desktop client currently supports. Some clients might require a specific version to be used, which you can find in the link for each authentication type.

+|Web client | Username and password<br>[Microsoft Entra authentication](configure-single-sign-on.md) |

+|Android client | Username and password<br>[Microsoft Entra authentication](configure-single-sign-on.md) |

+|iOS client | Username and password<br>[Microsoft Entra authentication](configure-single-sign-on.md) |

+|macOS client | Username and password <br>Smart card: support for smart card-based sign in using smart card redirection at the Winlogon prompt when NLA is not negotiated.<br>[Microsoft Entra authentication](configure-single-sign-on.md) |

+- You can't use some Azure Virtual Desktop features when session hosts running on Azure Stack HCI, such as:

+ - [Per-user access pricing](licensing.md)

+ -DomainAccountType "ComputerAccount"

+You can install the [Remote Desktop client for Windows](./users/connect-windows.md) on either a per-system or per-user basis. Installing it on a per-system basis installs the client on the machines for all users by default, and administrators control updates. Per-user installation installs the application to a subfolder within the local AppData folder of each user's profile, enabling users to install updates without needing administrative rights.

+To execute the following commands, get and use the [Azure PowerShell module](/powershell/azure/what-is-azure-powershell).

+This article describes how to expand managed disks for a Linux virtual machine (VM). You can [add data disks](add-disk.md) to provide for additional storage space, and you can also expand an existing data disk. The default virtual hard disk size for the operating system (OS) is typically 30 GB on a Linux VM in Azure. This article covers expanding either OS disks or data disks. You can't expand the size of striped volumes.

+In the case of expanding a data disk when there are several data disks present on the VM, it may be difficult to relate the Azure LUNs to the Linux devices. If the OS disk needs expansion, it is clearly labeled in the Azure portal as the OS disk.

+Here we can see, for example, the `/opt/db/data` filesystem is nearly full, and is located on the `/dev/sdd1` partition. The output of `df` shows the device path regardless of whether the disk is mounted by device path or the (preferred) UUID in the fstab. Also take note of the Type column, indicating the format of the filesystem. This is important later.

+Now locate the LUN that correlates to `/dev/sdd` by examining the contents of `/dev/disk/azure/scsi1`. The output of the following `ls` command shows that the device known as `/dev/sdd` within the Linux OS is located at LUN1 when looking in the Azure portal.

+If a data disk was expanded without downtime using the procedure mentioned previously, the disk size won't be changed until the device is rescanned, which normally only happens during the boot process. This rescan can be called on-demand with the following procedure. In this example we have detected using the methods in this document that the data disk is currently `/dev/sda` and has been resized from 256 GiB to 512 GiB.

+1. Expand the partition containing this PV using *growpart*, the device name, and partition number. Doing so expands the specified partition to use all the free contiguous space on the device.

+Complete reference documentation and samples for the REST API are available in the [Azure Monitor REST reference article](/rest/api/monitor).

+>

+> You can't expand the size of striped volumes.