- Use the `authentication-certificate` policy to authenticate with a backend service using a client certificate. When the certificate is [installed into API Management](./api-management-howto-mutual-certificates.md) first, identify it first by its thumbprint or certificate ID (resource name).

-description: Migrate your Azure API Management instance in-place from stv1 to stv2 compute platform. Follow these migration steps if your instance is deployed (injected) in an external or internal VNet.

-* [**Option 1: Keep the same subnet**](#option-1-migrate-and-keep-same-subnet) - Migrate the instance in-place and keep the instances's existing subnet configuration. You can choose whether the API Management instance's original VIP address is preserved (recommended) or whether a new VIP address will be generated. Currently, the [Migrate to Stv2](/rest/api/apimanagement/api-management-service/migratetostv2) REST API supports migrating the instance using the same subnet configuration.

-* [**Option 2: Change to a new subnet**](#option-2-migrate-and-change-to-new-subnet) - Migrate your instance by specifying a different subnet in the same or a different VNet. After migration, optionally migrate back to the instance's original subnet. The migration process changes the VIP address(es) of the instance. After migration, you need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address(es). Currently, the **Platform migration** blade in the Azure portal supports this migration option.

-* For certain migration options, the VIP address (or addresses, for a multi-region deployment) of the instance will change. If you migrate and keep the same subnet configuration, you can choose to preserve the VIP address or a new public VIP will be generated.

- [!INCLUDE [api-management-migration-no-preserve-ip](../../includes/api-management-migration-no-preserve-ip.md)]

- * After successful migration, the old compute is automatically decommissioned after a short period. Using the **Platform migration** blade in the portal, you can enable a migration setting to retain the old gateway for 48 hours. *The 48 hour delay option is only available for VNet-injected services.*

-You can migrate your API Management instance to the `stv2` platform keeping the existing subnet configuration, which simplifies your migration. Currently, you can use the Migrate to Stv2 REST API to migrate the instance using the same subnet configuration.

- With this option, the `stv1` compute is retained for a period by default after migration is complete so that you can validate the migrated instance and confirm the network and DNS configuration.

-|Internal | New VIP | No downtime | Retained by default for 4 hours to allow you to update network dependencies |

-### Migration script

-### Migration steps

-1. On the **Platform migration** page, in **Step 1**, review migration requirements and prerequisites.

-1. In **Step 2**, choose migration settings:

- * Select a location to migrate.

- * Select the **Virtual network**, **Subnet**, and optional **Public IP address** you want to migrate to.

-

- :::image type="content" source="media/migrate-stv1-to-stv2-vnet/select-location.png" alt-text="Screenshot of selecting network migration settings in the portal." lightbox="media/migrate-stv1-to-stv2-vnet/select-location.png":::

- * Select either **Return to original subnet as soon as possible** or **Stay in the new subnet and keep stv1 compute around for 48 hours** after migration. If you choose the former, the `stv1` compute will be deleted approximately 15 minutes after migration, allowing you to proceed directly with [manual migration back to the original subnet](#optional-migrate-back-to-original-subnet) if desired. If you choose the latter, the `stv1` compute is retained for 48 hours. You can use this period to validate your network settings and connectivity.

- :::image type="content" source="media/migrate-stv1-to-stv2-vnet/enable-retain-gateway.png" alt-text="Screenshot of options to retain stv1 compute in the portal." lightbox="media/migrate-stv1-to-stv2-vnet/enable-retain-gateway.png":::

-1. In **Step 3**, confirm you want to migrate, and select **Migrate**.

- Yes, you can preserve the IP address by [migrating and keeping the same subnet](#option-1-migrate-and-keep-same-subnet).

-

- API requests remain responsive during migration. Infrastructure configuration (such as custom domains, locations, and CA certificates) is locked for 30 minutes. In scenarios where you migrate to a new subnet, after migration, you'll need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address.

- The expected duration for a migration to a new VNet configuration is approximately 45 minutes. The indicator to check if the migration was already performed is to check if Status of your instance is back to **Online** and not **Updating**.

- When migrating and changing to a new VIP, after migration there is a short window if time during which the old gateway continues to serve traffic and you can confirm your network settings. See [Confirm settings before old gateway is purged](#confirm-settings-before-old-gateway-is-purged)

- - Currently, you can only upgrade to the same subnet in a single pass when using the [Migrate to stv2 REST API](#option-1-migrate-and-keep-same-subnet).

-

- Currently, if you use the **Platform migration** blade in the portal, you need to migrate to a new subnet and then migrate back to the original subnet:

- - The old gateway takes between 15 mins to 45 mins to vacate the subnet, so that you can initiate the move. However, you can enable a migration setting to retain the old gateway for 48 hours.

- - Ensure that the old subnet's networking for [NSG](./virtual-network-reference.md#required-ports) and [firewall](./api-management-using-with-vnet.md?tabs=stv2#force-tunnel-traffic-to-on-premises-firewall-using-expressroute-or-network-virtual-appliance) is updated for `stv2` dependencies.

- - Subnet IP address allocation is nondeterministic, therefore the original ILB (ingress) IP for "internal mode" deployments may change when you move back to the original subnet. This would require a DNS change if you're using A records.

- - By default, the old and the new managed gateways coexist for 15 mins, which is a small window of time to validate the deployment. You can enable a migration setting to retain the old gateway for 48 hours. This change keeps the old and the new managed gateways active to receive traffic and facilitate validation.

-| 1.0.2| v1 | v1.26, v1.27, v1.28, v1.29 | ECDSA + RSA certificate support for both Ingress and Gateway API, Ingress fixes, Server-sent events support |

-is in the process of being created, updated or deleted.</p>

-<p>BackendTLSPolicy is the schema for the BackendTLSPolicys API</p>

-<p>Note: Override is currently not supported and will result in a validation error.

-<p>BackendTLSPolicySpec defines the desired state of BackendTLSPolicy</p>

-<p>Note: Override is currently not supported and will result in a validation error.

-<p>CommonTLSPolicy is the schema for the CommonTLSPolicy API</p>

-<p>Verify provides the options to verify the backend certificate</p>

-<p>CommonTLSPolicyVerify defines the schema for the CommonTLSPolicyVerify API</p>

-<p>CaCertificateRef is the CA certificate used to verify peer certificate of

-the backend.</p>

-certificate of the backend.</p>

-<code>PolicyTargetReference</code><br/>

-<a href="https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.PolicyTargetReference">

-Gateway API .PolicyTargetReference

-(Members of <code>PolicyTargetReference</code> are embedded into this type.)

-<p>If a SectionNames is specified, but does not exist on the targeted object,

-the Policy will fail to attach, and the policy implementation will record

-<p>Note: Override is currently not supported and will result in a validation error.

-<p>Note: Override is currently not supported and will result in a validation error.

-<td>&nbsp;</td>

-<td>&nbsp;</td>

-<td>&nbsp;</td>

-<p>HTTPSpecifiers defines the schema for HTTP HealthCheck check specification</p>

-header name are invalid and will be rejected.

-<h3 id="alb.networking.azure.io/v1.HealthCheckPolicy">HealthCheckPolicy

-</h3>

-<p>HealthCheckPolicy is the schema for the HealthCheckPolicy API</p>

-<tbody><tr><td><p>&#34;Accepted&#34;</p></td>

-<td><p>HealthCheckPolicyReasonAccepted is used to set the HealthCheckPolicyConditionReason to Accepted

-When the given HealthCheckPolicy is correctly configured</p>

-<td><p>HealthCheckPolicyReasonInvalid is the reason when the HealthCheckPolicy isn&rsquo;t Accepted</p>

-<td><p>HealthCheckPolicyReasonInvalidGroup is used when the group is invalid</p>

-<td><p>HealthCheckPolicyReasonInvalidKind is used when the kind/group is invalid</p>

-<td><p>HealthCheckPolicyReasonInvalidName is used when the name is invalid</p>

-<td><p>HealthCheckPolicyReasonInvalidPort is used when the port is invalid</p>

-<td><p>HealthCheckPolicyReasonInvalidService is used when the Service is invalid</p>

-<td><p>HealthCheckPolicyReasonNoTargetReference is used when there&rsquo;s no target reference</p>

-<td><p>HealthCheckPolicyReasonOverrideNotSupported is used when the override isn&rsquo;t supported</p>

-<td><p>HealthCheckPolicyReasonRefNotPermitted is used when the ref isn&rsquo;t permitted</p>

-<td><p>HealthCheckPolicyReasonSectionNamesNotPermitted is used when the section names aren&rsquo;t permitted</p>

-<td><p>HealthCheckPolicyConditionAccepted is used to set the HealthCheckPolicyConditionType to Accepted</p>

-<td><p>HealthCheckPolicyConditionResolvedRefs is used to set the HealthCheckPolicyCondition to ResolvedRefs</p>

-<p>HealthCheckPolicyConfig defines the schema for HealthCheck check specification</p>

-<p>UnhealthyThreshold is the number of consecutive failed HealthCheck checks</p>

-<p>HealthyThreshold is the number of consecutive successful HealthCheck checks</p>

-<p>HealthCheckPolicySpec defines the desired state of HealthCheckPolicy</p>

-<td><p>HTTP implies that the service uses HTTP</p>

-<td><p>HTTPS implies that the service uses HTTPS</p>

-<td><p>TCP implies that the service uses plain TCP</p>

-<p>RoutePolicy is the schema for the RoutePolicy API</p>

-<p>Note: Override is currently not supported and will result in a validation error.

-<p>RoutePolicySpec defines the desired state of RoutePolicy</p>

-<p>Note: Override is currently not supported and will result in a validation error.

-<p>RouteTimeouts defines the schema for Timeouts specification</p>

-<p>SessionAffinity defines the schema for Session Affinity specification</p>

-| interval | How often in seconds health probes should be sent to the backend target. The minimum interval must be > 0 seconds. |

-| timeout | How long in seconds the request should wait until it's marked as a failure The minimum interval must be > 0 seconds. |

-| protocol | HTTP or HTTPS¹ |

-¹ HTTPS will be used when a backendTLSPolicy references a target backend service (for Gateway API implementation) or IngressExtension with a backendSetting protocol of HTTPS (for Ingress API implementation) is specified.

-In this example, the health probe emitted by Application Gateway for Containers sends the hostname contoso.com to the pods that make up _test-service_. The request path is `/`, a probe is emitted every 5 seconds and wait 3 seconds before determining the connection has timed out. If a response is received, an HTTP response code between 200 and 299 (inclusive of 200 and 299) is considered healthy, all other responses are considered unhealthy.

- "frontendPort": "80",

- "tlsCipher": "-",

-[  ](./media/how-to-url-redirect-ingress-api/url-redirect.png#lightbox)

-3. Deploy sample HTTP application

- Apply the following deployment.yaml file on your cluster to deploy a sample TLS certificate to demonstrate redirect capabilities.

-

- kubectl apply -f https://trafficcontrollerdocs.blob.core.windows.net/examples/https-scenario/ssl-termination/deployment.yaml

- This command creates the following on your cluster:

- - A namespace called `test-infra`

- - One service called `echo` in the `test-infra` namespace

- - One deployment called `echo` in the `test-infra` namespace

- - One secret called `listener-tls-secret` in the `test-infra` namespace

- --version 1.0.2 \

- --version 1.0.2 \

-| alb-controller | 2/2 | 2 | 2 | 18d | alb-controller | mcr.microsoft.com/application-lb/images/alb-controller:**1.0.2** | app=alb-controller |

-| alb-controller-bootstrap | 1/1 | 1 | 1 | 18d | alb-controller-bootstrap | mcr.microsoft.com/application-lb/images/alb-controller-bootstrap:**1.0.2** | app=alb-controller-bootstrap |

-In this example, the ALB controller version is **1.0.2**.

-By default, Ingress controller will provision an HTTP GET probe for the exposed pods.

-description: This article provides documentation on the annotations specific to the Application Gateway Ingress Controller.

-The Kubernetes Ingress resource can be annotated with arbitrary key/value pairs. AGIC relies on annotations to program Application Gateway features, which aren't configurable using the Ingress YAML. Ingress annotations are applied to all HTTP settings, backend pools, and listeners derived from an ingress resource.

-For an Ingress resource to be observed by AGIC, it **must be annotated** with `kubernetes.io/ingress.class: azure/application-gateway`. Only then AGIC works with the Ingress resource in question.

-| Annotation Key | Value Type | Default Value | Allowed Values |

-The following annotation allows the backend path specified in an ingress resource to be rewritten with prefix specified in this annotation. It allows users to expose services whose endpoints are different than endpoint names used to expose a service in an ingress resource.

-In the previous example, you've defined an ingress resource named `go-server-ingress-bkprefix` with an annotation `appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"`. The annotation tells application gateway to create an HTTP setting, which has a path prefix override for the path `/hello` to `/test/`.

-> [!NOTE]

-> In the above example, only one rule is defined. However, the annotations are applicable to the entire ingress resource, so if a user defined multiple rules, the backend path prefix would be set up for each of the paths specified. If a user wants different rules with different path prefixes (even for the same service), they would need to define different ingress resources.

-This annotation allows us to specify the host name that Application Gateway should use while talking to the Pods.

-Application Gateway [can be configured](./application-gateway-probe-overview.md) to send custom health probes to the backend address pool. When these annotations are present, Kubernetes Ingress controller [creates a custom probe](./application-gateway-create-probe-portal.md) to monitor the backend application and applies the changes to the application gateway.

-`health-probe-hostname`: This annotation allows a custom hostname on the health probe.<br>

-`health-probe-port`: This annotation configures a custom health probe port.<br>

-`health-probe-path`: This annotation defines a path for the health probe.<br>

-`health-probe-status-code`: This annotation allows the health probe to accept different HTTP status codes.<br>

-`health-probe-interval`: This annotation defines the interval that the health probe runs at.<br>

-`health-probe-timeout`: This annotation defines how long the health probe will wait for a response before failing the probe.<br>

-`health-probe-unhealthy-threshold`: This annotation defines how many health probes must fail for the backend to be marked as unhealthy.

-Application Gateway [can be configured](./redirect-overview.md) to automatically redirect HTTP URLs to their HTTPS counterparts. When this annotation is present and TLS is properly configured, Kubernetes Ingress controller creates a [routing rule with a redirection configuration](./redirect-http-to-https-portal.md#add-a-routing-rule-with-a-redirection-configuration) and applies the changes to your Application Gateway. The redirect created will be HTTP `301 Moved Permanently`.

-`connection-draining`: This annotation allows us to specify whether to enable connection draining.

-`connection-draining-timeout`: This annotation allows us to specify a timeout, after which Application Gateway terminates the requests to the draining backend endpoint.

-The following annotation allows you to specify whether to enable cookie based affinity.

-The following annotation allows you to specify the request timeout in seconds, after which Application Gateway fails the request if response is not received.

-The following annotation allows you to specify whether to expose this endpoint on Private IP of Application Gateway.

-> [!NOTE]

-> * For Application Gateway that doesn't have a private IP, Ingresses with `appgw.ingress.kubernetes.io/use-private-ip: "true"` is ignored. This is reflected in the controller logs and ingress events for those ingresses with `NoPrivateIP` warning.

-The annotation allows you to configure a frontend listener to use different ports other than 80/443 for http/https.

-If the port is within the App Gw authorized range (1 - 64999), this listener will be created on this specific port. If an invalid port or no port is set in the annotation, the configuration will fall back on default 80 or 443.

->External request will need to target http://somehost:8080 instead of http://somehost.

-The following annotation allows you to specify the protocol that Application Gateway should use while communicating with the pods. Supported Protocols are `http` and `https`.

-> [!NOTE]

-> While self-signed certificates are supported on Application Gateway, currently AGIC only supports `https` when pods are using a certificate signed by a well-known CA.

->

-> Don't use port 80 with HTTPS and port 443 with HTTP on the pods.

-Application Gateway can be configured to accept multiple hostnames. The hostname-extention annotation allows for this by letting you define multiple hostnames including wildcard hostnames. This will append the hostnames onto the FQDN that is defined in the ingress spec.rules.host on the frontend listener so it is [configured as a multisite listener.](./multiple-site-overview.md)

-> [!NOTE]

-> In the above example the listener would be configured to accept traffic for the hostnames "hostname1.contoso.com" and "hostname2.contoso.com"

-This annotation allows you to attach an already created WAF policy to the list paths for a host within a Kubernetes Ingress resource being annotated.

-> [!NOTE]

-> The WAF policy will be applied to both /ad-server and /auth URLs.

-The SSL certificate [can be configured to Application Gateway](/cli/azure/network/application-gateway/ssl-cert#az-network-application-gateway-ssl-cert-create) either from a local PFX certificate file or a reference to an Azure Key Vault unversioned secret ID. When the annotation is present with a certificate name and the certificate is pre-installed in Application Gateway, Kubernetes Ingress controller will create a routing rule with a HTTPS listener and apply the changes to your App Gateway. appgw-ssl-certificate annotation can also be used together with ssl-redirect annotation in case of SSL redirect.

-Please refer to appgw-ssl-certificate feature for more details.

-> Annotation "appgw-ssl-certificate" will be ignored when TLS Spec is defined in ingress at the same time. If a user wants different certs with different hosts(multi tls certificate termination), they would need to define different ingress resources.

-Users can configure a ssl profile on the Application Gateway per listener. When the annotation is present with a profile name and the profile is pre-installed in the Application Gateway, Kubernetes Ingress controller will create a routing rule with a HTTPS listener and apply the changes to your App Gateway.

-Users now can configure their own root certificates to Application Gateway to be trusted via AGIC. The annotation appgw-trusted-root-certificate can be used together with annotation backend-protocol to indicate end-to-end ssl encryption, multiple root certificates, separated by comma, if specified, for example, "name-of-my-root-cert1,name-of-my-root-certificate2".

-The following annotation allows you to assign an existing rewrite rule set to the corresponding request routing rule.

-> [!Note]

-> [Application Gateway for Containers](https://aka.ms/agc) has been released, which introduces numerous performance, resilience, and feature changes. Please consider leveraging Application Gateway for Containers for your next deployment.

-> URL Rewrite rules for Application Gateway for Containers may be found [here for Gateway API](./for-containers/how-to-url-rewrite-gateway-api.md) and [here for Ingress API](for-containers/how-to-url-rewrite-ingress-api.md).

-> Header Rewrite rules for Application Gateway for Containers may be found [here for Gateway API](./for-containers/how-to-header-rewrite-gateway-api.md).

-> [!Note]

-> This feature is supported since 1.6.0-rc1. Use [`appgw.ingress.kubernetes.io/rewrite-rule-set`](#rewrite-rule-set), which allows using an existing rewrite rule set on Application Gateway.

-Application Gateway allows you to rewrite selected content of requests and responses. With this feature, you can translate URLs, query string parameters as well as modify request and response headers. It also allows you to add conditions to ensure that the URL or the specified headers are rewritten only when certain conditions are met. These conditions are based on the request and response information. Rewrite Rule Set Custom Resource brings this feature to AGIC.

-HTTP headers allow a client and server to pass additional information with a request or response. By rewriting these headers, you can accomplish important tasks, such as adding security-related header fields like HSTS/ X-XSS-Protection, removing response header fields that might reveal sensitive information, and removing port information from X-Forwarded-For headers.

-With URL rewrite capability, you can: - Rewrite the host name, path and query string of the request URL - Choose to rewrite the URL of all requests or only those requests which match one or more of the conditions you set. These conditions are based on the request and response properties (request header, response header and server variables). - Choose to route the request based on either the original URL or the rewritten URL

-This annotation allows for application gateway ingress controller to explicitly set the priority of the associated [Request Routing Rules.](./multiple-site-overview.md#request-routing-rules-evaluation-order)

-In the above example the request routing rule would have a priority of 10 set.

-Application Gateway Ingress Controller (AGIC) deployed as an AKS add-on allows you to enable and disable the add-on with one line in Azure CLI. The life cycle of the Application Gateway will differ when you disable the AGIC add-on, depending on if the Application Gateway was created by the AGIC add-on, or if it was deployed separately from the AGIC add-on. You can run the same command to re-enable the AGIC add-on if you ever disable it, or to enable the AGIC add-on using an existing AKS cluster and Application Gateway.

-If the AGIC add-on automatically deployed the Application Gateway for you when you first set everything up, then disabling the AGIC add-on will by default delete the Application Gateway based on a couple criteria. There are two criteria that the AGIC add-on looks for to determine if it should delete the associated Application Gateway when you disable it:

-If both criteria are met, then the AGIC add-on will delete the Application Gateway it created when the add-on is disabled; however, it won't delete the public IP or the subnet in which the Application Gateway was deployed with/in. If the first criteria is not met, then it won't matter if the Application Gateway has the "created-by: ingress-appgw" tag - disabling the add-on won't delete the Application Gateway. Likewise, if the second criteria is not met, i.e. the Application Gateway lacks that tag, then disabling the add-on won't delete the Application Gateway in the MC_* node resource group.

-For more details on how to enable the AGIC add-on using an existing Application Gateway and AKS cluster, see [AGIC add-on brownfield deployment](tutorial-ingress-controller-add-on-existing.md).

-> If you use [Cloud Shell](https://shell.azure.com/), you don't need to install Helm. Azure Cloud Shell comes with Helm version 3. Skip the first step and just add the AGIC Helm repository.

-1. Install [Helm](/azure/aks/kubernetes-helm) and run the following to add `application-gateway-kubernetes-ingress` helm package:

- - *Kubernetes RBAC enabled* AKS cluster

- ```bash

- kubectl create serviceaccount --namespace kube-system tiller-sa

- kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller-sa

- helm init --tiller-namespace kube-system --service-account tiller-sa

- ```

-2. Add the AGIC Helm repository:

- ```bash

- helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/

- helm repo update

- ```

-In the first few steps, we install Helm's Tiller on your Kubernetes cluster. Use [Cloud Shell](https://shell.azure.com/) to install the AGIC Helm package:

-1. Add the `application-gateway-kubernetes-ingress` helm repo and perform a helm update

- helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/

-1. Install Helm chart `application-gateway-kubernetes-ingress` with the `helm-config.yaml` configuration from the previous step

- helm install -f <helm-config.yaml> application-gateway-kubernetes-ingress/ingress-azure

- helm install ./helm/ingress-azure \

- --name ingress-azure \

- ingress-azure application-gateway-kubernetes-ingress/ingress-azure

-existing Application Gateway, but need to host it on a [VM](https://azure.microsoft.com/services/virtual-machines/). We

-are going to reuse the existing Application Gateway and manually configure a listener and backend pools for

-installed in an environment with no pre-existing components.

-Follow the steps below to create a Microsoft Entra [service principal object](../active-directory/develop/app-objects-and-service-principals.md#service-principal-object). Record the `appId`, `password`, and `objectId` values - these values will be used in the following steps.

-1. Create the parameter file that will be used in the Azure Resource Manager template deployment later.

-This step will add the following components to your subscription:

-which we'll use to connect to our new Kubernetes cluster. [Cloud Shell](https://shell.azure.com/) has `kubectl` already installed. We'll use `az` CLI to obtain credentials for Kubernetes.

-[Helm](/azure/aks/kubernetes-helm) is a package manager for Kubernetes. We'll use it to install the `application-gateway-kubernetes-ingress` package.

-1. Install [Helm](/azure/aks/kubernetes-helm) and run the following to add `application-gateway-kubernetes-ingress` helm package:

-2. Add the AGIC Helm repository:

- ```bash

- helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/

- helm repo update

- ```

- helm install -f helm-config.yaml --generate-name application-gateway-kubernetes-ingress/ingress-azure

-* The [non-browsable shares](#non-browsable-share) and [access-based enumeration](#access-based-enumeration) features are currently in preview. You must register each feature before you can use it:

-1. Register the feature:

- ```azurepowershell-interactive

- Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSmbNonBrowsable

- Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSMBAccessBasedEnumeration

- ```

-2. Check the status of the feature registration:

- > [!NOTE]

- > The **RegistrationState** may be in the `Registering` state for up to 60 minutes before changing to `Registered`. Wait until the status is **Registered** before continuing.

- ```azurepowershell-interactive

- Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSmbNonBrowsable

- Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSMBAccessBasedEnumeration

- ```

-You can also use [Azure CLI commands](/cli/azure/feature) `az feature register` and `az feature show` to register the feature and display the registration status.

- This feature will hide directories and files created under a share from users who do not have access permissions to the files or folders under the share. Users will still be able to view the share.

- This feature prevents the Windows client from browsing the share. The share does not show up in the Windows File Browser or in the list of shares when you run the `net view \\server /all` command.

- > [!IMPORTANT]

- > Both the access-based enumeration and non-browsable shares features are currently in preview. If this is your first time using either, refer to the steps in [Before you begin](#before-you-begin) to register either feature.

-* The [non-browsable shares](#non-browsable-share) and [access-based enumeration](#access-based-enumeration) features are currently in preview. You must register each feature before you can use it:

-1. Register the feature:

- ```azurepowershell-interactive

- Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSmbNonBrowsable

- Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSMBAccessBasedEnumeration

- ```

-2. Check the status of the feature registration:

- > [!NOTE]

- > The **RegistrationState** may be in the `Registering` state for up to 60 minutes before changing to `Registered`. Wait until the status is **Registered** before continuing.

- ```azurepowershell-interactive

- Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSmbNonBrowsable

- Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFSMBAccessBasedEnumeration

- ```

-You can also use [Azure CLI commands](/cli/azure/feature) `az feature register` and `az feature show` to register the feature and display the registration status.

- This feature hides directories and files created under a share from users who do not have access permissions. You can still view the share. You can only enable access-based enumeration if the dual-protocol volume uses NTFS security style.

- > [!IMPORTANT]

- > The access-based enumeration and non-browsable shares features are currently in preview. If this is your first time using either, refer to the steps in [Before you begin](#before-you-begin) to register the features.

-description: Learn how to optimize TCO with capacity reservations in Azure NetApp Files.

-# Reserved capacity for Azure NetApp Files

-You can save money on the storage costs for Azure NetApp Files with capacity reservations. Azure NetApp Files reserved capacity offers you a discount on capacity for storage costs when you commit to a reservation for one or three years, optimizing your TCO. A reservation provides a fixed amount of storage capacity for the term of the reservation.

-Azure NetApp Files reserved capacity can significantly reduce your capacity costs for storing data in your Azure NetApp Files volumes. How much you save depends on the total capacity you choose to reserve, and the [service level](azure-netapp-files-service-levels.md) chosen.

-For pricing information about reservation capacity for Azure NetApp Files, see [Azure NetApp Files pricing](https://azure.microsoft.com/pricing/details/netapp/).

-## Reservation terms for Azure NetApp Files

-This section describes the terms of an Azure NetApp Files capacity reservation.

->[!NOTE]

->Azure NetApp Files reserved capacity covers matching capacity pools in the selected service level and region. When using capacity pools configured with [Standard storage with cool access](manage-cool-access.md), only "hot" tier consumption is covered by the reserved capacity benefit.

-### Reservation capacity

-You can purchase Azure NetApp Files reserved capacity in units of 100 TiB and 1 PiB per month for a one- or three-year term for a particular service level within a region.

-### Reservation scope

-Azure NetApp Files reserved capacity is available for a single subscription and multiple subscriptions (shared scope). When scoped to a single subscription, the reservation discount is applied to the selected subscription only. When scoped to multiple subscriptions, the reservation discount is shared across those subscriptions within the customer's billing context.

-A reservation applies to your usage within the purchased scope and cannot be limited to a specific NetApp account, capacity pools, container, or object within the subscription.

-Any capacity reservation for Azure NetApp Files covers only the capacity pools within the service level selected. Add-on features such as cross-region replication and backup are not included in the reservation. As soon as you buy a reservation, the capacity charges that match the reservation attributes are charged at the discount rates instead of the pay-as-you go rates.

-For more information on Azure reservations, see [What are Azure Reservations](../cost-management-billing/reservations/save-compute-costs-reservations.md).

-### Supported service level options

-Azure NetApp Files reserved capacity is available for Standard, Premium, and Ultra service levels in units of 100 TiB and 1 PiB.

-### Requirements for purchase

-To purchase reserved capacity:

-* You must be in the **Owner** role for at least one Enterprise or individual subscription with pay-as-you-go rates.

-* For Enterprise subscriptions, **Add Reserved Instances** must be enabled in the EA portal. Or, if that setting is disabled, you must be an EA Admin on the subscription.

-* For the Cloud Solution Provider (CSP) program, only admin agents or sales agents can buy Azure NetApp Files reserved capacity.

-## Determine required capacity before purchase

-When you purchase an Azure NetApp Files reservation, you must choose the region and tier for the reservation. Your reservation is valid only for data stored in that region and tier. For example, suppose you purchase a reservation for Azure NetApp Files *Premium* service level in US East. That reservation applies to neither *Premium* capacity pools for that subscription in US West nor capacity pools for other service levels (for example, *Ultra* service level in US East). Additional reservations can be purchased.

-Reservations are available for 100-TiB or 1-PiB increments, with higher discounts for 1-PiB increments. When you purchase a reservation in the Azure portal, Microsoft might provide you with recommendations based on your previous usage to help determine which reservation you should purchase.

-Purchasing an Azure NetApp Files reserved capacity does not automatically increase your regional capacity. Azure reservations for Azure NetApp Files are not an on-demand capacity guarantee. If your capacity reservation requires a quota increase, it's recommended you complete that before making the reservation. For more information, see [Regional capacity in Azure NetApp Files](regional-capacity-quota.md).

-## Purchase Azure NetApp Files reserved capacity

-You can purchase Azure NetApp Files reserved capacity through the [Azure portal](https://portal.azure.com/). You can pay for the reservation up front or with monthly payments. For more information about purchasing with monthly payments, see [Purchase Azure reservations with up front or monthly payments](../cost-management-billing/reservations/prepare-buy-reservation.md).

-To purchase reserved capacity:

-1. Navigate to the [**Purchase reservations**](https://portal.azure.com/#blade/Microsoft_Azure_Reservations/CreateBlade/referrer/Browse_AddCommand) blade in the Azure portal.

-2. Select **Azure NetApp Files** to buy a new reservation.

-3. Fill in the required fields as described in the table that appears.

-4. After you select the parameters for your reservation, the Azure portal displays the cost. The portal also shows the discount percentage over pay-as-you-go billing.

-5. In the **Purchase reservations** blade, review the total cost of the reservation. You can also provide a name for the reservation.

-After you purchase a reservation, it is automatically applied to any existing [Azure NetApp Files capacity pools](azure-netapp-files-set-up-capacity-pool.md) that match the terms of the reservation. If you haven't created any Azure NetApp Files capacity pools, the reservation applies when you create a resource that matches the terms of the reservation. In either case, the term of the reservation begins immediately after a successful purchase.

-## Exchange or refund a reservation

-You can exchange or refund a reservation, with certain limitations. For more information about Azure Reservations policies, see [Self-service exchanges and refunds for Azure Reservations](../cost-management-billing/reservations/exchange-and-refund-azure-reservations.md).

-<!--

-### Exchange a reservation

-Exchanging a reservation enables you to receive a prorated refund based on the unused portion of the reservation. You can then apply the refund to the purchase price of a new Azure NetApp Files reservation.

-There's no limit on the number of exchanges you can make. Also, there's no fee associated with an exchange. The new reservation that you purchase must be of equal or greater value than the prorated credit from the original reservation. An Azure NetApp Files reservation can be exchanged only for another Azure NetApp Files reservation, and not for a reservation for any other Azure service.

-### Refund a reservation

-You can cancel an Azure NetApp Files reservation at any time. When you cancel, you'll receive a prorated refund based on the remaining term of the reservation, minus a 12% early termination fee. The maximum refund per year is $50,000.

-Cancelling a reservation immediately terminates the reservation and returns the remaining months to Microsoft. The remaining prorated balance, minus the fee, will be refunded to your original form of purchase. -->

-## Expiration of a reservation

-When a reservation expires, any Azure NetApp Files capacity that you are using under that reservation is billed at the pay-as-you go rate. Reservations don't renew automatically.

-An email notification is sent 30 days prior to the expiration of the reservation, and again on the expiration date. To continue taking advantage of the cost savings that a reservation provides, renew it no later than the expiration date.

-## Need help? Contact us

-If you have questions or need help, [create a support request](https://go.microsoft.com/fwlink/?linkid=2083458).

-## Next steps

-* [What are Azure Reservations?](../cost-management-billing/reservations/save-compute-costs-reservations.md)

-* [Understand how reservation discounts are applied to Azure storage services](../cost-management-billing/reservations/understand-storage-charges.md)

-* [Reserved capacity](reserved-capacity.md) is now generally available (GA)

- Pay-as-you-go pricing is the most convenient way to purchase cloud storage when your workloads are dynamic or changing over time. However, some workloads are more predictable with stable capacity usage over an extended period. These workloads can benefit from savings in exchange for a longer-term commitment. With a one-year or three-year commitment of Azure NetApp Files reserved capacity, you can save up to 34% on sustained usage of Azure NetApp Files. Reserved capacity is available in stackable increments of 100 TiB and 1 PiB on Standard, Premium and Ultra service levels in a given region. Reserved capacity can be used in a single subscription (single-subscription scope), or across multiple subscriptions (shared scope) in the same Azure tenant. Azure NetApp Files reserved capacity benefits are automatically applied to existing Azure NetApp Files capacity pools in the matching region and service level. Azure NetApp Files reserved capacity not only provides cost savings but also improves financial predictability and stability, allowing for more effective budgeting. Additional usage is conveniently billed at the regular pay-as-you-go rate.

- For more detail, see the [Azure NetApp Files reserved capacity](reserved-capacity.md) or see reservations in the Azure portal.

-

-**Automatic deletions are supported for resource group and subscription deployments. Currently, deployments in the history for [management group](deploy-to-management-group.md) and [tenant](deploy-to-tenant.md) deployments aren't automatically deleted.**

-To disable automatic deletions, register the `Microsoft.Resources/DisableDeploymentGrooming` feature flag. When you register the feature flag, you opt out of automatic deletions for the entire Azure subscription. You can't opt out for only a particular resource group. To reenable automatic deletions, unregister the feature flag.

-* **Repeatable results**: Repeatedly deploy your infrastructure throughout the development lifecycle and have confidence your resources are deployed in a consistent manner. Templates are idempotent, which means you can deploy the same template many times and get the same resource types in the same state. You can develop one template that represents the desired state, rather than developing lots of separate templates to represent updates. For example, the following file creates a storage account. If you deploy this template and the storage account with the specified properties already exists , no changes is made.

-| [VMSA-2024-0006](https://www.vmware.com/security/advisories/VMSA-2024-0006.html) ESXi Use-after-free and Out-of-bounds write vulnerability | March 2024 | For ESXi 7.0, Microsoft worked with Broadcom on an AVS specific hotfix as part of the [ESXi 7.0U3o](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-vcenter-server-70u3o-release-notes/https://docsupdatetracker.net/index.html) rollout. For the 8.0 rollout, Azure VMware Solution is deploying [vCenter Server 8.0 U2b & ESXi 8.0 U2b](architecture-private-clouds.md#vmware-software-versions) which is not vulnerable. | Auguest 2024 - Resolved in [ESXi 7.0U3o](https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-vcenter-server-70u3o-release-notes/https://docsupdatetracker.net/index.html) and [vCenter Server 8.0 U2b & ESXi 8.0 U2b](architecture-private-clouds.md#vmware-software-versions) |

-The Premium SKU is a new SKU that supports Bastion features such as Session Recording and Private-Only Bastion. When you deploy bastion, only select the Premium SKU if you need the features that it supports.

-To interact with the linked storage account, the app uses the Azure.Storage.Blobs Library for .NET. Using the [BlobServiceClient](/dotnet/api/azure.storage.blobs.blobserviceclient) class which takes a reference to the account Uri and authenticating [Token](/dotnet/api/azure.core.tokencredentia) such as [DefaultAzureCredential](/dotnet/api/azure.identity.defaultazurecredential).

-If you have questions or need help, [create a support request](https://go.microsoft.com/fwlink/?linkid=2083458).

-When you've deployed Defender for IoT at scale, with several OT sensors, each sensor might detect different aspects of the same device. To prevent duplicated devices in your device inventory, Defender for IoT assumes that any devices found in the same zone, with a logical combination of similar characteristics, is the same device. Defender for IoT automatically consolidates these devices and lists them only once in the device inventory.

-The following table lists the columns available in the Defender for IoT device inventory on the Azure portal. Starred items **(*)** are also available from the OT sensor.

-|Name |Description |

-|||

-|**Authorization** * |Editable. Determines whether or not the device is marked as *authorized*. This value might need to change as the device security changes. |

-|**Business Function** | Editable. Describes the device's business function. |

-| **Class** | Editable. The device's class. <br>Default: `IoT` |

-|**Data source** | The source of the data, such as a micro agent, OT sensor, or Microsoft Defender for Endpoint. <br>Default: `MicroAgent`|

-|**Description** * | Editable. The device's description. |

-| **Device Id** | The device's Azure-assigned ID number. |

-| **Firmware model** | The device's firmware model.|

-| **Firmware vendor** | Editable. The vendor of the device's firmware. |

-| **Firmware version** * |Editable. The device's firmware version. |

-|**First seen** * | The date and time the device was first seen. Shown in `MM/DD/YYYY HH:MM:SS AM/PM` format. On the OT sensor, shown as **Discovered**.|

-|**Importance** | Editable. The device's important level: `Low`, `Medium`, or `High`. |

-| **IPv4 Address** | The device's IPv4 address. |

-|**IPv6 Address** | The device's IPv6 address.|

-|**Last activity** * | The date and time the device last sent an event through to Azure or to the OT sensor, depending on where you're viewing the device inventory. Shown in `MM/DD/YYYY HH:MM:SS AM/PM` format. |

-|**Location** | Editable. The device's physical location. |

-| **MAC Address** * | The device's MAC address. |

-|**Model** *| Editable The device's hardware model. |

-|**Name** * | Mandatory, and editable. The device's name as the sensor discovered it, or as entered by the user. |

-|**Network location** (Public preview) | The device's network location. Displays whether the device is defined as *local* or *routed*, according to the configured subnets. |

-|**OS architecture** | Editable. The device's operating system architecture. |

-|**OS distribution** | Editable. The device's operating system distribution, such as Android, Linux, and Haiku. |

-|**OS platform** * | Editable. The device's operating system, if detected. On the OT sensor, shown as **Operating System**. |

-|**OS version** | Editable. The device's operating system version, such as Windows 10 or Ubuntu 20.04.1. |

-|**PLC mode** * | The device's PLC operating mode, including both the *Key* state (physical / logical) and the *Run* state (logical). If both states are the same, then only one state is listed.<br><br>- Possible *Key* states include: `Run`, `Program`, `Remote`, `Stop`, `Invalid`, and `Programming Disabled`. <br><br>- Possible *Run* states are `Run`, `Program`, `Stop`, `Paused`, `Exception`, `Halted`, `Trapped`, `Idle`, or `Offline`. |

-|**Programming device** * | Editable. Defines whether the device is defined as a *Programming Device*, performing programming activities for PLCs, RTUs, and controllers, which are relevant to engineering stations. |

-|**Protocols** *| The protocols that the device uses. |

-| **Purdue level** | Editable. The Purdue level in which the device exists.|

-|**Scanner device** * | Editable. Defines whether the device performs scanning-like activities in the network. |

-|**Sensor**| The sensor the device is connected to. |

-|**Serial number** *| The device's serial number. |

-| **Site** | The device's site. <br><br>All Enterprise IoT sensors are automatically added to the **Enterprise network** site. |

-| **Slots** | The number of slots the device has. |

-| **Subtype** | Editable. The device's subtype, such as *Speaker* or *Smart TV*. <br>**Default**: `Managed Device` |

-| **Tags** | Editable. The device's tags. |

-|**Type** * | Editable. The device type, such as *Communication* or *Industrial*. <br>**Default**: `Miscellaneous` |

-|**Vendor** *| The name of the device's vendor, as defined in the MAC address. |

-| **VLAN** * | The device's VLAN. |

-|**Zone** | The device's zone. |

-The following columns are available on OT sensors only:

-* For frequently asked questions about Azure DNS, see [Azure DNS FAQ](dns-faq-private.yml).

-* For frequently asked questions about Azure Private DNS, see [Azure Private DNS FAQ](dns-faq.yml).

-> | US | Europe |

-> |||

-> | Central US EUAP | Italy North |

-> | | Spain Central |

-> | | Norway East |

-To learn how to use the Geo-replication feature, see [Use Geo-replication](use-geo-replication.md).

-One way to check the status of your `$export` operation is to go to your storage account's *storage browser* and see whether any `.ndjson` files are present in the export container. If the files aren't present and no other `$export` jobs are running, it's possible that the current job is stuck in a bad state. In this case, you can cancel the `$export` job by calling the FHIR service API with a `DELETE` request. Later, you can requeue the `$export` job and try again.

-For more information about canceling an `$export` operation, see the [Bulk Data Delete Request](https://www.hl7.org/fhir/uv/bulkdata/) documentation from HL7.

-*Figure: Balancing multi-tier applications by using both public and internal Load Balancer*

-| US Gov Arizona | 52.244.67.164, 52.244.67.64, 52.244.66.82, 52.126.52.254, 52.126.53.145, 52.182.49.105, 52.182.49.175 |

-| US Gov Virginia | 52.227.159.157, 52.227.152.90, 23.97.4.36, 13.77.239.182, 13.77.239.190 |

-| US DoD Central | 52.182.49.204, 52.182.52.106 |

-| US DoD Central | 52.182.48.215, 52.182.92.143, 52.182.53.147, 52.182.52.212, 52.182.49.162, 52.182.49.151 |

-| US Gov Arizona | 52.244.67.143, 52.244.65.66, 52.244.65.190, 52.126.50.197, 52.126.49.223, 52.126.53.144, 52.126.36.100 |

-| US Gov Virginia | 13.72.54.205, 52.227.138.30, 52.227.152.44, 13.77.239.177, 13.77.239.140, 13.77.239.187, 13.77.239.184 |

-> The following plans and resources are no longer available or supported with the public release of the **Logic App (Standard)** resource type in Azure regions:

-> Functions Premium plan, App Service Environment v1, and App Service Environment v2. Except with ASEv3, the App Service Plan is unavailable and unsupported.

-The Migration and modernization tool only supports like-for-like migrations currently. The tool doesnΓÇÖt support upgrading the OS version during migration. The migrated machine will have the same OS as the source machine.

-Migration and modernization capabilities support like-for-like migrations currently. We don't support consolidating servers or upgrading the operating system as part of the migration.

-We recommend that you use virtual network flow logs [Virtual network flow logs](vnet-flow-logs-overview.md) for these virtual machine sizes.

-> Virtual Machines that run heavy networking traffic might encounter flow logging failures. We recommend that you migrate NSG flow logs to virtual network flow logs [Virtual network flow logs](vnet-flow-logs-overview.md) for these types of workloads.

-Follow the steps provided in [Create an Azure Red Hat OpenShift cluster](https://learn.microsoft.com/azure/openshift/create-cluster?tabs=azure-cli) until the "Create the cluster" steps, then continue as instructed:

-* [Enable route exchange](quickstart-configure-route-server-portal.md#configure-route-exchange) between the ExpressRoute gateway and the route server in the hub VNet.

-In the control plane, the NVA in the hub VNet will learn about on-premises routes from the ExpressRoute gateway through [route exchange](quickstart-configure-route-server-portal.md#configure-route-exchange) with the route server in the hub. In return, the NVA will send the spoke VNet addresses to the ExpressRoute gateway using the same route server. The route server in both the spoke and hub VNets will then program the on-premises network addresses to the virtual machines in their respective virtual network.

-Azure Route Server supports not only third-party network virtual appliances (NVA) in Azure but also seamlessly integrates with ExpressRoute and Azure VPN gateways. You donΓÇÖt need to configure or manage the BGP peering between the gateway and Azure Route Server. You can enable route exchange between the gateways and Azure Route Server by enabling [branch-to-branch](quickstart-configure-route-server-portal.md#configure-route-exchange) in Azure portal. If you prefer, you can use [Azure PowerShell](quickstart-configure-route-server-powershell.md#route-exchange) or [Azure CLI](quickstart-configure-route-server-cli.md#configure-route-exchange) to enable the route exchange with the Route Server.

-If you enable BGP on the VPN gateway, the gateway learns *On-premises 1* routes dynamically over BGP. For more information, see [How to configure BGP for Azure VPN Gateway](../vpn-gateway/bgp-howto.md). If you donΓÇÖt enable BGP on the VPN gateway, the gateway learns *On-premises 1* routes that are defined in the local network gateway of *On-premises 1*. For more information, see [Create a local network gateway](../vpn-gateway/tutorial-site-to-site-portal.md#LocalNetworkGateway). Whether you enable BGP on the VPN gateway or not, the gateway advertises the routes it learns to the Route Server if route exchange is enabled. For more information, see [Configure route exchange](quickstart-configure-route-server-portal.md#configure-route-exchange).

-* When the same route is learned over ExpressRoute, Azure VPN or an SDWAN appliance, the ExpressRoute network will be preferred by default. You can configure routing preference to influence Route Server route selection. For more information, see [Routing preference (preview)](hub-routing-preference.md).

-description: In this quickstart, you learn how to create and configure an Azure Route Server using the Azure portal.

-# Quickstart: Create and configure Route Server using the Azure portal

-In this quickstart, you configure Azure Route Server to peer with a Network Virtual Appliance (NVA) in your virtual network using the Azure portal. Azure Route Server will learn routes from the NVA and program them on the virtual machines in the virtual network. Azure Route Server will also advertise the virtual network routes to the NVA. For more information, read [Azure Route Server](overview.md).

-* An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

-* Review the [service limits for Azure Route Server](route-server-faq.md#limitations).

-### Sign in to your Azure account and select your subscription

-From a browser, navigate to the [Azure portal](https://portal.azure.com) and sign in with your Azure account.

-### Create a Route Server

-1. Select **+ Create new route server**.

- :::image type="content" source="./media/quickstart-configure-route-server-portal/route-server-landing-page.png" alt-text="Screenshot of Route Server landing page.":::

-1. On the **Create a Route Server** page, enter, or select the required information.

- :::image type="content" source="./media/quickstart-configure-route-server-portal/create-route-server-page.png" alt-text="Screenshot of create Route Server page.":::

- | Subscription | Select the Azure subscription you want to use to deploy the Route Server. |

- | Resource group | Select a resource group to create the Route Server in. If you don't have an existing resource group, you can create a new one. |

- | Name | Enter a name for the Route Server. |

- | Region | Select the region the Route Server will be created in. Select the same region as the virtual network you created previously to see the virtual network in the drop-down. |

- | Virtual Network | Select the virtual network in which the Route Server will be created. You can create a new virtual network or use an existing virtual network. If you're using an existing virtual network, make sure the existing virtual network has enough space for a minimum of a /27 subnet to accommodate the Route Server subnet requirement. If you don't see your virtual network from the dropdown, make sure you've selected the correct Resource Group or region. |

- | Subnet | Once you've created or select a virtual network, the subnet field will appear. This subnet is dedicated to Route Server only. Select **Manage subnet configuration** and create the Azure Route Server subnet. Select **+ Subnet** and create a subnet using the following guidelines:</br><br>- The subnet must be named *RouteServerSubnet*.</br><br>- The subnet must be a minimum of /27 or larger.</br> |

- | Public IP address | Create a new or select an existing Standard public IP resource to assign to the Route Server. To ensure connectivity to the backend service that manages the Route Server configuration, a public IP address is required. |

-1. Select **Review + create**, review the summary, and then select **Create**.

-The section will help you configure BGP peering with your NVA.

-1. Go to [Route Server](./overview.md) in the Azure portal and select the Route Server you want to configure.

- :::image type="content" source="./media/quickstart-configure-route-server-portal/select-route-server.png" alt-text="Screenshot of Route Server list.":::

-1. Select **Peers** under *Settings* in the left navigation panel. Then select **+ Add** to add a new peer.

- :::image type="content" source="./media/quickstart-configure-route-server-portal/peers-landing-page.png" alt-text="Screenshot of peers landing page.":::

-1. Enter the following information about your NVA peer.

- :::image type="content" source="./media/quickstart-configure-route-server-portal/add-peer-page.png" alt-text="Screenshot of add peer page.":::

- | Settings | Value |

- |-|-|

- | Name | Give a name for the peering between your Route Server and the NVA. |

- | ASN | Enter the Autonomous Systems Number (ASN) of your NVA. |

- | IPv4 Address | Enter the IP address of the NVA the Route Server will communicate with to establish BGP. |

-1. Select **Add** to add this peer.

-You'll need the Azure Route Server's peer IPs and ASN to complete the configuration on your NVA to establish a BGP session. You can obtain this information from the overview page your Route Server.

-## Configure route exchange

-If you have a virtual network gateway (ExpressRoute or VPN) in the same virtual network, you can enable *branch-to-branch* traffic to exchange routes between the gateway and the Route Server.

-1. Go to the Route Server that you want to configure.

-1. Select **Configuration** under **Settings** in the left navigation panel.

-1. Select **Enable** for the **Branch-to-Branch** setting and then select **Save**.

- :::image type="content" source="./media/quickstart-configure-route-server-portal/enable-route-exchange.png" alt-text="Screenshot of how to enable route exchange.":::

-## Clean up resources

-If you no longer need the Azure Route Server, select **Delete** from the overview page to deprovision the Route Server.

-## Next steps

-After you create the Azure Route Server, continue to learn about how Azure Route Server interacts with ExpressRoute and VPN Gateways:

-> [Azure ExpressRoute and Azure VPN support](expressroute-vpn-support.md)

-1. On the **Purchase reservations page**, select **Microsoft Sentinel Pre-Purchase Plan**.

- `Need Sentinel screenshot here`

-# Troubleshoot your CEF or Syslog data connector

-To learn more about using the Azure Storage management library for specific resource management scenarios, see the [Azure Storage management library developer guide for .NET](../blobs/storage-blob-dotnet-get-started.md).

-Every workspace comes with a pre-configured serverless SQL pool called **Built-in**.

-1. In Synapse Studio, go to the **Develop** hub

-1. Paste the following code into the script.

-1. Select **Run**.

-1. Use the `master` database to create a separate database for custom database objects. Custom database objects, cannot be created in the `master` database.

- > Use a collation with `_UTF8` suffix to ensure that UTF-8 text is properly converted to `VARCHAR` columns. `Latin1_General_100_BIN2_UTF8` provides the best performance in the queries that read data from Parquet files and Azure Cosmos DB containers. For more information on changing collations, refer to [Collation types supported for Synapse SQL](sql/reference-collation-types.md).

-1. From `DataExplorationDB`, create utility objects such as credentials and data sources.

-The article describes the built-in Synapse RBAC (role-based access control) roles, the permissions they grant, and the scopes at which they can be used.

-|Synapse Administrator |Full Synapse access to serverless and dedicated SQL pools, Data Explorer pools, Apache Spark pools, and Integration runtimes. Includes create, read, update, and delete access to all published code artifacts. Includes Compute Operator, Linked Data Manager, and Credential User permissions on the workspace system identity credential. Includes assigning Synapse RBAC roles. In addition to Synapse Administrator, Azure Owners can also assign Synapse RBAC roles. Azure permissions are required to create, delete, and manage compute resources. Synapse RBAC roles can be assigned even when the associated subscription is disabled.</br></br>_Can read and write artifacts</br> Can do all actions on Spark activities.</br> Can view Spark pool logs</br> Can view saved notebook and pipeline output </br> Can use the secrets stored by linked services or credentials</br>Can assign and revoke Synapse RBAC roles at current scope_|Workspace </br> Spark pool<br/>Integration runtime </br>Linked service</br>Credential |

-|Synapse Apache Spark Administrator</br>|Full Synapse access to Apache Spark Pools. Create, read, update, and delete access to published Spark job definitions, notebooks and their outputs, and to libraries, linked services, and credentials.  Includes read access to all other published code artifacts. Doesn't include permission to use credentials and run pipelines. Doesn't include granting access. </br></br>_Can do all actions on Spark artifacts</br>Can do all actions on Spark activities_|Workspace</br>Spark pool|

-|Synapse SQL Administrator|Full Synapse access to serverless SQL pools. Create, read, update, and delete access to published SQL scripts, credentials, and linked services.  Includes read access to all other published code artifacts.  Doesn't include permission to use credentials and run pipelines. Doesn't include granting access. </br></br>*Can do all actions on SQL scripts<br/>Can connect to SQL serverless endpoints with SQL `db_datareader`, `db_datawriter`, `connect`, and `grant` permissions*|Workspace|

-|Synapse Contributor|Full Synapse access to Apache Spark pools and Integration runtimes. Includes create, read, update, and delete access to all published code artifacts and their outputs, including scheduled pipelines, credentials and linked services.  Includes compute operator permissions. Doesn't include permission to use credentials and run pipelines. Doesn't include granting access. </br></br>_Can read and write artifacts</br>Can view saved notebook and pipeline output</br>Can do all actions on Spark activities</br>Can view Spark pool logs_|Workspace </br> Spark pool<br/> Integration runtime|

-|Synapse Artifact User|Read access to published code artifacts and their outputs. Can create new artifacts but can't publish changes or run code without additional permissions.|Workspace

-|Synapse Compute Operator |Submit Spark jobs and notebooks and view logs.  Includes canceling Spark jobs submitted by any user. Requires additional use credential permissions on the workspace system identity to run pipelines, view pipeline runs and outputs. </br></br>_Can submit and cancel jobs, including jobs submitted by others</br>Can view Spark pool logs_|Workspace</br>Spark pool</br>Integration runtime|

-|Synapse Monitoring Operator |Read published code artifacts, including logs and outputs for pipeline runs and completed notebooks. Includes ability to list and view details of Apache Spark pools, Data Explorer pools, and Integration runtimes. Requires additional permissions to run/cancel pipelines, Spark notebooks, and Spark jobs.|Workspace |

-|Synapse User|List and view details of SQL pools, Apache Spark pools, Integration runtimes, and published linked services and credentials. Doesn't include other published code artifacts.  Can create new artifacts but can't run or publish without additional permissions. </br></br>_Can list and read Spark pools, Integration runtimes._|Workspace, Spark pool</br>Linked service </br>Credential|

->- All artifact read, write, and delete actions are with respect to published artifacts in the live service. These permissions do not affect access to artifacts in a connected Git repo.

-Role|Actions

-Synapse Administrator|workspaces/read</br>workspaces/roleAssignments/write, delete</br>workspaces/managedPrivateEndpoint/write, delete</br>workspaces/bigDataPools/useCompute/action</br>workspaces/bigDataPools/viewLogs/action</br>workspaces/integrationRuntimes/useCompute/action</br>workspaces/integrationRuntimes/viewLogs/action</br>workspaces/artifacts/read</br>workspaces/notebooks/write, delete</br>workspaces/sparkJobDefinitions/write, delete</br>workspaces/sqlScripts/write, delete</br>workspaces/kqlScripts/write, delete</br>workspaces/dataFlows/write, delete</br>workspaces/pipelines/write, delete</br>workspaces/triggers/write, delete</br>workspaces/datasets/write, delete</br>workspaces/libraries/write, delete</br>workspaces/linkedServices/write, delete</br>workspaces/credentials/write, delete</br>workspaces/notebooks/viewOutputs/action</br>workspaces/pipelines/viewOutputs/action</br>workspaces/linkedServices/useSecret/action</br>workspaces/credentials/useSecret/action</br>workspaces/linkConnections/read</br>workspaces/linkConnections/write</br>workspaces/linkConnections/delete</br>workspaces/linkConnections/useCompute/action|

-Action|Role

-workspaces/read|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse SQL Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher</br>Synapse Artifact User</br>Synapse Compute Operator </br>Synapse Monitoring Operator </br>Synapse Credential User</br>Synapse Linked Data Manager</br>Synapse User

-workspaces/roleAssignments/write, delete|Synapse Administrator

-workspaces/managedPrivateEndpoint/write, delete|Synapse Administrator</br>Synapse Linked Data Manager

-workspaces/bigDataPools/useCompute/action|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse Contributor</br>Synapse Compute Operator </br>Synapse Monitoring Operator

-workspaces/bigDataPools/viewLogs/action|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse Contributor</br>Synapse Compute Operator

-workspaces/integrationRuntimes/useCompute/action|Synapse Administrator</br>Synapse Contributor</br>Synapse Compute Operator</br>Synapse Monitoring Operator

-workspaces/integrationRuntimes/viewLogs/action|Synapse Administrator</br>Synapse Contributor</br>Synapse Compute Operator</br>Synapse Monitoring Operator

-workspaces/linkConnections/read|Synapse Administrator</br>Synapse Contributor</br>Synapse Compute Operator

-workspaces/linkConnections/useCompute/action|Synapse Administrator</br>Synapse Contributor</br>Synapse Compute Operator

-workspaces/artifacts/read|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse SQL Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher</br>Synapse Artifact User

-workspaces/notebooks/write, delete|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/sparkJobDefinitions/write, delete|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/sqlScripts/write, delete|Synapse Administrator</br>Synapse SQL Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/kqlScripts/write, delete|Synapse Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/dataFlows/write, delete|Synapse Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/pipelines/write, delete|Synapse Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/linkConnections/write, delete|Synapse Administrator</br>Synapse Contributor

-workspaces/triggers/write, delete|Synapse Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/datasets/write, delete|Synapse Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/libraries/write, delete|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher

-workspaces/linkedServices/write, delete|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse SQL Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher</br>Synapse Linked Data Manager

-workspaces/credentials/write, delete|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse SQL Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher</br>Synapse Linked Data Manager

-workspaces/notebooks/viewOutputs/action|Synapse Administrator</br>Synapse Apache Spark Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher</br>Synapse Artifact User

-workspaces/pipelines/viewOutputs/action|Synapse Administrator</br>Synapse Contributor</br>Synapse Artifact Publisher</br>Synapse Artifact User

-workspaces/linkedServices/useSecret/action|Synapse Administrator</br>Synapse Credential User

-workspaces/credentials/useSecret/action|Synapse Administrator</br>Synapse Credential User

-| | cis-windows-server-2012-r2-v2-2-1-l2 | cis-ws2012-r2-l2 ||

-| | cis-windows-server-2016-v1-0-0-l1 | cis--l1 ||

-| | cis-windows-server-2016-v1-0-0-l2 | cis-ws2016-l2 ||

-| | cis-windows-server-2019-v1-0-0-l1 | cis-ws2019-l1 ||

-| | cis-windows-server-2019-v1-0-0-l2 | cis-ws2019-l2 ||

-| | cis-windows-server-2022-l1| cis-windows-server-2022-l1 </br> cis-windows-server-2022-l1-gen2 | |

-| | cis-windows-server-2022-l2 | cis-windows-server-2022-l2 </br> cis-windows-server-2022-l2-gen2 | |

-| | cis-windows-server| cis-windows-server2016-l1-gen1 </br> cis-windows-server2019-l1-gen1 </br> cis-windows-server2019-l1-gen2 </br> cis-windows-server2019-l2-gen1 </br> cis-windows-server2022-l1-gen2 </br> cis-windows-server2022-l2-gen2 </br> cis-windows-server2022-l1-gen1 | |

-| |cis-oracle-linux-8-l1 | cis-oracle8-l1||

-| |cis-rhel | cis-redhat7-l1-gen1 </br> cis-redhat8-l1-gen1 </br> cis-redhat8-l2-gen1 </br> cis-redhat9-l1-gen1 </br> cis-redhat9-l1-gen2| |

-| |cis-rhel-7-l2 | cis-rhel7-l2 | |

-| |cis-rhel-8-l1 | | |

-| |cis-rhel-8-l2 | cis-rhel8-l2 | |

-| |cis-rhel9-l1 | cis-rhel9-l1 </br> cis-rhel9-l1-gen2 ||

-| |cis-ubuntu | cis-ubuntu1804-l1 </br> cis-ubuntulinux2004-l1-gen1 </br> cis-ubuntulinux2204-l1-gen1 </br> cis-ubuntulinux2204-l1-gen2 ||

-| |cis-ubuntu-linux-2004-l1| cis-ubuntu2004-l1||

-| |cis-ubuntu-linux-2204-l1 | cis-ubuntu-linux-2204-l1 </br> cis-ubuntu-linux-2204-l1-gen2 | |

- | Amazon Linux 2023 |

- | Windows Server 2012 R2 and higher (including Server Core) |

- | Ubuntu 16.04, 18.04, 20.04, and 22.04 LTS |

- | SUSE Linux Enterprise Server (SLES) 12 and 15 (x64) |

- | Red Hat Enterprise Linux (RHEL) 7, 8, 9 (x64) |

- | Oracle 7.x, 8.x|

- | Rocky Linux 8|

-The property [AllowExtensionOperations](https://learn.microsoft.com/dotnet/api/microsoft.azure.management.compute.models.osprofile.allowextensionoperations?view=azure-dotnet-legacy) is set to false in the machine OSProfile.

-For Windows, see [issues related to proxy](https://learn.microsoft.com/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting?toc=%2Fwindows%2Fdeployment%2Ftoc.json&bc=%2Fwindows%2Fdeployment%2Fbreadcrumb%2Ftoc.json#issues-related-to-httpproxy).

-For Windows, see [Protocols in TLS/SSL Schannel SSP](https://learn.microsoft.com/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-).

-You can choose whether the session is disconnected or the remote lock screen shown when a remote session is locked, either by the user or by policy. When the session lock behavior is set to disconnect, a dialog is shown to let users know they were disconnected. Users can choose the **Reconnect** option from the dialog when they're ready to connect again.

-For scenarios that rely on legacy authentication, including NTLM, CredSSP, RDSTLS, TLS, and RDP basic authentication protocols, users are prompted to re-enter their credentials.

-1. The Group Policy settings are only available the operating systems listed in [Prerequisites](#prerequisites). To make them available on other versions of Windows Server, you need to copy the administrative template files `C:\Windows\PolicyDefinitions\terminalserver.admx` and `C:\Windows\PolicyDefinitions\en-US\terminalserver.adml` from a session host to the same location on your domain controllers or the [Group Policy Central Store](/troubleshoot/windows-client/group-policy/create-and-manage-central-store), depending on your environment. In the file path for `terminalserver.adml` replace `en-US` with the appropriate language code if you're using a different language.

-1. Open the **Group Policy Management** console on device you use to manage the Active Directory domain.

- - To disconnect the remote session when the session locks, select **Enabled** or **Not configured**.

- - To show the remote lock screen when the session locks, select **Disabled**.

-1. Configure the target device groups.

-When single sign-on using Microsoft Entra ID is enabled and the remote session is locked, either by the user or by policy, you can choose whether the session is disconnected or the remote lock screen shown. The default behavior is to disconnect the session when it locks.

-When the session lock behavior is set to disconnect, and a dialog is shown to let users know they were disconnected. Users can choose the **Reconnect** option from the dialog when they're ready to connect again. This behavior is done for security reasons and to ensure full support of passwordless authentication. Disconnecting the session provides the following benefits:

-1. [Create or edit a configuration profile](/mem/intune/configuration/administrative-templates-windows) for **Windows 10 and later** devices, with the **Templates** profile type, and the **Administrative templates** template.

-1. In the **Configuration settings** tab, browse to **Computer configuration** > **Windows Components** > **Remote Desktop Services** > **Remote Desktop Session Host** > **Device and Resource Redirection**, then select **Do not allow WebAuthn redirection**.

- :::image type="content" source="media/redirection-remote-desktop-protocol/redirection-configuration-intune-template-webauthn.png" alt-text="A screenshot showing the device and resource redirection options in the Microsoft Intune portal." lightbox="media/redirection-remote-desktop-protocol/redirection-configuration-intune-template-webauthn.png":::

-1. Select **Do not allow WebAuthn redirection**. In the pane separate pane that opens:

- - To allow WebAuthn redirection, select **Disabled** or **Not configured**, then select **OK**.

- - To disable WebAuthn redirection, select **Enabled**, then select **OK**.

-A virtual network peering cannot be created between two virtual networks deployed through the classic deployment model. This tutorial uses virtual networks that exist in the same region. This tutorial peers virtual networks in the same region. You can also peer virtual networks in different [supported regions](virtual-network-manage-peering.md#cross-region). It's recommended that you familiarize yourself with the [peering requirements and constraints](virtual-network-manage-peering.md#requirements-and-constraints) before peering virtual networks.

-When creating a virtual network peering between virtual networks that exist in different subscriptions, the subscriptions can associated to the same Microsoft Entra tenant. If you don't already have a Microsoft Entra tenant, you can quickly [create one](../active-directory/develop/quickstart-create-new-tenant.md?toc=%2fazure%2fvirtual-network%2ftoc.json#create-a-new-azure-ad-tenant).

-In the diagram below, both toggles need to be enabled to allow connectivity between the standalone VNet 4 and the VNets directly connected to hub 2 (VNet 2 and VNet 3): **Allow traffic from remote Virtual WAN networks** for the virtual network gateway and **Allow traffic from non Virtual WAN networks** for the virtual hub's ExpressRoute gateway. If an Azure Route Server is deployed in standalone VNet 4, and the Route Server has [branch-to-branch](../route-server/quickstart-configure-route-server-portal.md#configure-route-exchange) enabled, then connectivity will be blocked between VNet 1 and standalone VNet 4.

-In the **Attachments (optional)** section, you should supply as much comprehensive information as possible. If a screen doesn't look right, [attach a screenshot](#attach-a-screenshot). If you're reporting a problem other than a screen issue, it's best to follow the steps in [Recreate my problem](#recreate-my-problem) and then use the steps in [Attach a file](#attach-a-file) to attach the log files.

-### Attach a file

-Attach the Azure VPN Client **log files**. It's best if you attach the file after you recreate the problem to make sure the problem is included in the log file. To attach the client log files:

-1. Select **Attach a file** and locate the log files for the Azure VPN client. Log files are stored locally in the following folder: **%localappdata%\Packages\Microsoft.AzureVpn_8wekyb3d8bbwe\LocalState\LogFiles**.

-1. From the LogFiles folder, select **Azure VPNClient.log** and **Azure VpnCxn.log**.

- :::image type="content" source="./media/feedback-hub-azure-vpn-client/locate-files.png" alt-text="Screenshot showing the Azure VPN client log files." lightbox="./media/feedback-hub-azure-vpn-client/locate-files.png":::

-For more information about FeedBack Hub, see [Send feedback to Microsoft with the Feedback Hub app](https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332).

-| P2S VPN | P2S | [Azure VPN Client for macOS](#macos) | Microsoft Entra ID authentication updates, additional features. | May 2024 | N/A|