+[Azure App Service](overview.md) provides a highly scalable, self-patching web hosting service. This guide shows you how to map an existing custom Domain Name System (DNS) name to App Service. To migrate a live site and its DNS domain name to App Service with no downtime, see [Migrate an active DNS name to Azure App Service](manage-custom-dns-migrate-domain.md).

+| - | - | - |

+| Root domain | contoso.com | [A record](https://en.wikipedia.org/wiki/List_of_DNS_record_types#A). Don't use the CNAME record for the root record. (For information, see [RFC 1912, section 2.4](https://datatracker.ietf.org/doc/html/rfc1912#section-2.4).) |

+| Subdomain |www.contoso.com, my.contoso.com | [CNAME record](https://en.wikipedia.org/wiki/CNAME_record). You can map a subdomain to the app's IP address directly with an A record, but it's possible for [the IP address to change](overview-inbound-outbound-ips.md#when-inbound-ip-changes). The CNAME maps to the app's default hostname instead, which is less susceptible to change. |

+* [Create an App Service app](./index.yml), or use an app that you created for another tutorial. The web app's [App Service plan](overview-hosting-plans.md) must be a paid tier, not the Free (F1) tier. See [Scale up an app](manage-scale-up.md#scale-up-your-pricing-tier) to update the tier.

+## Configure a custom domain

+1. For **TLS/SSL certificate**, select **App Service Managed Certificate** if your app is in the Basic tier or higher. If you want to remain in the Shared tier, or if you want to use your own certificate, select **Add certificate later**.

+1. For **Domain**, specify a fully qualified domain name you want based on the domain you own. The **Hostname record type** box defaults to the recommended DNS record to use, depending on whether the domain is a root domain (like `contoso.com`), a subdomain (like `www.contoso.com`), or a wildcard domain (like `*.contoso.com`).

+1. For each custom domain in App Service, you need two DNS records with your domain provider. The **Domain validation** section shows you two DNS records that you must add with your domain provider. You can use the copy buttons to copy the value or values that you need in the next section.

+ The following screenshot shows the default selections for a `www.contoso.com` domain. It shows a CNAME record and a TXT record to add.

+## Create the DNS records

+### [Root domain (for example, contoso.com)](#tab/root)

+Create two records, as described in the following table:

+| A | `@` | The app's IP address shown in the **Add custom domain** dialog. | The domain mapping itself. (`@` typically represents the root domain.) |

+| TXT | `asuid` | The domain verification ID shown in the **Add custom domain** dialog. | For the root domain, App Service accesses the `asuid` TXT record to verify your ownership of the custom domain. |

+### [Subdomain (for example, www.contoso.com)](#tab/subdomain)

+Create two records, as described in the following table:

+|A|`<subdomain>` (for example, `www`)|IP address shown in the **Add custom domain** dialog.| The domain mapping itself. |

+|TXT|`asuid.<subdomain>` (for example, `asuid.www`)|The domain verification ID shown in the **Add custom domain** dialog.| App Service accesses the `asuid.<subdomain>` TXT record to verify your ownership of the custom domain. |

+Create two records, as described in the following table:

+| - | - | - |-|

+| CNAME | `<subdomain>` (for example, `www`) | `<app-name>.azurewebsites.net`. (See [the note at the start of this article](#dnl-note).) | The domain mapping itself. |

+For a wildcard name, like `*` in `*.contoso.com`, create two records, as described in the following table:

+| CNAME | `*` | `<app-name>.azurewebsites.net`. (See [the note at the start of this article](#dnl-note).) | The domain mapping itself. |

+## Validate domain ownership and complete the mapping

+1. If the **Domain validation** section shows green check marks next to both domain records, you've configured them correctly. Select **Add**. If you see any errors or warnings, resolve them in the DNS record settings on your domain provider's website.

+ > If you configured the TXT record but not the A or CNAME record, App Service treats the change as a [domain migration](manage-custom-dns-migrate-domain.md) scenario and allows the validation to succeed, but you won't see green check marks next to the records.

+1. You should see the custom domain added to the list. You might also see a red X and the text **No binding**.

+ If you selected **App Service Managed Certificate** earlier, wait a few minutes for App Service to create the managed certificate for your custom domain. When the process is complete, the red X becomes a green check mark and you see the word **Secured**. If you selected **Add certificate later**, the red X will remain until you [add a private certificate for the domain](configure-ssl-certificate.md) and [configure the binding](configure-ssl-bindings.md).

+ > Unless you configure a certificate binding for your custom domain, any HTTPS request from a browser to the domain will receive an error or warning, depending on the browser.

+## Test the DNS resolution

+Browse to the DNS names that you configured.

+If you receive an HTTP 404 (Not Found) error when you browse to the URL of your custom domain, the two most likely causes are:

+- The browser client has cached the old IP address of your domain. Clear the cache and test the DNS resolution again. On a Windows machine, you can clear the cache with `ipconfig /flushdns`.

+> [Purchase an App Service domain](manage-custom-dns-buy-domain.md)

+For high availability scenarios, you can implement a load-balancing DNS setup without Traffic Manager by creating multiple *A records* that point from the root domain to each app copy's IP address. Then, [map the same root domain to all the app copies](app-service-web-tutorial-custom-domain.md#create-the-dns-records). Since the same domain name cannot be mapped to two different apps in the same region, this setup only works when your app copies are in different regions.

+Node.js apps must be deployed with all the required npm dependencies. The App Service deployment engine automatically runs `npm install --production` for you when you deploy a [Git repository](deploy-local-git.md), or when you deploy a [Zip package](deploy-zip.md) [with build automation enabled](deploy-zip.md#enable-build-automation-for-zip-deploy). If you deploy your files using [FTP/S](deploy-ftp.md), however, you need to upload the required packages manually.

+>Since the runtime is regularly patched and updated by the platform, we don't recommend that you target a specific minor version/patch as these are not guaranteed to be available due to potential security risks.

+In App Service on Windows, Node.js apps are hosted with [IISNode](https://github.com/Azure/iisnode), and your Node.js app should listen to the port specified in the `process.env.PORT` variable. The following example shows how to do that in a simple Express app:

+App Service sets the environment variable `PORT` in the Node.js container, and forwards the incoming requests to your container at that port number. To receive the requests, your app should listen to that port using `process.env.PORT`. The following example shows how to do that in a simple Express app:

+If you deploy your app by using Git, or by using zip packages [with build automation enabled](deploy-zip.md#enable-build-automation-for-zip-deploy), the App Service build automation steps through the following sequence:

+1. Run custom script, if one is specified by `PRE_BUILD_SCRIPT_PATH`.

+> As is noted in the [npm docs](https://docs.npmjs.com/misc/scripts), scripts named `prebuild` and `postbuild` run before and after `build`, respectively, if specified. `preinstall` and `postinstall` run before and after `install`, respectively.

+The following example uses the two variables to specify a series of commands, separated by commas.

+For information about additional environment variables to customize build automation, see [Oryx configuration](https://github.com/microsoft/Oryx/blob/master/doc/configuration.md).

+The Node.js containers come with [PM2](https://pm2.keymetrics.io/), a production process manager. You can configure your app to start with PM2, with npm start, or with a custom command.

+|[Run with npm start](#run-with-npm-start)|Development use only.|

+|[Run with a custom command](#run-with-a-custom-command)|Either development or staging.|

+- One of the following [PM2 files](https://pm2.keymetrics.io/docs/usage/application-declaration/#process-file): *process.json* or *ecosystem.config.js*

+### Run with a custom command

+### Run with npm start

+In the Azure explorer, find the app you want to debug, right-click it and select **Start Remote Debugging**. Select **Yes** to enable remote debugging for your app. App Service starts a tunnel proxy for you and attaches the debugger. You can then make requests to the app and see the debugger pausing at break points.

+Once finished with debugging, stop the debugger by selecting **Disconnect**. When prompted, you should select **Yes** to disable remote debugging. To disable it later, right-click your app again in the Azure explorer and select **Disable Remote Debugging**.

+By default, App Service build automation runs `npm install --production` when it recognizes that a Node.js app is deployed through Git, or through Zip deployment [with build automation enabled](deploy-zip.md#enable-build-automation-for-zip-deploy). If your app requires any of the popular automation tools, such as Grunt, Bower, or Gulp, you need to supply a [custom deployment script](https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script) to run it.

+From a local terminal window, change the directory to your repository root and run the following commands:

+In App Service, [TLS/SSL termination](https://wikipedia.org/wiki/TLS_termination_proxy) happens at the network load balancers, so all HTTPS requests reach your app as unencrypted HTTP requests. If your app logic needs to check if the user requests are encrypted, inspect the `X-Forwarded-Proto` header.

+Popular web frameworks let you access the `X-Forwarded-*` information in your standard app pattern. In [Express](https://expressjs.com/), you can use [trust proxies](https://expressjs.com/en/guide/behind-proxies.html). For example:

+When deploying Node.js apps on Azure App Service for Linux, you might need to handle URL rewrites directly within your application. This is particularly useful for ensuring specific URL patterns are redirected to the correct endpoints without relying on web server configurations. There are several ways to accomplish URL rewrites in Node.js. One example is through the [express-urlrewrite](https://www.npmjs.com/package/express-urlrewrite) package.

+Application Insights allows you to monitor your application's performance, exceptions, and usage without making any code changes. To attach the Application Insights agent, go to your web app in the portal, select **Application Insights** under **Settings**, and then select **Turn on Application Insights**. Next, select an existing Application Insights resource or create a new one. Finally, select **Apply** at the bottom. To instrument your web app using PowerShell, see [these instructions](/azure/azure-monitor/app/azure-web-apps-nodejs#enable-through-powershell)

+ - Depending on your *package.json*, different packages might be installed for production mode (`dependencies` vs. `devDependencies`).

+ - Certain web frameworks might deploy static files differently in production mode.

+ - Certain web frameworks might use custom startup scripts when running in production mode.

+- Run your app in App Service in development mode. For example, in [MEAN.js](https://meanjs.org/), you can set your app to development mode at runtime by [setting the `NODE_ENV` app setting](configure-common.md).

+After deploying your Node.js code to a native Windows app in App Service, you might see the message `You do not have permission to view this directory or page` in the browser when navigating to your app's URL. This is most likely because you don't have a *web.config* file. (See the [template](https://github.com/projectkudu/kudu/blob/master/Kudu.Core/Scripts/iisnode.config.template) and an [example](https://github.com/Azure-Samples/nodejs-docs-hello-world/blob/master/web.config).)

+If you use [ZIP deployment](deploy-zip.md) (through Visual Studio Code, for example), be sure to [enable build automation](deploy-zip.md#enable-build-automation-for-zip-deploy). It's not enabled by default. [`az webapp up`](/cli/azure/webapp#az-webapp-up) uses ZIP deployment with build automation enabled.

+> [Azure App Service on Linux FAQ](faq-app-service-linux.yml)

+description: Create an App Service certificate and manage it. Renew, synchronize, and delete App Service certificates.

+This article shows how to create an App Service certificate and perform management tasks like renewing, synchronizing, and deleting certificates. Once you have an App Service certificate, you can then import it into an App Service app. An App Service certificate is a private certificate that's managed by Azure. It combines the simplicity of automated certificate management and the flexibility of renewal and export options.

+- [Create an App Service app](./index.yml). The app's [App Service plan](overview-hosting-plans.md) must be in the Basic, Standard, Premium, or Isolated tier. See [Scale up an app](manage-scale-up.md#scale-up-your-pricing-tier) to update the tier.

+> Currently, App Service certificates aren't supported in Azure national clouds.

+#### Buy the certificate

+1. Go to the [Create App Service certificate page](https://portal.azure.com/#create/Microsoft.SSL) to start the purchase.

+ > App Service Certificates purchased from Azure are issued by GoDaddy. For some domains, you must explicitly allow GoDaddy as a certificate issuer by creating a [CAA domain record](https://wikipedia.org/wiki/DNS_Certification_Authority_Authorization) with the value `0 issue godaddy.com`.

+ :::image type="content" source="./media/configure-ssl-certificate/purchase-app-service-cert.png" alt-text="Screenshot of Create App Service certificate pane with purchase options.":::

+1. To configure the certificate, use the following table. When you're done, select **Review + Create**, and then select **Create**.

+ | **Resource Group** | The resource group that will contain the certificate. You can either create a new resource group or select the same resource group as your App Service app. |

+ | **Naked domain hostname** | Specify the root domain. The issued certificate provides security for *both* the root domain and the `www` subdomain. In the issued certificate, the **Common Name** field specifies the root domain, and the **Subject Alternative Name** field specifies the `www` domain. To provide security for only a subdomain, specify the fully qualified domain name for the subdomain, for example, `mysubdomain.contoso.com`.|

+ | **Enable auto renewal** | Select whether to automatically renew the certificate before expiration. Each renewal extends the certificate expiration by one year. The cost is charged to your subscription. |

+#### Store the certificate in Azure Key Vault

+[Key Vault](/azure/key-vault/general/overview) is an Azure service that helps safeguard cryptographic keys and secrets used by cloud applications and services. For App Service certificates, we recommend that you use Key Vault. After you finish the certificate purchase process, you must complete a few more steps before you start using the certificate.

+ :::image type="content" source="media/configure-ssl-certificate/configure-key-vault.png" alt-text="Screenshot of the Certificate Configuration pane with 'Step 1: Store' selected.":::

+ | **Days to retain deleted vaults** | The number of days, after deletion, that objects remain recoverable. (See [Azure Key Vault soft-delete overview](/azure/key-vault/general/soft-delete-overview).) Set a value between 7 and 90. |

+ | **Purge protection** | Enabling this option forces all deleted objects to remain in soft-deleted state for the entire duration of the retention period. |

+1. Select **Next** and then select **Vault access policy**. Currently, App Service certificates support only Key Vault access policies, not the RBAC model.

+1. Select **Review + create**, and then select **Create**.

+1. After the key vault is created, don't select **Go to resource**. Wait for the **Select key vault from Azure Key Vault** page to reload.

+1. From the same **Certificate Configuration** page as in the previous section, select **Step 2: Verify**.

+ :::image type="content" source="media/configure-ssl-certificate/verify-domain.png" alt-text="Screenshot of the Certificate Configuration pane with 'Step 2: Verify' selected.":::

+1. Select **App Service Verification**. Because you mapped the domain to your web app earlier in this section, the domain is already verified. To finish this step, just select **Verify**, and then select **Refresh** until the message **Certificate is Domain Verified** appears.

+| **Manual Verification** | Confirm the domain by using either a DNS TXT record or an HTML page. (The latter applies only to Standard certificates. See the following note.) The steps are provided after you select the option. The HTML page option doesn't work for web apps with **HTTPS Only** enabled. For domain verification via DNS TXT record for either the root domain (for example, `contoso.com`) or the subdomain (for example, `www.contoso.com` or `test.api.contoso.com`) and regardless of the certificate SKU, you need to add a TXT record at the root domain level, using `@` for the name and the domain verification token for the value in your DNS record. |

+> With the Standard certificate, you get a certificate for the requested top-level domain *and* the `www` subdomain, for example, `contoso.com` and `www.contoso.com`. However, App Service Verification and Manual Verification both use HTML page verification, which doesn't support the `www` subdomain when you issue, rekey, or renew a certificate. For the Standard certificate, use Domain Verification and Mail Verification to include the `www` subdomain with the requested top-level domain in the certificate.

+By default, App Service certificates have a one-year validity period. Before the expiration date, you can automatically or manually renew App Service certificates in one-year increments. The renewal process effectively gives you a new App Service certificate with the expiration date extended to one year from the existing certificate's expiration date.

+> Unlike the free App Service managed certificate, purchased App Service certificates don't have automated domain re-verification. Failure to verify domain ownership results in failed renewals. For more information about how to verify your App Service certificate, review [Confirm domain ownership](#confirm-domain-ownership).

+> The renewal process requires that the service principal for App Service has the required permissions on your key vault. These permissions are set up for you when you import an App Service certificate through the Azure portal. Make sure that you don't remove these permissions from your key vault.

+1. Select **On** or **Off**, and then select **Save**.

+ :::image type="content" source="./media/configure-ssl-certificate/auto-renew-app-service-cert.png" alt-text="Screenshot of specified certificate's auto renewal settings." lightbox="./media/configure-ssl-certificate/auto-renew-app-service-cert.png":::

+1. To manually renew the certificate instead, select **Manual Renew**. You can request to manually renew your certificate 60 days before expiration, but [certificates can't be issued for longer than 397 days](https://www.godaddy.com/help/important-notification-about-ssl-offerings-9322).

+## Rekey an App Service certificate

+If you think your certificate's private key is compromised, you can rekey your certificate. This action rotates the certificate with a new certificate issued from the certificate authority.

+ :::image type="content" source="./media/configure-ssl-certificate/rekey-app-service-cert.png" alt-text="Screenshot of rekeying an App Service certificate." lightbox="./media/configure-ssl-certificate/rekey-app-service-cert.png":::

+Run the following commands in [Azure Cloud Shell](https://shell.azure.com), or run them locally if you have [installed Azure CLI](/cli/azure/install-azure-cli). Replace the placeholders with the names that you used when you [bought the App Service certificate](#buy-the-certificate).

+If you delete an App Service certificate, the delete operation is irreversible and final. The result is a revoked certificate, and any binding in App Service that uses the certificate becomes invalid.

+1. When the confirmation box opens, enter the certificate name, and then select **OK**.

+Your App Service certificate is probably not yet domain-verified. Until [domain ownership is confirmed](#confirm-domain-ownership), your App Service certificate isn't ready for use. As a Key Vault secret, it maintains an `Initialize` tag, and its value and content-type remain empty. When domain ownership is confirmed, the key vault secret shows a value and a content-type, and the tag changes to `Ready`.

+Your App Service certificate is probably not yet domain-verified. Until [domain ownership is confirmed](#confirm-domain-ownership), your App Service certificate isn't ready for use.

+#### What changes does the App Service certificate creation process make to my existing key vault?

+- Creates a [delete lock](../azure-resource-manager/management/lock-resources.md) called `AppServiceCertificateLock` on the vault to prevent accidental deletion of the key vault.

+## Related content

+* [Frequently asked questions about creating or deleting resources in Azure App Service](./faq-configuration-and-management.yml)

+ Your app's **Custom domain** page is updated with the new, dedicated IP address. Copy this IP address, then [remap the A record](app-service-web-tutorial-custom-domain.md#create-the-dns-records) to this new IP address.

+- If you have an SNI SSL binding to `<app-name>.azurewebsites.net`, [remap any CNAME mapping](app-service-web-tutorial-custom-domain.md#create-the-dns-records) to point to `sni.<app-name>.azurewebsites.net` instead (add the `sni` prefix).

+By default, the App Service resource provider doesn't have access to your key vault. To use a key vault for a certificate deployment, you must authorize read access for the resource provider (App Service) to the key vault. You can grant access either with access policy or RBAC.

+> Currently, the Azure portal does not allow you to configure an App Service certificate in Key Vault to use the RBAC model. You can, however, use Azure CLI, Azure PowerShell, or an ARM template deployment to perform this configuration.

+### [RBAC permissions](#tab/RBAC)

+| Resource provider | Service principal app ID / assignee | Key vault RBAC role |

+|--|--|--|

+| **Microsoft Azure App Service** or **Microsoft.Azure.WebSites** | - `abfa0a7c-a6b6-4736-8310-5855508787cd` for public Azure cloud environment <br><br>- `6a02c803-dafd-4136-b4c3-5a6f318b4714` for Azure Government cloud environment | Certificate User |

+The service principal app ID or assignee value is the ID for App Service resource provider. To learn how to authorize key vault permissions for App Service resource provider using access policy refer to the [provide access to Key Vault keys, certificates, and secrets with an Azure role-based access control documentation](/azure/key-vault/general/rbac-guide?tabs=azure-portal#key-vault-scope-role-assignment).

+> [!NOTE]

+> Do not delete these RBAC permissions from key vault, otherwise App Service will not be able to sync your web app with the latest key vault certificate version.

+### [Access policy permissions](#tab/accesspolicy)

+| Resource provider | Service principal app ID | Key vault secret permissions | Key vault certificate permissions |

+|--|--|--|--|

+| **Microsoft Azure App Service** or **Microsoft.Azure.WebSites** | - `abfa0a7c-a6b6-4736-8310-5855508787cd` for public Azure cloud environment <br><br>- `6a02c803-dafd-4136-b4c3-5a6f318b4714` for Azure Government cloud environment | Get | Get |

+The service principal app ID or assignee value is the ID for App Service resource provider. To learn how to authorize key vault permissions for App Service resource provider using access policy refer to the [assign a Key Vault access policy documentation](/azure/key-vault/general/assign-access-policy?tabs=azure-portal).

+> [!NOTE]

+> Do not delete these access policy permissions from key vault, otherwise App Service will not be able to sync your web app with the latest key vault certificate version.

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+An App Service Environment can be created in **either** an Azure Resource Manager virtual network, **or** a classic deployment model [virtual network][virtualnetwork]. A new virtual network and new subnet can be defined at the time an App Service Environment is created. Instead, an App Service Environment can be created in a preexisting virtual network and preexisting subnet. As of June 2016, ASEs can also be deployed into virtual networks that use either public address ranges or RFC1918 address spaces (private addresses). For more information, see [How to Create an ASEv1 from template](app-service-app-service-environment-create-ilb-ase-resourcemanager.md).

+App Service Environments require a valid DNS infrastructure configured for the virtual network. If the DNS configuration is changed after the creation of an App Service Environment, developers can force an App Service Environment to pick up the new DNS configuration. If you trigger a rolling environment reboot using the **Restart** icon, the environment picks up the new DNS configuration. (The **Restart** icon is located at the top of the App Service Environment management page, in the [Azure portal](https://portal.azure.com).)

+It's also recommended that any custom DNS servers on the virtual network be set up ahead of time before creating an App Service Environment. If a virtual network's DNS configuration is changed during the creation of an App Service Environment, the App Service Environment creation process fails. Similarly, if there's a custom DNS server that's unreachable or unavailable on the other end of a VPN gateway, the App Service Environment creation process will also fail.

+Once a network security group is created, one or more network security rules are added to it. Since the set of rules might change over time, you should space out the numbering scheme used for rule priorities. This practice makes it easy to insert other rules over time.

+In the following example, a rule explicitly grants access to the management ports needed by the Azure infrastructure to manage and maintain an App Service Environment. All management traffic flows over TLS and is secured by client certificates. Even though the ports are opened, they're inaccessible by any entity other than Azure management infrastructure.

+When you lock down access to port 80 and 443 to "hide" an App Service Environment behind upstream devices or services, remember the upstream IP address. For example, if you're using a web application firewall (WAF), the WAF has its own IP address or addresses. The WAF uses them when proxying traffic to a downstream App Service Environment. You need to use this IP address in the *SourceAddressPrefix* parameter of a network security rule.

+In the following example, inbound traffic from a specific upstream IP address is explicitly allowed. The address *1.2.3.4* is used as a placeholder for the IP address of an upstream WAF. Change the value to match the address used by your upstream device or service.

+If FTP support is wanted, use the following rules as a template to grant access to the FTP control port and data channel ports. Since FTP is a stateful protocol, you might be unable to route FTP traffic through a traditional HTTP/HTTPS firewall or proxy device. In this case, you need to set the *SourceAddressPrefix* to a different value, such as the IP address range of developer or deployment machines on which FTP clients are running.

+(**Note:** the data channel port range might change during the preview period.)

+If remote debugging with Visual Studio is used, the following rules demonstrate how to grant access. There's a separate rule for each supported version of Visual Studio since each version uses a different port for remote debugging. As with FTP access, remote debugging traffic might not flow properly through a traditional WAF or proxy device. The *SourceAddressPrefix* can instead be set to the IP address range of developer machines running Visual Studio.

+If an app is configured with an explicit IP-SSL address (applicable *only* to ASEs that have a public VIP), instead of using the default IP address of the App Service Environment, both HTTP, and HTTPS traffic flows into the subnet over ports other than ports 80 and 443.

+When an app on an ASE is configured to use IP-SSL, external customers won't see or need to worry about the special port pair mapping. Traffic to the apps will flow normally to the configured IP-SSL address. The translation to the special port pair automatically happens internally, during the routing traffic's final leg into the subnet that contains the ASE.

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+ * *3* means both HTTP/HTTPS traffic on ports 80/443, and the control/data channel ports listened to by the FTP service on the ASE, will be bound to an ILB allocated virtual network internal address.

+ * *2* means only the FTP service related ports (both control and data channels) will be bound to an ILB address, while the HTTP/HTTPS traffic will remain on the public VIP.

+ * *0* means all traffic is bound to the public VIP making the ASE external.

+* *dnsSuffix*: This parameter defines the default root domain that will be assigned to the ASE. In the public variation of Azure App Service, the default root domain for all web apps is *azurewebsites.net*. However since an ILB ASE is internal to a customer's virtual network, it doesn't make sense to use the public service's default root domain. Instead, an ILB ASE should have a default root domain that makes sense for use within a company's internal virtual network. For example, a hypothetical Contoso Corporation might use a default root domain of *internal.contoso.com* for apps that are intended to only be resolvable and accessible within Contoso's virtual network.

+* *ipSslAddressCount*: This parameter is automatically defaulted to a value of 0 in the *azuredeploy.json* file because ILB ASEs only have a single ILB address. There are no explicit IP-SSL addresses for an ILB ASE, and so the IP-SSL address pool for an ILB ASE must be set to zero, otherwise a provisioning error will occur.

+Once the ILB ASE is created, a TLS/SSL certificate should be associated with the ASE as the "default" TLS/SSL certificate use for establishing TLS/SSL connections to apps. Continuing with the hypothetical Contoso Corporation example, if the ASE's default DNS suffix is *internal.contoso.com*, then a connection to *`https://some-random-app.internal.contoso.com`* requires a TLS/SSL certificate that is valid for **.internal.contoso.com*.

+* *Subject Alternative Name*: This attribute must include both **.your-root-domain-here.com*, and**.scm.your-root-domain-here.com*. The reason for the second entry is that TLS connections to the SCM/Kudu site associated with each app will be made using an address of the form *your-app-name.scm.your-root-domain-here.com*.

+[examplebase64encoding]: https://powershellscripts.blogspot.com/2007/02/base64-encode-file.html

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+For more details on how App Service Environments work with virtual networks and on-premises networks consult the following articles on [Network Architecture][NetworkArchitectureOverview], [Controlling Inbound Traffic][ControllingInboundTraffic], and [Securely Connecting to Backends][SecurelyConnectingToBackends].

+[AppServicePricing]: https://azure.microsoft.com/pricing/details/app-service/

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+![Conceptual Architecture][ConceptualArchitecture]

+The green plus signs indicate that the network security group on the subnet containing "apiase" allows inbound calls from the upstream web apps, as well calls from itself. However the same network security group explicitly denies access to general inbound traffic from the Internet.

+In order to know what network security rules are needed, you need to determine which network clients will be allowed to reach the App Service Environment containing the API app, and which clients are blocked.

+Since [network security groups (NSGs)][NetworkSecurityGroups] are applied to subnets, and App Service Environments are deployed into subnets, the rules contained in an NSG apply to **all** apps running on an App Service Environment. Using the sample architecture for this article, once a network security group is applied to the subnet containing "apiase," all apps running on the "apiase" App Service Environment will be protected by the same set of security rules.

+* **Determine the outbound IP address of upstream callers:** What is the IP address or addresses of the upstream callers? These addresses need to be explicitly allowed access in the NSG. Since calls between App Service Environments are considered "Internet" calls, the outbound IP address assigned to each of the three upstream App Service Environments needs to be allowed access in the NSG for the "apiase" subnet. For more information on determining the outbound IP address for apps running in an App Service Environment, see the [Network Architecture][NetworkArchitecture] Overview article.

+* **Will the back-end API app need to call itself?** A sometimes overlooked and subtle point is the scenario where the back-end application needs to call itself. If a back-end API application on an App Service Environment needs to call itself, it's also treated as an "Internet" call. In the sample architecture, this requires allowing access from the outbound IP address of the "apiase" App Service Environment as well.

+Once the set of outbound IP addresses are known, the next step is to construct a network security group. Network security groups can be created for both Resource Manager based virtual networks, and classic virtual networks. The following examples show creating and configuring an NSG on a classic virtual network using PowerShell.

+The full list of rules in the network security group are shown. Note how the last rule, which is highlighted, blocks inbound access from all callers, other than callers that are explicitly granted access.

+![NSG Configuration][NSGConfiguration]

+## Extra Links and Information

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+App Service Environments are always created within a subnet of a [virtual network][virtualnetwork] - apps running in an App Service Environment can communicate with private endpoints located within the same virtual network topology. Since customers might lock down parts of their virtual network infrastructure, it's important to understand the types of network communication flows that occur with an App Service Environment.

+When an App Service Environment (ASE) uses a public virtual IP address (VIP) for apps, all inbound traffic arrives on that public VIP. This traffic includes HTTP and HTTPS traffic for apps, and other traffic for FTP, remote debugging functionality, and Azure management operations. For a full list of the specific ports (both required and optional) that are available on the public VIP see the article on [controlling inbound traffic][controllinginboundtraffic] to an App Service Environment.

+App Service Environments also support running apps that are bound only to a virtual network internal address, also referred to as an ILB (internal load balancer) address. On an ILB enabled ASE, HTTP, and HTTPS traffic for apps and remote debugging calls, arrive on the ILB address. For most common ILB-ASE configurations, FTP/FTPS traffic also arrives on the ILB address. However Azure management operations flow to ports 454/455 on the public VIP of an ILB enabled ASE.

+The following diagram shows an overview of the various inbound and outbound network flows for an App Service Environment where the apps are bound to a public virtual IP address:

+An App Service Environment can communicate with private customer endpoints. For example, apps running in the App Service Environment can connect to database servers running on IaaS virtual machines in the same virtual network topology.

+>

+>

+App Service Environments also communicate with Sql DB and Azure Storage resources necessary for managing and operating an App Service Environment. Some of the Sql and Storage resources that an App Service Environment communicates with are located in the same region as the App Service Environment, while others are located in remote Azure regions. As a result, outbound connectivity to the Internet is always required for an App Service Environment to function properly.

+When an App Service Environment makes outbound calls, an IP Address is always associated with the outbound calls. The specific IP address depends on whether the endpoint being called is located within the virtual network topology, or outside of the virtual network topology.

+If the endpoint being called is **outside** of the virtual network topology, then the outbound address (also known as the outbound NAT address) is the public VIP of the App Service Environment. This address can be found in the portal user interface for the App Service Environment in Properties section.

+This address can also be determined for ASEs that only have a public VIP by creating an app in the App Service Environment, and then performing a *nslookup* on the app's address. The resultant IP address is both the public VIP, and the App Service Environment's outbound NAT address.

+If the endpoint being called is **inside** of the virtual network topology, the outbound address of the calling app is the internal IP address of the individual compute resource running the app. However there isn't a persistent mapping of virtual network internal IP addresses to apps. Apps can move around across different compute resources, and the pool of available compute resources in an App Service Environment can change due to scaling operations.

+The following diagram shows an example of a layered architecture with apps on one App Service Environment (for example "Front door" web apps) calling apps on a second App Service Environment (for example internal back-end API apps not intended to be accessible from the Internet).

+![Calls Between App Service Environments][CallsBetweenAppServiceEnvironments]

+Even though calls between different App Service Environments are treated as "Internet" calls, when both App Service Environments are located in the same Azure region the network traffic will remain on the regional Azure network and won't physically flow over the public Internet. As a result you can use a network security group on the subnet of the second App Service Environment to only allow inbound calls from the first App Service Environment (whose outbound IP address is 192.23.1.2), thus ensuring secure communication between the App Service Environments.

+Details on using user-defined routes to grant outbound Internet access to App Service Environments is available in this [article][ExpressRoute].

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+- Virtual networks that use public address ranges or RFC1918 address spaces (that is, private addresses).

+- Outbound network connectivity to Azure Storage endpoints worldwide on both port 80 and port 443. These endpoints are located in the same region as App Service Environment and also other Azure regions. Azure Storage endpoints resolve under the following DNS domains: table.core.windows.net, blob.core.windows.net, queue.core.windows.net, and file.core.windows.net.

+- Outbound network connectivity to the Azure Files service on port 445.

+- Outbound network connectivity to Azure SQL Database endpoints that are located in the same region as App Service Environment. SQL Database endpoints resolve under the database.windows.net domain, which requires open access to ports 1433, 11000-11999, and 14000-14999. For details about SQL Database V12 port usage, see [Ports beyond 1433 for ADO.NET 4.5](/azure/azure-sql/database/adonet-v12-develop-direct-route-ports).

+- Outbound network connectivity to the Azure management-plane endpoints (both Azure classic deployment model and Azure Resource Manager endpoints). Connectivity to these endpoints includes the management.core.windows.net and management.azure.com domains.

+- Outbound network connectivity to the ocsp.msocsp.com, mscrl.microsoft.com, and crl.microsoft.com domains. Connectivity to these domains is needed to support TLS functionality.

+- The DNS configuration for the virtual network must be able to resolve all endpoints and domains mentioned in this article. If the endpoints can't be resolved, App Service Environment creation fails. Any existing App Service Environment is marked as unhealthy.

+- Outbound access on port 53 is required for communication with DNS servers.

+- If a custom DNS server exists on the other end of a VPN gateway, the DNS server must be reachable from the subnet that contains App Service Environment.

+- The outbound network path can't travel through internal corporate proxies and can't be force tunneled on-premises. These actions change the effective NAT address of outbound network traffic from App Service Environment. Changes to the NAT address of App Service Environment outbound network traffic cause connectivity failures to many of the endpoints. App Service Environment creation fails. Any existing App Service Environment is marked as unhealthy.

+- Inbound network access to required ports for App Service Environment must be allowed. For details, see [How to control inbound traffic to App Service Environment][requiredports].

+- The ExpressRoute configuration advertises 0.0.0.0/0. By default, the configuration force tunnels all outbound traffic on-premises.

+- The UDR applied to the subnet that contains App Service Environment defines 0.0.0.0/0 with a next hop type of internet. An example of this configuration is described later in this article.

+>

+>

+>

+- Install Azure PowerShell from the [Azure Downloads page][AzureDownloads]. Choose a download with a date of June 2015 or later. Under **Command-line tools** > **Windows PowerShell**, select **Install** to install the latest PowerShell cmdlets.

+- Create a unique subnet for exclusive use by App Service Environment. The unique subnet ensures that the UDRs applied to the subnet open outbound traffic for App Service Environment only.

+0.0.0.0/0 is a broad address range. The range is overridden by address ranges advertised by ExpressRoute that are more specific. A UDR with a 0.0.0.0/0 route should be used in conjunction with an ExpressRoute configuration that advertises 0.0.0.0/0 only.

+>

+- Outbound traffic to the Azure and non-Azure endpoints described in this article does **not** flow down the ExpressRoute circuit. If outbound traffic from the subnet is force tunneled on-premises, App Service Environment creation always fails.

+- DNS lookups for the endpoints described in this article all resolve properly.

+[virtualnetwork]: https://azure.microsoft.com/services/virtual-network/

+[ExpressRoute]: https://azure.microsoft.com/services/expressroute/

+[requiredports]: app-service-app-service-environment-control-inbound-traffic.md

+[AzureDownloads]: https://azure.microsoft.com/downloads/

+[DownloadCenterAddressRanges]: https://www.microsoft.com/download/details.aspx?id=41653

+[IntroToAppServiceEnvironment]: app-service-app-service-environment-intro.md

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+Although the virtual machine has a public endpoint as well, connection attempts to use the public IP address will be rejected because of the network ACL.

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+From there, the interface should be fairly familiar since it is the same experience that you see when you scale an App Service plan.

+The production App Service plan can grow at a maximum rate of eight instances/hour

+during the week and four instances/hour during the weekend. It can release instances

+For this scenario, Frank knows that the error rate increases after front ends

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+* A Classic(V1) or Resource Manager(V2) Azure Virtual Network (virtual network)

+The hosts in the resource pools (front ends and workers) aren't directly accessible to tenants. You can't use Remote Desktop Protocol (RDP) to connect to them, change their provisioning, or act as an admin on them.

+* For moderate to heavy production workloads, we recommend that you have at least four P3s to ensure there are sufficient front ends running when scheduled maintenance occurs. Scheduled maintenance activities bring down one front end at a time. This reduces overall available front-end capacity during maintenance activities.

+* Front ends can take up to an hour to deploy.

+**Workers**: The workers are where your apps run. When you scale up your App Service plans, that uses up workers in the associated worker pool.

+* You can't instantly add workers. They might take up to an hour to deploy.

+* Scaling the size of a compute resource for any pool takes < 1 hour per update domain. There are 20 update domains in an ASE. If you scaled the compute size of a worker pool with 10 instances, it could take up to 10 hours to complete.

+* If you change the size of the compute resources that are used in a worker pool, you'll cause cold starts of the apps that are running in that worker pool.

+The fastest way to change the compute resource size of a worker pool that isn't running any apps is to:

+* Scale down the quantity of workers to 2. The minimum scale down size in the portal is 2. It will take a few minutes to deallocate your instances.

+If you want to set autoscale rules around compute resource pool metrics, then keep in mind the time that provisioning requires. For more information about autoscaling App Service Environments, see [How to configure autoscale in an App Service Environment][ASEAutoscale].

+Each ASE is configured with 500 GB of storage. This space is used across all the apps in the ASE. This storage space is a part of the ASE and currently can't be switched to use your storage space. If you're making adjustments to your virtual network routing or security, you need to still allow access to Azure Storage--or the ASE can't function.

+The database holds the information that defines the environment, and the details about the apps that are running within it. This too is a part of the Azure-held subscription. It's not something that you have a direct ability to manipulate. If you're making adjustments to your virtual network routing or security, you need to still allow access to SQL Azure--or the ASE can't function.

+The virtual network that is used with your ASE can be one that you made when you created the ASE or one that you made ahead of time. When you create the subnet during ASE creation, it forces the ASE to be in the same resource group as the virtual network. If you need the resource group used by your ASE to be different than that of your virtual network, then you need to create your ASE using an Azure Resource Manager template.

+* There needs to be a subnet with eight or more addresses where the ASE is deployed.

+Unlike the hosted service that contains the ASE, the [virtual network][virtualnetwork] and subnet are under user control. You can administer your virtual network through the Virtual Network UI or PowerShell. An ASE can be deployed in a Classic or Resource Manager virtual network. The portal and API experiences are slightly different between Classic and Resource Manager VNets but the ASE experience is the same.

+The virtual network that is used to host an ASE can use either private RFC1918 IP addresses or it can use public IP addresses. If you wish to use an IP range that isn't covered by RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) then you need to create your virtual network and subnet to be used by your ASE ahead of ASE creation.

+Because this capability places the Azure App Service into your virtual network, it means that your apps that are hosted in your ASE can now access resources that are made available through ExpressRoute or site-to-site virtual private networks (VPNs) directly. The apps that are within your App Service Environment don't require extra networking features to access resources available to the virtual network that is hosting your App Service Environment. This means that you don't need to use virtual network Integration or Hybrid Connections to get to resources in or connected to your virtual network. You can still use both of those features though to access resources in networks that aren't connected to your virtual network.

+For example, you can use virtual network Integration to integrate with a virtual network that is in your subscription but isn't connected to the virtual network that your ASE is in. You can still also use Hybrid Connections to access resources that are in other networks, just like you normally can.

+If you do have your virtual network configured with an ExpressRoute VPN, you should be aware of some of the routing needs that an ASE has. There are some user-defined route (UDR) configurations that are incompatible with an ASE. For more information about running an ASE in a virtual network with ExpressRoute, see [Running an App Service Environment in a virtual network with ExpressRoute][ExpressRoute].

+When you create an ASE, it will create a VIP in your virtual network. There are two VIP types, external and internal. When you create an ASE with an external VIP then your apps in your ASE will be accessible via an internet routable IP address. When you select Internal your ASE will be configured with an ILB and won't be directly internet accessible. An ILB ASE still requires an external VIP but it's only used for Azure management and maintenance access.

+During ILB ASE creation you provide the subdomain used by the ILB ASE and will have to manage your own DNS for the subdomain you specify. Because you set the subdomain name, you also need to manage the certificate used for HTTPS access. After ASE creation, you're prompted to provide the certificate. To learn more about creating and using an ILB ASE read [How to Create an ASEv1 from template](app-service-app-service-environment-create-ilb-ase-resourcemanager.md).

+You can manage and monitor your App Service Environment by using the UI in the Azure portal. If you have an ASE, then you're likely to see the App Service symbol on your sidebar. This symbol is used to represent App Service Environments in the Azure portal:

+Multiple App Service plans can make use of the workers in a worker pool. The workload isn't distributed in the same fashion as with the front-end servers, so the CPU and memory usage don't provide much in the way of useful information. It's more important to track how many workers that you have used and are available--especially if you're managing this system for others to use.

+The metrics that were discussed are the App Service Environment metrics. There are also metrics that are available at the App Service plan level. This is where monitoring CPU and memory makes a lot of sense.

+In an ASE, all of the App Service plans are dedicated App Service plans. That means that the only apps that are running on the hosts allocated to that App Service plan are the apps in that App Service plan. To see details on your App Service plan, bring up your App Service plan from any of the lists in the ASE UI or from **Browse App Service plans** (which lists all of them).

+Within the ASE blade, there's a **Settings** section that contains several important capabilities:

+**Settings** > **Properties**: The **Settings** blade automatically opens when you bring up your ASE blade. At the top is **Properties**. There are many items in here that are redundant to what you see in **Essentials**, but what is useful is **Virtual IP Address**, and **Outbound IP Addresses**.

+**Settings** > **IP Addresses**: When you create an IP Secure Sockets Layer (SSL) app in your ASE, you need an IP SSL address. In order to obtain one, your ASE needs IP SSL addresses that it owns that can be allocated. When an ASE is created, it has one IP SSL address for this purpose, but you can add more. There's a charge for extra IP SSL addresses, as shown in [App Service pricing][AppServicePricing] (in the section on SSL connections). The additional price is the IP SSL price.

+* A scale operation from the main ASE blade at the top. You can make multiple scale configuration changes to the front-end and worker pools. They're all applied as a single operation.

+You can configure an App Service Environment to use up to 55 total compute resources. Of those 55 compute resources, only 50 can be used to host workloads. The reason for this is twofold. There's a minimum of two front-end compute resources. That leaves up to 53 to support the worker-pool allocation. In order to provide fault tolerance, you need to have an additional compute resource that is allocated according to the following rules:

+* Each worker pool needs at least one additional compute resource that isn't available to be assigned a workload.

+* When the quantity of compute resources in a worker pool goes above a certain value, then another compute resource is required for fault tolerance. This isn't the case in the front-end pool.

+The minimum footprint has two front-end servers and two workers. With the above statements then, here are a few examples to clarify:

+* If you have two workers in a single pool, then 1 can be used to host workloads.

+> This article is about App Service Environment v1. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+In the Azure App Service, there are normally three things you can scale:

+* worker size

+In an ASE, there's no need to select or change the pricing plan. In terms of capabilities it's already at a Premium pricing capability level.

+With respect to worker sizes, the ASE admin can assign the size of the compute resource to be used for each worker pool. That means you can have Worker Pool 1 with P4 compute resources and Worker Pool 2 with P1 compute resources, if desired. They don't have to be in size order. For details around the sizes and their pricing see the document here [Azure App Service Pricing][AppServicePricing]. This leaves the scaling options for web apps and App Service Plans in an App Service Environment to be:

+You can't scale up your ASP beyond the number of available compute resources in the worker pool that your ASP is in. If you need compute resources in that worker pool, you need to get your ASE administrator to add them. For information around reconfiguring your ASE read the information here: [How to Configure an App Service environment][HowtoConfigureASE]. You might also want to take advantage of the ASE autoscale features to add capacity based on schedule or metrics. To get more details on configuring autoscale for the ASE environment, itself see [How to configure autoscale for an App Service Environment][ASEAutoscale].

+When you first create your web app in an App Service Environment, it starts with one instance. You can then scale out to more instances to provide extra compute resources for your app.

+If your ASE has enough capacity, then this is simple. You go to your App Service Plan that holds the sites you want to scale up and select Scale. This opens the UI where you can manually set the scale for your ASP or configure autoscale rules for your ASP. To manually scale your app set Scale by to an instance count that, I enter manually***. From here either drag the slider to the desired quantity or enter it in the box next to the slider.

+![Screenshot that shows where you can set the scale for your ASP or configure autoscale rules for your ASP.][2]

+The autoscale rules for an ASP in an ASE work the same as they do normally. You can select ***CPU Percentage*** under ***Scale by*** and create autoscale rules for your ASP based on CPU Percentage or you can create more complex rules using ***schedule and performance rules***. To see more complete details on configuring autoscale use the guide here [Scale an app in Azure App Service][AppScale].

+As noted earlier, the worker pool selection is accessed from the ASP UI. Open the page for the ASP that you want to scale and select worker pool. You see all of the worker pools which you configured in your App Service Environment. If you have only one worker pool, then you only see the one pool listed. To change what worker pool your ASP is in, you select the worker pool you want your App Service Plan to move to.

+Before moving your ASP from one worker pool to another, it's important to make sure you have adequate capacity for your ASP. In the list of worker pools, not only is the worker pool name listed but you can also see how many workers are available in that worker pool. Make sure that there are enough instances available to contain your App Service Plan. If you need more compute resources in the worker pool you wish to move to, then get your ASE administrator to add them.

+> Moving an ASP from one worker pool will cause cold starts of the apps in that ASP. This can cause requests to run slowly as your app is cold started on the new compute resources. The cold start can be avoided by using the [application warm up capability][AppWarmup] in Azure App Service. The Application Initialization module described in the article also works for cold starts because the initialization process is also invoked when apps are cold started on new compute resources.

+>

+>

+[AppServicePricing]: https://azure.microsoft.com/pricing/details/app-service/

+ Title: Prevent and recover from an auto-migration of an App Service Environment

+description: Learn how to prevent and address issues related to an auto-migration to App Service Environment v3.

+# Prevent and resolve issues caused by an auto-migration of an App Service Environment

+> [!IMPORTANT]

+> App Service Environment v1 and v2 are retired and no longer supported. If you have an App Service Environment v1 or v2, you must migrate to App Service Environment v3. For more information, see [Upgrade to App Service Environment v3](upgrade-to-asev3.md).

+>

+> Auto-migrations are migrations that are initiated by Microsoft. As of September 1, 2024, the platform will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration is not feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+If you have an App Service Environment v1 or v2 that was auto-migrated to App Service Environment v3, you might encounter issues with your apps or services. This article provides guidance on how to address these issues.

+## Overview

+After September 1, 2024, all App Service Environments v1 and v2 are eligible to be automatically migrated (auto-migrated) to App Service Environment v3 at any given time unless otherwise stated. The platform initiates auto-migrations, which are necessary to ensure that your App Service Environment is running on a supported platform.

+> [!NOTE]

+> Auto-migrations and deletions are done in batches. If your App Service Environment isn't auto-migrated yet, it's subject to auto-migration or deletion at any time. The only way to ensure that your App Service Environment isn't unexpectedly auto-migrated or deleted is to request a 30-day grace period.

+>

+Auto-migrations are done using the [in-place migration feature](migrate.md). There's about one hour of downtime during the migration process. The inbound and outbound IP addresses of your App Service Environment might change during the migration process. Downtime might be longer if you have dependencies on these IP addresses. Downtime might also be longer if you use features that aren't supported in App Service Environment v3.

+## Grace period

+If you need more time to complete your migrations, we can offer a one-time 30-day grace period. Your App Service Environment isn't auto-migrated or deleted during the grace period. When the grace period ends, we attempt to auto-migrate your App Service Environment. If auto-migration isn't feasible, your resources and associated app data are deleted.

+To receive this grace period, go to [Azure portal](https://portal.azure.com) and visit the Migration page for your App Service Environment. If you have more than one App Service Environment, you need to acknowledge and receive a grace period for each of your environments that requires more time to migrate.

+Once you receive the grace period, the banner at the top of the Migration page shows the grace period end date. You might need to refresh the page to see the updated banner. It can take up to five minutes for the banner to update with the date.

+If you need more support or have questions, contact Azure Support using the *Open support ticket* option in the Azure portal on the Migration page. It's important that you acknowledge and receive a grace period for each of your environments that require more time to migrate before you open the support request. The acknowledgment and grace period ensures your environments don't get auto-migrated while the support request is being processed.

+## Auto-migration limitations

+Auto-migrations are done using the [in-place migration feature](migrate.md). The following limitations apply to auto-migrations, similar to the [limitations of in-place migrations](migrate.md#in-place-migration-feature-limitations):

+- The new App Service Environment v3 is in the existing subnet that was used for your old environment.

+- The new App Service Environment v3 is in the same region as your old environment.

+- The new App Service Environment v3 is in the same resource group as your old environment.

+- All resources maintain the same names and resource IDs.

+- IP-based TLS/SSL bindings aren't supported in App Service Environment v3. If you have IP-based TLS/SSL bindings, you must remove them once the migration is complete. Your apps don't work until you remove the bindings.

+- App Service Environment v1 in a [Classic virtual network](/previous-versions/azure/virtual-network/create-virtual-network-classic) isn't supported for migration. If you have an App Service Environment v1 in a Classic virtual network, you must [migrate manually](migration-alternatives.md). **Your App Service Environment is eligible for deletion at any time if you don't request a 30-day grace period.**

+- The in-place migration feature isn't available in China East 2 and China North 2. The feature isn't supported there because App Service Environment v3 isn't available in these regions. Therefore, auto-migration isn't possible for App Service Environments in these regions. If you have an App Service Environment in these regions, you must [migrate manually](migration-alternatives.md) to one of the supported regions, such as China East 3 or China North 3. **Your App Service Environment is eligible for deletion at any time if you don't request a 30-day grace period.**

+For more information about in-place migrations and to see what process is followed during an auto-migration, see the [Migration to App Service Environment v3 using the in-place migration feature](migrate.md).

+### Ineligible for auto-migration

+There are two scenarios where you might be ineligible for auto-migration. The first scenario is if your current environment is in a region that doesn't support App Service Environment v3. The other scenario is if you have an App Service Environment v1 in a Classic virtual network. If you're ineligible for auto-migration and can never auto-migrate, the portal displays a message with the reason why you're ineligible. You must [migrate manually](migration-alternatives.md). **Your App Service Environment is eligible for deletion at any time if you don't request a 30-day grace period.**

+In some cases, you might be temporarily blocked from auto-migration, but you can resolve the blocking issue and enable auto-migration. For example, if you have a resource lock on your App Service Environment, you can remove the resource lock to enable auto-migration. An auto-migration that is blocked by a resource lock, Azure Policy, or networking configuration is automatically suspended. If you need to unsuspend your App Service Environment, open a support ticket.

+The following errors might be displayed in the portal if you're ineligible for auto-migration:

+|Error |Recommendation |

+|||

+|The App Service Environment v1 is in a Classic virtual network. Classic virtual networks don't support App Service Environment v3. |You must [migrate manually](migration-alternatives.md). |

+|There's a resource lock on the App Service Environment/virtual network/resource group/subscription that's preventing the migration. |To enable auto-migration, remove the resource lock. |

+|There's an [Azure Policy](../../governance/policy/overview.md) that's preventing the migration. |To enable auto-migration, remove any Azure Policy that blocks resource modifications or deletions for the App Service Environment or the virtual network the environment is in. |

+|The App Service Environment is in a region that doesn't support auto-migration. |You must [migrate manually](migration-alternatives.md). |

+## What to do if your App Service Environment is suspended

+If your App Service Environment is suspended, you have two options.

+### Unsuspend and self-migrate

+If you want to migrate yourself, open a support ticket using the option in the Migration page to see if we can unsuspend your App Service Environment. **We don't guarantee that we can unsuspend your environment**.

+### Resume/unsuspend as App Service Environment v3

+If you want to expedite migration, you can resume/unsuspend your environment as an **App Service Environment v3**. To resume your App Service Environment as a v3, go to the [Azure portal](https://portal.azure.com) and visit the Migration page for your App Service Environment. To resume your environment as an App Service Environment v3, select the "Migrate now" button. This button initiates the same process that is used for auto-migrations. The limitations, downtime, and other considerations are the same as for auto-migrations. If you have more than one App Service Environment, you need to resume each of your environments that are suspended.

+## Features to limit the effects of auto-migrations

+To limit the effect of auto-migrations, we implemented the following features to the auto-migration feature.

+### Outbound IP address preservation

+Previously, the outbound IP address of your App Service Environment was always changed during the migration process. Now, the outbound IP address of your App Service Environment might be preserved during the migration process. The App Service Environment v1/v2 public IP address might be preserved and is used as the outbound IP address of the App Service Environment v3. **We don't guarantee that we can preserve your outbound IP address**. However, App Service Environment v3 has two outbound IP addresses. If you have a custom domain suffix configuration and you connect to your Azure Key Vault over the public internet, you might still need to account for the other new outbound IP address.

+For internal load balancer (ILB) App Service Environment migrations, the inbound IP is always preserved. This functionality remains the same during auto-migration.

+For external load balancer (ELB) App Service Environment migrations, the inbound IP still changes. This change might affect you if you use A records to point to the inbound IP address of your App Service Environment. If you use A records, you must update the A records to point to the new inbound IP address after the migration process is complete. If you use CNAME records, you likely don't need to make any DNS changes. If you have any other dependencies on the inbound IP address, you must update them accordingly.

+### App Service Environment v2 custom domain suffix configuration compatibility

+[Custom domain suffix on App Service Environment v3](how-to-custom-domain-suffix.md) is implemented differently than on App Service Environment v2. On App Service Environment v2, the certificate is uploaded directly to the App Service Environment. Additionally, nonwildcard certificates are allowed. On App Service Environment v3, the certificate must be stored in Azure Key Vault and the App Service Environment must be able to access the key vault. Also, nonwildcard certificates aren't allowed.

+To reduce the effect of auto-migrations, we implemented a limited compatibility mode for App Service Environment v2 custom domain suffix configurations on App Service Environment v3. If you have a custom domain suffix configuration on App Service Environment v2, the configuration is migrated to App Service Environment v3. The certificate is uploaded to the App Service Environment v3 and the configuration is updated to use the uploaded certificate. This process is done as a temporary measure and is only valid until the current certificate expires. You must [update the configuration to use Azure Key Vault](how-to-custom-domain-suffix.md) after the migration process is complete and before the certificate expires. If you don't update the configuration, once the certificate expires, the custom domain suffix doesn't work. For more information, see [Custom domain suffix on App Service Environment v3](how-to-custom-domain-suffix.md).

+> [!IMPORTANT]

+> Even with the custom domain suffix compatibility mode, your custom domain suffix configuration might not work as expected. **We don't guarantee that your custom domain suffix will work after auto-migration.** We strongly recommend that you update the configuration to use Azure Key Vault as soon as possible after the migration process is complete.

+>

+### Migration support for apps with IP-based TLS/SSL bindings

+IP-based TLS/SSL bindings aren't supported in App Service Environment v3. Previously, the migration feature only allowed you to migrate once you removed the bindings. To enable auto-migrations, the automatic validation to check for IP-based TLS/SSL bindings is removed. If you have IP-based TLS/SSL bindings, you must remove them once the migration is complete. Your apps don't work until you remove the bindings.

+## Address issues caused by an auto-migration

+The following are issues you might encounter with your apps or services after an auto-migration. If your issue isn't listed here and you need assistance, contact [Azure Support](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade).

+### Issue: App Service Environment v3 is using the old custom domain suffix configuration

+If you have a custom domain suffix configuration on App Service Environment v2, the configuration is migrated to App Service Environment v3. The certificate is uploaded to the App Service Environment v3 and the configuration is updated to use the uploaded certificate. This process is done as a temporary measure and is only valid until the current certificate expires. **We don't guarantee that your old custom domain suffix configuration will work after auto-migration.**

+To address this incompatibility, you must [update the configuration to use Azure Key Vault](how-to-custom-domain-suffix.md) after the migration process is complete and before the certificate expires. If you don't update the configuration, once the certificate expires, the custom domain suffix doesn't work. To update the custom domain suffix configuration, follow the steps in [Custom domain suffix on App Service Environment v3](how-to-custom-domain-suffix.md).

+### Issue: Apps on App Service Environment v3 have IP-based TLS/SSL bindings

+IP-based TLS/SSL bindings aren't supported in App Service Environment v3. You must remove the bindings once the migration is complete. Your apps don't work until you remove the bindings.

+### Issue: Dependent resources are't updated to use the new inbound IP address

+ILB App Service Environment migrations preserve the inbound IP address, so no action is needed.

+ELB App Service Environment migrations change the inbound IP address. If you use A records to point to the inbound IP address of your App Service Environment, you must update the A records to point to the new inbound IP address after the migration process is complete. If you use CNAME records, you likely don't need to make any DNS changes. If you have any other dependencies on the inbound IP address, you must update them accordingly. The old inbound IP address is no longer valid after the migration process is complete.

+### Issue: Dependent resources aren't updated to use the new outbound IP address

+App Service Environment v3 has two outbound IP addresses. After the migration process, your existing outbound IP address might be preserved, but another outbound IP is created. You might need to account for this other new outbound IP address if you have a custom domain suffix configuration and connect to your Azure Key Vault over the public internet. If your original outbound IP address isn't preserved, you must account for this change as well.

+### Issue: Feature change or incompatibility with App Service Environment v3

+In general, App Service Environment v3 is compatible with App Service Environment v1 and v2. However, there are some differences. To see the differences between the versions, review the [App Service Environment version comparison](version-comparison.md). If you're using a feature that isn't supported or behaves differently on App Service Environment v3, you must update your apps accordingly.

+The following are notable changes in App Service Environment v3:

+- IP-based TLS/SSL bindings aren't supported.

+- Custom domain suffix configuration is different.

+- Default domain is always maintained even if you have a custom domain suffix.

+- Nonwildcard certificates for custom domain suffix aren't allowed.

+- App Service Environment v3 has two outbound IP addresses.

+- The [available SKUs](https://azure.microsoft.com/pricing/details/app-service/windows/) are different sizes.

+- The [pricing model](overview.md#pricing) is different.

+- The [networking model](networking.md) is different.

+- FTPS endpoint structure is different. Access to FTPS endpoint using custom domain suffix isn't supported.

+- App Service Environment v3 doesn't fall back to Azure DNS if your configured custom DNS servers in the virtual network aren't able to resolve a given name. If this behavior is required, ensure that you have a forwarder to a public DNS or include Azure DNS in the list of custom DNS servers.

+## Pricing

+There's no cost associated with auto-migrating your App Service Environment. You stop being charged for your previous App Service Environment as soon as it shuts down during the migration process. You begin getting charged for your new App Service Environment v3 as soon as it gets deployed. For more information about App Service Environment v3 pricing, see the [pricing details](overview.md#pricing).

+When you migrate to App Service Environment v3 from previous versions, there are scenarios that you should consider that can potentially reduce your monthly cost. Consider [reservations](../../cost-management-billing/reservations/reservation-discount-app-service.md#how-reservation-discounts-apply-to-isolated-v2-instances) and [savings plans](../../cost-management-billing/savings-plan/savings-plan-compute-overview.md) to further reduce your costs. For information on cost saving opportunities, see [Cost saving opportunities after upgrading to App Service Environment v3](upgrade-to-asev3.md#cost-saving-opportunities-after-upgrading-to-app-service-environment-v3).

+> [!NOTE]

+> Due to the conversion of App Service plans from Isolated to Isolated v2, your apps may be over-provisioned after the migration since the Isolated v2 tier has more memory and CPU per corresponding instance size. You'll have the opportunity to [scale your environment](../manage-scale-up.md) as needed once migration is complete. For more information, review the [SKU details](https://azure.microsoft.com/pricing/details/app-service/windows/).

+>

+### Scale down your App Service plans

+The App Service plan SKUs available for App Service Environment v3 run on the Isolated v2 (Iv2) tier. The number of cores and amount of RAM are effectively doubled per corresponding tier compared the Isolated tier. When you migrate, your App Service plans are converted to the corresponding tier. For example, your I2 instances are converted to I2v2. While I2 has two cores and 7-GB RAM, I2v2 has four cores and 16-GB RAM. If you expect your capacity requirements to stay the same, you're over-provisioned and paying for compute and memory you're not using. For this scenario, you can scale down your I2v2 instance to I1v2 and end up with a similar number of cores and RAM that you had previously.

+## Support policy after retirement for App Service Environment v1 and v2

+The following statement represents the Azure App Service Environment v1 and v2 support policy as of September 1, 2024. It doesn't affect your workloads running on App Service Environment v3.

+This support policy expires at the end of any extension or grace-period that you have been granted written approval by Microsoft to run the services past the scheduled retirement date. Failure to migrate by that date will result in all remaining Azure App Service Environments v1 and v2 being retired which may include but not be limited to deletion of the apps and data, automated in-place migration, and other retirement procedures.

+The extended support policy includes the following items:

+

+- As of September 1, 2024, the [Service Level Agreement (SLA)](https://aka.ms/postEOL/ASE/SLA) is no longer applicable for App Service Environment v1 and v2. Through continued use of the product beyond the retirement date, you acknowledge that Azure doesn't commit to the SLA of 99.95% for the retired environment.

+- We're committed to maintaining the platform and allowing you to complete your migrations. Therefore, Customer Support Services (CSS) and Product Group (PG) support channels will continue to handle support cases and Critical Response Incidents (CRIs) in a commercially reasonable manner. No new security and compliance investments will be made in App Service Environment v1 and v2.

+- App Service will continue to patch the operating system and language runtimes in accordance with the platformΓÇÖs update processes documented [here](../overview-patch-os-runtime.md).

+- App Service will continue to test and validate Azure App Service updates prior to roll out and will continue to follow safe deployment procedures for platform updates.

+- App Service will continue to actively monitor the production footprint of Azure App Service Environment v1/v2 and will continue to respond to issues detected via this monitoring with the same urgency as today.

+- Microsoft will continue to accept Azure App Service support cases and drive resolution of Azure App Service issues in a timely manner.

+- App Service will continue to apply patches and hotfixes for critical Azure App Service platform bugs that might arise.

+- However, the ability to effectively mitigate issues that might arise from lower-level Azure dependencies might be impaired due to retirement affecting all Cloud Services and Azure Service Management (ASM)/RedDog Front End (RDFE) components.

+We encourage you to complete migration to Azure App Service Environment v3 as soon as possible to avoid disruption to your services. Our team is available to assist you with the migration process and to answer any questions you might have. For more information on the retirement and migration steps, available resources, and benefits of migrating, see the [product documentation](upgrade-to-asev3.md).

+## Frequently asked questions

+- **Why am I experiencing temporary application outages on my App Service Environment v1/v2?**

+ The Azure platform is preparing for the retirement of Cloud Services (Classic), which is the infrastructure that App Service Environment v1 and v2 run on. As part of this preparation, you should expect temporary outages and service disruptions. To minimize the effect of these disruptions, we recommend that you migrate to App Service Environment v3 as soon as possible.

+- **Why was my App Service Environment auto-migrated?**

+ App Service Environment v1 and v2 are retired and no longer supported. The supporting infrastructure for App Service Environment v1 and v2 is being decommissioned. To ensure that your App Service Environment is running on a supported platform, Microsoft initiates auto-migrations to App Service Environment v3.

+- **Why are my apps not working after auto-migration?**

+ After an auto-migration, you might encounter issues with your apps or services due to feature updates or incompatibilities. To address these issues, see [Address issues caused by an auto-migration](#address-issues-caused-by-an-auto-migration).

+- **What is the downtime during the auto-migration process?**

+ There's about one hour of downtime during the auto-migration process. The inbound and outbound IP addresses of your App Service Environment might change during the migration process. Downtime might be longer if you have dependencies on these IP addresses. Downtime might also be longer if you use features that aren't supported in App Service Environment v3.

+- **Will I be charged for auto-migrations?**

+ There's no cost associated with auto-migrating your App Service Environment. You stop being charged for your previous App Service Environment as soon as it shuts down during the migration process. You begin getting charged for your new App Service Environment v3 as soon as it gets deployed.

+- **Why was my App Service Environment deleted?**

+ If auto-migration isn't feasible, your resources and associated app data are deleted. We strongly urge you to act now to avoid this scenario. If you need more time to complete your migrations, we can offer a one-time 30-day grace period. Your App Service Environment isn't deleted during the grace period. When the grace period ends, we might delete your App Service Environment and all associated data.

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+The App Service Environment(ASE) is a deployment of the Azure App Service that runs within your Azure Virtual Network(VNet). It can be deployed with an internet accessible application endpoint or an application endpoint that is in your virtual network. If you deploy the ASE with an internet accessible endpoint, that deployment is called an External ASE. If you deploy the ASE with an endpoint in your virtual network, that deployment is called an ILB ASE. You can learn more about the ILB ASE from the [Create and use an ILB ASE](./create-ilb-ase.md) document.

+The ASE is a single tenant system. Because it's single tenant, there are some features available only with an ASE that aren't available in the multitenant App Service.

+## ILB ASE certificates

+If you're using an External ASE, then your apps are reached at &lt;appname&gt;.&lt;asename&gt;.p.azurewebsites.net. By default all ASEs, even ILB ASEs, are created with certificates that follow that format. When you have an ILB ASE, the apps are reached based on the domain name that you specify when creating the ILB ASE. In order for the apps to support TLS, you need to upload certificates. Obtain a valid TLS/SSL certificate by using internal certificate authorities, purchasing a certificate from an external issuer, or using a self-signed certificate.

+- **Subject Alternative Name:** This attribute must include both *.[your-root-domain-here] and*.scm.[your-root-domain-here] for the wildcard ILB ASE certificate. If creating the certificate for your app, then it should be [appname].[your-root-domain-here] and [appname].scm.[your-root-domain-here].

+As a third variant, you can create an ILB ASE certificate that includes all of your individual app names in the SAN of the certificate instead of using a wildcard reference. The problem with this method is that you need to know up front the names of the apps that you're putting in the ASE or you need to keep updating the ILB ASE certificate.

+### Upload certificate to ILB ASE

+After an ILB ASE is created in the portal, the certificate must be set for the ILB ASE. Until the certificate is set, the ASE will show a banner that the certificate wasn't set.

+The certificate that you upload must be a .pfx file. After the certificate is uploaded, there's a time delay of approximately 20 minutes before the certificate is used.

+You can't create the ASE and upload the certificate as one action in the portal or even in one template. As a separate action, you can upload the certificate using a template as described in the [Create an ASE from a template](./create-from-template.md) document.

+When creating a self signed cert, you'll need to ensure the subject name has the format of CN={ASE_NAME_HERE}_InternalLoadBalancingASE.

+## Application certificates

+Apps that are hosted in an ASE can use the app-centric certificate features that are available in the multitenant App Service. Those features include:

+- SNI certificates

+- IP-based SSL, which is only supported with an External ASE. An ILB ASE doesn't support IP-based SSL.

+- KeyVault hosted certificates

+The instructions for uploading and managing those certificates are available in [Add a TLS/SSL certificate in Azure App Service](../configure-ssl-certificate.md). If you're simply configuring certificates to match a custom domain name that you have assigned to your web app, then those instructions will suffice. If you're uploading the certificate for an ILB ASE web app with the default domain name, then specify the scm site in the SAN of the certificate as noted earlier.

+## TLS settings

+## Private client certificate

+1. Generate a *.cer* file for your certificate.

+3. Go to SSL settings in the app. Click Upload Certificate. Select Public. Select Local Machine. Provide a name. Browse and select your *.cer* file. Select upload.

+5. Go to Application Settings. Create an App Setting WEBSITE_LOAD_ROOT_CERTIFICATES with the thumbprint as the value. If you have multiple certificates, you can put them in the same setting separated by commas and no whitespace like

+ 84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

+The certificate will be available by all the apps in the same app service plan as the app, which configured that setting. If you need it to be available for apps in a different App Service plan, you'll need to repeat the App Setting operation in an app in that App Service plan. To check that the certificate is set, go to the Kudu console and issue the following command in the PowerShell debug console:

+To perform testing, you can create a self signed certificate and generate a *.cer* file with the following PowerShell:

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+4. Select your OS (Windows, Linux, or Docker).

+5. Select the App Service plan, and then select **Create New**. Linux web apps and Windows web apps cannot be in the same App Service Plan, but can be in the same App Service Environment.

+6. In the **Location** drop-down list, select the region where you want to create the ASE. If you select an existing ASE, a new ASE isn't created. The App Service plan is created in the ASE that you selected.

+7. Select **Pricing tier**, and choose one of the **Isolated** pricing SKUs. If you choose an **Isolated** SKU card and a location that's not an ASE, a new ASE is created in that location. To start the process to create an ASE, select **Select**. The **Isolated** SKU is available only in conjunction with an ASE. You also can't use any other pricing SKU in an ASE other than **Isolated**.

+8. Enter the name for your ASE. This name is used in the addressable name for your apps. If the name of the ASE is _appsvcenvdemo_, the domain name is _.appsvcenvdemo.p.azurewebsites.net_. If you create an app named _mytestapp_, it's addressable at mytestapp.appsvcenvdemo.p.azurewebsites.net. You can't use white space in the name. If you use uppercase characters, the domain name is the total lowercase version of that name.

+ c. Select the size of the subnet. _Remember to select a size large enough to accommodate future growth of your ASE._ We recommend `/24`, which has 256 addresses and can handle a maximum-sized ASE. We don't recommend `/28`, for example, because only 16 addresses are available. Infrastructure uses at least seven addresses and Azure Networking uses another 5. In a `/28` subnet, you're left with a maximum scaling of 4 App Service plan instances for an External ASE and only 3 App Service plan instances for an ILB ASE.

+1. In the [Azure portal](https://portal.azure.com/), **Create a Resource** > **Web + Mobile** > **Web App for Containers.**

+1. Select the App Service plan, and then select **Create New**. Linux web apps and Windows web apps cannot be in the same App Service Plan, but can be in the same App Service Environment.

+1. In the **Location** drop-down list, select the region where you want to create the ASE. If you select an existing ASE, a new ASE isn't created. The App Service plan is created in the ASE that you selected.

+1. Select **Pricing tier**, and choose one of the **Isolated** pricing SKUs. If you choose an **Isolated** SKU card and a location that's not an ASE, a new ASE is created in that location. To start the process to create an ASE, select **Select**. The **Isolated** SKU is available only in conjunction with an ASE. You also can't use any other pricing SKU in an ASE other than **Isolated**.

+1. Enter the name for your ASE. This name is used in the addressable name for your apps. If the name of the ASE is _appsvcenvdemo_, the domain name is _.appsvcenvdemo.p.azurewebsites.net_. If you create an app named _mytestapp_, it's addressable at mytestapp.appsvcenvdemo.p.azurewebsites.net. You can't use white space in the name. If you use uppercase characters, the domain name is the total lowercase version of that name.

+ c. Select the size of the subnet. _Remember to select a size large enough to accommodate future growth of your ASE._ We recommend `/24`, which has 128 addresses and can handle a maximum-sized ASE. We don't recommend `/28`, for example, because only 16 addresses are available. Infrastructure uses at least seven addresses and Azure Networking uses another 5. In a `/28` subnet, you're left with a maximum scaling of 4 App Service plan instances for an External ASE and only 3 App Service plan instances for an ILB ASE.

+1. Select ΓÇ£Configure Container.ΓÇ¥

+ - Enter your custom image name (you can use Azure Container Registry, Docker Hub, and your own private registry). If you donΓÇÖt want to use your own custom container, you can just bring your code and use a built-in image with App Service on Linux, using the instructions above.

+1. Search the Azure Marketplace for **App Service Environment**, or select **Create a resource** > **Web Mobile** > **App Service Environment**.

+1. Enter the name of your ASE. This name is used for the apps created in the ASE. If the name is _mynewdemoase_, the subdomain name is _.mynewdemoase.p.azurewebsites.net_. If you create an app named _mytestapp_, it's addressable at mytestapp.mynewdemoase.p.azurewebsites.net. You can't use white space in the name. If you use uppercase characters, the domain name is the total lowercase version of the name. If you use an ILB, your ASE name isn't used in your subdomain but is instead explicitly stated during ASE creation.

+1. Select or specify a new resource group. The resource group used for your ASE must be the same one that's used for your VNet. If you select an existing VNet, the resource group selection for your ASE is updated to reflect that of your VNet. _You can create an ASE with a resource group that is different from the VNet resource group if you use a Resource Manager template._ To create an ASE from a template, see [Create an App Service environment from a template][MakeASEfromTemplate].

+1. Select your VNet and location. You can create a new VNet or select an existing VNet:

+ - If you select a new VNet, you can specify a name and location.

+ - The new VNet has the address range 192.168.250.0/23 and a subnet named default. The subnet is defined as 192.168.250.0/24. You can only select a Resource Manager VNet. The **VIP Type** selection determines if your ASE can be directly accessed from the internet (External) or if it uses an ILB. To learn more about these options, see [Create and use an internal load balancer with an App Service environment][MakeILBASE].

+ - If you select **External** for the **VIP Type**, you can select how many external IP addresses the system is created with for IP-based SSL purposes.

+ - If you select **Internal** for the **VIP Type**, you must specify the domain that your ASE uses. You can deploy an ASE into a VNet that uses public or private address ranges. To use a VNet with a public address range, you need to create the VNet ahead of time.

+ - If you select an existing VNet, a new subnet is created when the ASE is created. _You can't use a pre-created subnet in the portal. You can create an ASE with an existing subnet if you use a Resource Manager template._ To create an ASE from a template, see [Create an App Service Environment from a template][MakeASEfromTemplate].

+You can still create instances of the first version of App Service Environment (ASEv1). To start that process, search the Marketplace for **App Service Environment v1**. You create the ASE in the same way that you create the standalone ASE. When it's finished, your ASEv1 has two front ends and two workers. With ASEv1, you must manage the front ends and workers. They're not automatically added when you create your App Service plans. The front ends act as the HTTP/HTTPS endpoints and send traffic to the workers. The workers are the roles that host your apps. You can adjust the quantity of front ends and workers after you create your ASE.

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+Azure App Service environments (ASEs) can be created with an internet-accessible endpoint or an endpoint on an internal address in an Azure Virtual Network. When created with an internal endpoint, that endpoint is provided by an Azure component called an internal load balancer (ILB). The ASE on an internal IP address is called an ILB ASE. The ASE with a public endpoint is called an External ASE.

+When you create an ASE in the Azure portal, you can create your virtual network at the same time or choose a pre-existing virtual network to deploy into.

+When you create an ASE from a template, you must start with:

+A TLS/SSL certificate must be associated with the ASE as the "default" TLS/SSL certificate that's used to establish TLS connections to apps. If the ASE's default DNS suffix is *internal.contoso.com*, a connection to `https://some-random-app.internal.contoso.com` requires an TLS/SSL certificate that's valid for **.internal.contoso.com*.

+* **Subject Alternative Name**: This attribute must include both **.your-root-domain-here.com* and**.scm.your-root-domain-here.com*. TLS connections to the SCM/Kudu site associated with each app use an address of the form *your-app-name.scm.your-root-domain-here.com*.

+* Save the base64-encoded string to a separate file.

+After the TLS/SSL certificate is successfully generated and converted to a base64-encoded string, use the example Resource Manager template [Configure the default SSL certificate][quickstartconfiguressl] on GitHub.

+[examplebase64encoding]: https://powershellscripts.blogspot.com/2007/02/base64-encode-file.html

+# Create and use an Internal Load Balancer App Service Environment

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+The Azure App Service Environment is a deployment of Azure App Service into a subnet in an Azure virtual network (VNet). There are two ways to deploy an App Service Environment (ASE):

+- With a VIP on an internal IP address, often called an ILB ASE because the internal endpoint is an internal load balancer (ILB).

+## Overview

+You can deploy an ASE with an internet-accessible endpoint or with an IP address in your VNet. To set the IP address to a VNet address, the ASE must be deployed with an ILB. When you deploy your ASE with an ILB, you must provide the name of your ASE. The name of your ASE is used in the domain suffix for the apps in your ASE. The domain suffix for your ILB ASE is &lt;ASE name&gt;.appserviceenvironment.net. Apps that are made in an ILB ASE are not put in the public DNS.

+Earlier versions of the ILB ASE required you to provide a domain suffix and a default certificate for HTTPS connections. The domain suffix is no longer collected at ILB ASE creation and a default certificate is also no longer collected. When you create an ILB ASE now, the default certificate is provided by Microsoft and is trusted by the browser. You are still able to set custom domain names on apps in your ASE and set certificates on those custom domain names.

+- Host intranet applications securely in the cloud, which you access through a site-to-site or ExpressRoute.

+- Protect apps with a WAF device

+- Host apps in the cloud that aren't listed in public DNS servers.

+- Create internet-isolated back-end apps, which your front-end apps can securely integrate with.

+- Use IP-based TLS/SSL binding.

+- Assign IP addresses to specific apps.

+- Buy and use a certificate with an app through the Azure portal. You can obtain certificates directly from a certificate authority and use them with your apps. You can't obtain them through the Azure portal.

+1. Select or create an App Service plan.

+### Web jobs, Functions and the ILB ASE

+## DNS configuration

+For every app that's created, there are two endpoints. In an ILB ASE, you have *&lt;app name&gt;.&lt;ILB ASE Domain&gt;* and *&lt;app name&gt;.scm.&lt;ILB ASE Domain&gt;*.

+The SCM site name takes you to the Kudu console, called the **Advanced portal**, within the Azure portal. The Kudu console lets you view environment variables, explore the disk, use a console, and much more. For more information, see [Kudu console for Azure App Service][Kudu].

+Internet-based CI systems, such as GitHub and Azure DevOps, will still work with an ILB ASE if the build agent is internet accessible and on the same network as ILB ASE. So in case of Azure DevOps, if the build agent is created on the same VNET as ILB ASE (different subnet is fine), it will be able to pull code from Azure DevOps git and deploy to ILB ASE.

+- To get started with ASEs, see [Introduction to App Service environments][Intro].

+> This article is about App Service Environment v3, which is used with Isolated v2 App Service plans.

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+The App Service Environment (ASE) is a deployment of Azure App Service in a customer's Azure Virtual Network. Many customers configure their Azure virtual networks to be extensions of their on-premises networks with VPNs or Azure ExpressRoute connections. Forced tunneling is when you redirect internet bound traffic to your VPN or a virtual appliance instead. Virtual appliances are often used to inspect and audit outbound network traffic.

+To learn more about routing in a virtual network, read [User-defined routes and IP forwarding][routes].

+## Configure your ASE subnet to ignore BGP routes ##

+After you configure the ASE subnet to ignore all BGP routes, your apps will no longer be able to reach on premises. To enable your apps to access resources on-premises, edit the UDR assigned to your ASE subnet and add routes for your on premises address ranges. The Next hop type should be set to Virtual network gateway.

+1. Create a route table and assign it to your ASE subnet. Find the addresses that match your region here [App Service Environment management addresses][management]. Create routes for those addresses or use the AppServiceManagement service tag with a next hop of internet. These routes are needed because the App Service Environment inbound management traffic must reply from the same address it was sent to.

+Service Endpoints enable you to restrict access to multi-tenant services to a set of Azure virtual networks and subnets. You can read more about Service Endpoints in the [Virtual Network Service Endpoints][serviceendpoints] documentation.

+1. Create a route table and assign it to your ASE subnet. Find the addresses that match your region here [App Service Environment management addresses][management]. Create routes for those addresses with a next hop of internet. These routes are needed because the App Service Environment inbound management traffic must reply from the same address it was sent to.

+4. _To set the egress addresses in an existing App Service Environment:_ Go to resources.azure.com, and go to Subscription/\<subscription id>/resourceGroups/\<ase resource group>/providers/Microsoft.Web/hostingEnvironments/\<ase name>. Then you can see the JSON that describes your App Service Environment. Make sure it says **read/write** at the top. Select **Edit**. Scroll down to the bottom. Change the **userWhitelistedIpRanges** value from **null** to something like the following. Use the addresses you want to set as the egress address range.

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+* Linux web apps

+[ASEAZ]: https://azure.github.io/AppService/2019/12/12/App-Service-Environment-Support-for-Availability-Zones.html

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+With Network Security Groups, you do not need to worry about the individual addresses or maintaining your own configuration. There is an IP service tag named AppServiceManagement that is kept up-to-date with all of the addresses. To use this IP service tag in your NSG, go to the portal, open your Network Security Groups UI, and select Inbound security rules. If you have a pre-existing rule for the inbound management traffic, edit it. If this NSG was not created with your ASE, or if it is all new, then select **Add**. Under the Source drop down, select **Service Tag**. Under the Source service tag, select **AppServiceManagement**. Set the source port ranges to \*, Destination to **Any**, Destination port ranges to **454-455**, Protocol to **TCP**, and Action to **Allow**. If you are making the rule, then you need to set the Priority.

+The management addresses can be placed in a route table with a next hop of internet to ensure that all inbound management traffic is able to go back through the same path. These routes are needed when configuring forced tunneling. When possible, use the AppServiceManagement service tag instead of the individual addresses. To create the route table, you can use the portal, PowerShell or Azure CLI. The commands to create a route table using Azure CLI from a PowerShell prompt are below.

+> The migration feature described in this article is used for in-place (same subnet) automated migration of App Service Environment v1 and v2 to App Service Environment v3. If you haven't requested a 30-day grace period, review the [grace period overview](./auto-migration.md#grace-period), and then request a grace period by going to [Azure portal](https://portal.azure.com) and visiting the Migration blade for each of your App Service Environments.

+>

+> If you're looking for information on the side-by-side migration feature, see [Migrate to App Service Environment v3 by using the side-by-side migration feature](side-by-side-migrate.md). If you're looking for information on manual migration options, see [Manual migration options](migration-alternatives.md). For help deciding which migration option is right for you, see [Migration path decision tree](upgrade-to-asev3.md#migration-path-decision-tree). For more information on App Service Environment v3, see [App Service Environment v3 overview](overview.md).

+App Service can automate migration of your App Service Environment v1 and v2 to an [App Service Environment v3](overview.md). There are different migration options. Review the [migration path decision tree](upgrade-to-asev3.md#migration-path-decision-tree) to decide which option is best for your use case. App Service Environment v3 provides [advantages and feature differences](overview.md#feature-differences) over earlier versions. Make sure to review the [supported features](overview.md#feature-differences) of App Service Environment v3 before migrating to reduce the risk of an unexpected application issue.

+ - ILB App Service Environment name character limit: 36 characters

+ - ELB App Service Environment name character limit: 42 characters

+For this guide, [install the Azure CLI](/cli/azure/install-azure-cli) or use [Azure Cloud Shell](https://shell.azure.com/) and use a Bash shell.

+You can make your new App Service Environment v3 resource zone redundant if your existing environment is in a [region that supports zone redundancy](./overview.md#regions).

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+![Diagram that shows the elements of an external deployment.][1]

+- HTTP/S

+- FTP/S

+- Web deployment

+- Remote debugging

+Ports 7564 and 1221 can show as open on a port scan. They reply with an IP address, and nothing more. You can block them if you want to.

+The inbound management traffic provides command and control of the App Service Environment, in addition to system monitoring. The source addresses for this traffic are listed in [App Service Environment management addresses][ASEManagement]. The network security configuration needs to allow access from the App Service Environment management addresses on ports 454 and 455. If you block access from those addresses, your App Service Environment will become unhealthy and then become suspended. The TCP traffic that comes in on ports 454 and 455 must go back out from the same VIP, or you will have an asymmetric routing problem.

+Within the subnet, there are many ports used for internal component communication, and they can change. This requires all of the ports in the subnet to be accessible from the subnet.

+For outbound access, an App Service Environment depends on multiple external systems. Many of those system dependencies are defined with DNS names, and don't map to a fixed set of IP addresses. Thus, the App Service Environment requires outbound access from the subnet to all external IPs, across a variety of ports.

+| Azure SQL | 1433 |

+The outbound dependencies are listed in [Locking down an App Service Environment](./firewall-integration.md). If the App Service Environment loses access to its dependencies, it stops working. When that happens for a long enough period of time, it's suspended.

+When you use an internal load balancer, the SCM site isn't accessible from outside the virtual network. Some capabilities don't work from the app portal because they require access to the SCM site of an app. You can connect to the SCM site directly, instead of by using the portal.

+If your internal load balancer is the domain name `contoso.appserviceenvironment.net`, and your app name is _testapp_, the app is reached at `testapp.contoso.appserviceenvironment.net`. The SCM site that goes with it is reached at `testapp.scm.contoso.appserviceenvironment.net`.

+> These IP addresses don't change, as long as your App Service Environment is running. If your App Service Environment becomes suspended and is then restored, the addresses used will change. The normal cause for a suspension is if you block inbound management access, or you block access to a dependency.

+[NSGs][NSGs] provide the ability to control network access within a virtual network. When you use the portal, there's an implicit _deny rule_ at the lowest priority to deny everything. What you build are your _allow rules_.

+- TCP from the IP service tag `AppServiceManagement` on ports 454, 455

+- TCP from the load balancer on port 16001

+- From the App Service Environment subnet to the App Service Environment subnet on all ports

+- UDP to all IPs on port 53

+- UDP to all IPs on port 123

+- TCP to all IPs on ports 80, 443

+- TCP to the IP service tag `Sql` on port 1433

+- TCP to all IPs on port 12000

+- To the App Service Environment subnet on all ports

+_Forced tunneling_ is when you set routes in your virtual network so the outbound traffic doesn't go directly to the internet. Instead, the traffic goes somewhere else, like an Azure ExpressRoute gateway or a virtual appliance. If you need to configure your App Service Environment in such a manner, see [Configuring your App Service Environment with forced tunneling][forcedtunnel].

+Service endpoints enable you to restrict access to multi-tenant services to a set of Azure virtual networks and subnets. For more information, see [Virtual Network service endpoints][serviceendpoints].

+When you enable service endpoints on a resource, there are routes created with higher priority than all other routes. If you use service endpoints on any Azure service, with a force-tunneled App Service Environment, the traffic to those services isn't force-tunneled.

+[forcedtunnel]: ./forced-tunnel-support.md

+> The migration feature described in this article is used for side-by-side (different subnet) automated migration of App Service Environment v2 to App Service Environment v3. If you haven't requested a 30-day grace period, review the [grace period overview](./auto-migration.md#grace-period), and then request a grace period by going to [Azure portal](https://portal.azure.com) and visiting the Migration blade for each of your App Service Environments.

+App Service can automate migration of your App Service Environment v1 and v2 to an [App Service Environment v3](overview.md). There are different migration options. Review the [migration path decision tree](upgrade-to-asev3.md#migration-path-decision-tree) to decide which option is best for your use case. App Service Environment v3 provides [advantages and feature differences](overview.md#feature-differences) over earlier versions. Make sure to review the [supported features](overview.md#feature-differences) of App Service Environment v3 before migrating to reduce the risk of an unexpected application issue.

+>

+ - ILB App Service Environment name character limit: 36 characters

+ - ELB App Service Environment name character limit: 42 characters

+ - For ILB App Service Environments, your App Service Environment v3 front ends aren't used until you update your private DNS zones with the new inbound IP address.

+ - For ELB App Service Environments, the migration process doesn't redirect traffic to the App Service Environment v3 front ends until you complete the final step of the migration.

+For this guide, [install the Azure CLI](/cli/azure/install-azure-cli) or use [Azure Cloud Shell](https://shell.azure.com/) and use a Bash shell.

+>

+>

+You can get the new inbound IP address for your new App Service Environment v3 by running the following command that corresponds to your App Service Environment load balancer type. It's your responsibility to make any necessary updates.

+> If your migration includes a custom domain suffix, the default host name behavior for App Service Environment v3 is different than for App Service Environment v2. For App Service Environment v3, the default host name always uses the default domain suffix and is in the form *APP-NAME.ASE-NAME.appserviceenvironment.net*. Review all your dependent resources, such as App Gateway, that use the host names of your apps to ensure they're updated to account for this behavior. For more information on App Service Environment feature differences between the different versions, see [App Service Environment version comparison](version-comparison.md).

+>

+This step is your opportunity to test and validate your new App Service Environment v3.

+> If you're currently using App Service Environment v1 or v2, you must migrate your workloads to [App Service Environment v3](overview.md). [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+>

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+|**1**|**Receive a 30-day grace period**| If you haven't requested a 30-day grace period, review the [grace period overview](./auto-migration.md#grace-period), and then request a grace period by going to [Azure portal](https://portal.azure.com) and visiting the Migration blade for each of your App Service Environments. You must receive a grace period to prevent unexpected auto-migration or deletion.|

+|**2**|**Pre-flight check**|Determine if your environment meets the prerequisites to automate your upgrade using one of the automated migration features. Decide whether an in-place or side-by-side migration is right for your use case.<br>- [Migration path decision tree](#migration-path-decision-tree)<br>- [Automated upgrade using the in-place migration feature](migrate.md)<br>- [Automated upgrade using the side-by-side migration feature](side-by-side-migrate.md)<br><br>If not, you can upgrade manually.<br>- [Manual migration](migration-alternatives.md)|

+|**3**|**Migrate**|Based on results of your review, either upgrade using one of the automated migration features or follow the manual steps.|

+|**4**|**Testing and troubleshooting**|Upgrading using one of the automated migration features requires a 3-6 hour service window. If you use the side-by-side migration feature, you have the opportunity to [test and validate your App Service Environment v3](./side-by-side-migrate.md#redirect-customer-traffic-validate-your-app-service-environment-v3-and-complete-migration) before completing the upgrade. Support teams are monitoring upgrades to ensure success. If you have a support plan and you need technical help, create a [support request](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest).|

+|**5**|**Optimize your App Service plans**|Once your upgrade is complete, you can optimize the App Service plans for additional benefits.<br><br>Review the autoselected Isolated v2 SKU sizes and scale up or scale down your App Service plans as needed.<br>- [Scale down your App Service plans](../manage-scale-up.md)<br>- [App Service Environment post-migration scaling guidance](migrate.md#pricing)<br><br>Explore reserved instance pricing, savings plans, and check out the pricing estimates if needed.<br>- [App Service pricing page](https://azure.microsoft.com/pricing/details/app-service/windows/)<br>- [How reservation discounts apply to Isolated v2 instances](../../cost-management-billing/reservations/reservation-discount-app-service.md#how-reservation-discounts-apply-to-isolated-v2-instances)<br>- [Azure pricing calculator](https://azure.microsoft.com/pricing/calculator)|

+|**6**|**Learn more**|Overview of the upgrade process with App Service Environment Product Managers:<br>- [Azure App Service Community Standup: App Service Environment Migration](https://www.youtube.com/live/rjeVKFZHeb4)<br><br>On-demand Learn Live sessions with Azure FastTrack Architects:<br>- [Use the in-place automated migration feature](https://www.youtube.com/watch?v=lI9TK_v-dkg)<br>- [Use the side-by-side automated migration feature](https://www.youtube.com/watch?v=VccH5C0rdto)<br><br>Need more help? [Submit a request](https://cxp.azure.com/nominationportal/nominationform/fasttrack) to contact FastTrack.<br><br>[Frequently asked questions](migrate.md#frequently-asked-questions)<br><br>[Community support](https://aka.ms/asev1v2retirement)|

+There are two automated migration features available to help you upgrade to App Service Environment v3.

+When migrating to App Service Environment v3, we map App Service plan tiers as follows:

+You must complete migration to App Service Environment v3 as soon as possible or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration is not feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+## We want your feedback

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+ g. Select **Linux** or **Windows**.

+ h. Select your ASE in the **Region** drop-down list.

+### DNS configuration

+The DNS settings for your ASE default domain suffix do not restrict your apps to only being accessible by those names. You can set a custom domain name without any validation on your apps in an ILB ASE. If you then want to create a zone named *contoso.net*, you could do so and point it to the ILB IP address. The custom domain name works for app requests but doesn't for the scm site. The scm site is only available at *&lt;appname&gt;.scm.&lt;asename&gt;.appserviceenvironment.net*.

+If you integrate with Log Analytics, you can see the logs by selecting **Logs** from the ASE portal and creating a query against **AppServiceEnvironmentPlatformLogs**. Logs are only emitted when your ASE has an event that will trigger it. If your ASE doesn't have such an event, there won't be any logs. To quickly see an example of logs in your Log Analytics workspace, perform a scale operation with one of the App Service plans in your ASE. You can then run a query against **AppServiceEnvironmentPlatformLogs** to see those logs.

+- Open the Alerts page in your ASE portal

+- Select **New alert rule**

+- Select your Resource to be your Log Analytics workspace

+- Set your condition with a custom log search to use a query like, "AppServiceEnvironmentPlatformLogs | where ResultDescription contains "has begun scaling" or whatever you want. Set the threshold as appropriate.

+- Add or create an action group as desired. The action group is where you define the response to the alert such as sending an email or an SMS message

+- Name your alert and save it.

+> This article includes information about about App Service Environment v1 and v2. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+App Service Environment v3 runs on the latest [Virtual Machine Scale Sets](/azure/virtual-machine-scale-sets/overview) infrastructure while App Service Environment v1 and v2 run on [Cloud Services (classic)](../../cloud-services/cloud-services-choose-me.md). Because of this, App Service Environment v3 has the best performing and fastest scaling times across all versions.

+ - TCP from the IP service tag AppServiceManagement on ports 454, 455

+ - TCP from the load balancer on port 16001

+ - From the App Service Environment subnet to the App Service Environment subnet on all ports

+ - UDP to all IPs on port 53

+ - UDP to all IPs on port 123

+ - TCP to all IPs on port 80, 443

+ - TCP to the IPs service tag Sql on ports 1433

+ - TCP to all IPs on port 12000

+ - To the App Service Environment subnet on all ports

+The custom domain suffix is for the App Service Environment. It's available on App Service Environment v1 and v3, but was removed from App Service Environment v2.

+> This article is about App Service Environment v2, which is used with Isolated App Service plans. [App Service Environment v1 and v2 are retired as of 31 August 2024](https://aka.ms/postEOL/ASE). There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the [Introduction to the App Service Environment](overview.md). If you're currently using App Service Environment v1, please follow the steps in [this article](upgrade-to-asev3.md) to migrate to the new version.

+> As of 31 August 2024, [Service Level Agreement (SLA) and Service Credits](https://aka.ms/postEOL/ASE/SLA) no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

+> You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the [in-place migration feature](migrate.md), but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

+>

+> If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the [grace period overview](./auto-migration.md#grace-period), and then go to [Azure portal](https://portal.azure.com) and visit the Migration blade for each of your App Service Environments.

+App Service Environment v2 (ASE) can be deployed into Availability Zones (AZ). Customers can deploy an internal load balancer (ILB) ASEs into a specific AZ within an Azure region. If you pin your ILB ASE to a specific AZ, the resources used by an ILB ASE will either be pinned to the specified AZ, or deployed in a zone redundant manner.

+Unless the steps described in this article are followed, ILB ASEs aren't automatically deployed in a zonal manner. You can't pin an External ASE with a public IP address to a specific availability zone.

+- France Central

+Applications deployed on a zonal ILB ASE will continue to run and serve traffic on that ASE even if other zones in the same region suffer an outage. It's possible that nonruntime behaviors, including; application service plan scaling, application creation, application configuration, and application publishing might still be impacted from an outage in other availability zones. The zone-pinned deployment of a zonal ILB ASE only ensures continued uptime for already deployed applications.

+To make your apps zone redundant, you need to deploy two zonal ILB ASEs. The two zonal ILB ASEs must be in separate availability zones. You then need to deploy your apps into each of the ILB ASEs. After your apps are created, you need to configure a load balancing solution. The recommended solution is to deploy a [zone redundant Application Gateway](../../application-gateway/application-gateway-autoscaling-zone-redundant.md) upstream of the zonal ILB ASEs.

+ILB ASEs deployed in an availability zone will only store customer data within the region where the zonal ILB ASE has been deployed. Both website file content and customer supplied settings and secrets stored in App Service remain within the region where the zonal ILB ASE is deployed.

+Customers can validate that an App Service Environment is properly configured to store data in a single region by following these steps:

+1. Using [Resource Explorer](https://resources.azure.com), navigate to the Azure Resource Manager resource for the App Service Environment. ASEs are listed under *providers/Microsoft.Web/hostingEnvironments*.

+2. If a *zones* property exists in the view of the Azure Resource Manager JSON syntax, and it contains a single valued JSON array with a value of "1," "2," or "3," then the ASE is zonally deployed and customer data remains in the same region.

+2. If a *zones* property doesn't exist, or the property doesn't have valid zone value as specified earlier, then the ASE isn't zonally deployed, and customer data isn't exclusively stored in the same region.

+* [Create an App Service app](./index.yml), or use an app that you created for another tutorial. The app should be in an Azure Public region. At this time, Azure national clouds are not supported.

+* To use an App Service domain, the app's [App Service plan](overview-hosting-plans.md) must be a paid tier, not a Free (F1) tier. See [Scale up an app](manage-scale-up.md#scale-up-your-pricing-tier) to update the tier.

+> For some subscriptions types, before you can create an App Service domain, the subscription needs to have sufficient history on Azure.

+> App Service domains aren't supported on free trial or credit-based subscriptions.

+ > You can also create an App Service domain independently of an app by going to the App Service Domains view and selecting **Create**, or by navigating to [the create page directly](https://portal.azure.com/#create/Microsoft.Domain). But since the domain is independent from your app, you won't be able to assign hostnames like `www` to your app, which you can do if you create the domain from your app's **Custom domains** page.

+1. In the **Basics** tab, configure the following settings:

+ | **Domain** | The domain you want. For example, **contoso.com**. If the domain you want isn't available, you can select from a list of suggested available domains or try a different domain. |

+ | **root (@)** | The root or apex subdomain. If you buy the `contoso.com` domain, that's the root domain. Select **No** if you don't want to map the hostname to your app. |

+ | **'www' subdomain** | If you buy the `contoso.com` domain, the `www` subdomain would be `www.contoso.com`. Select **No** if you don't want to map the hostname to your app. |

+ > If you didn't launch the App Service domain wizard from an app's **Custom domains** page, you won't see this tab. You can still add the hostnames later by following the steps at [Map a hostname manually](#map-a-hostname-manually).

+ | **Auto renewal** | Your App Service domain is registered to you at one-year increments. Enable auto renewal so that your domain registration doesn't expire and you retain ownership of the domain. Your Azure subscription is automatically charged the yearly domain registration fee at the time of renewal. If you leave this option disabled, you must [renew the domain manually](#renew-the-domain). |

+ | **Privacy protection** | Enabled by default. Privacy protection hides your domain registration contact information from the WHOIS database and is already included in the yearly domain registration fee. To opt out, select **Disable**. Privacy protection isn't supported in following top-level domains (TLDs): co.uk, in, org.uk, co.in, and nl. |

+1. Select **Next: Tags** and set the tags you want for your App Service domain. Tagging isn't required. It's a [feature in Azure that helps you manage your resources](../azure-resource-manager/management/tag-resources.md).

+ > App Service domains use GoDaddy for domain registration and Azure DNS to host the domains. In addition to the yearly domain registration fee, usage charges for Azure DNS apply. For information, see [Azure DNS Pricing](https://azure.microsoft.com/pricing/details/dns/).

+1. When the domain registration is complete, you see a **Go to resource** button. Select it to see the management page.

+> For some subscriptions types, before you can create an App Service domain, the subscription needs to have sufficient history on Azure.

+> App Service domains aren't supported on free trial or credit-based subscriptions.

+1. For **TLS/SSL certificate**, select **App Service Managed Certificate** if your app is in the Basic tier or higher. If you want to remain in the Shared tier, or if you want to use your own certificate, select **Add certificate later**.

+ > To map to an App Service domain in a different subscription, see [Map an externally purchased domain](app-service-web-tutorial-custom-domain.md). In this case, Azure DNS is the external domain provider, and you need to add the required DNS records manually.

+ | **Root domain** | The root or apex subdomain. If you buy the `contoso.com` domain, that's the root domain. |

+ | **Subdomain** | In the **Subdomain** box, specify a subdomain like `www` or `shoppingcart`. |

+1. You should see the custom domain added to the list. You might also see a red X and the text **No binding**.

+ If you selected **App Service Managed Certificate** earlier, wait a few minutes for App Service to create the managed certificate for your custom domain. When the process is complete, the red X becomes a green check mark with the word **Secured**. If you selected **Add certificate later**, the red X will remain until you [add a private certificate for the domain](configure-ssl-certificate.md) and [configure the binding](configure-ssl-bindings.md).

+ > Unless you configure a certificate binding for your custom domain, any HTTPS request from a browser to the domain will receive an error or warning, depending on the browser.

+1. Test the mapping by navigating to it in a browser. (For example, go to `shoppingcart.contoso.com`.)

+The App Service domain you bought is valid for one year from the time of purchase. You can configure your domain to renew automatically, or you can manually renew your domain name up to 90 days ahead of domain expiration. Upon successful automatic or manual renewal, you'll be billed for the cost of the domain, and your domain expiration will be extended for another year.

+> For .nl domains, you can only manually renew the domain starting 90 days ahead of domain expiration and up to the 20th of the month before the expiration date. You won't be able to renew the domain after this period even if the domain hasn't yet expired.

+If you want to configure automatic renewal, or if you want to manually renew your domain, follow these steps:

+1. From the left navigation of the domain, select **Domain renewal**. To start renewing your domain automatically, select **On**. Otherwise select **Off**. The setting takes effect immediately. If automatic renewal is enabled, on the day after your domain expiration date, Azure attempts to bill you for the domain name renewal.

+In Azure, DNS records for an App Service domain are managed using [Azure DNS](https://azure.microsoft.com/services/dns/). You can add, remove, and update DNS records just as you would for an externally purchased domain. To manage custom DNS records:

+After you purchase the App Service domain, you can update the domain contact information if you need to. It's important to keep this contact information up to date so that you can receive notifications about your domain and receive verification emails if you decide to transfer out your domain. To update your contact information:

+1. From the left navigation of the domain, select **Advanced domain management (preview)**. To update your contact information, select **Edit contact**.

+ :::image type="content" source="./media/custom-dns-web-site-buydomains-web-app/dncmntask-cname-buydomain-update-contact.png" alt-text="Screenshot showing where to update contact information for a purchased domain." border="true" lightbox="./media/custom-dns-web-site-buydomains-web-app/dncmntask-cname-buydomain-update-contact.png":::

+1. In the pane that appears, update the necessary fields and then select **Submit**.

+ > If you have privacy protection disabled and update name or organization information, an email verification is sent to the email address on file for confirmation. Additionally, if you update your email address, a verification email is sent first to the previous email on file for confirmation. Once that's completed, another email is sent to the new email on file for confirmation. The contact information won't update until after you have confirmed via email.

+Privacy protection hides your domain registration contact information from the WHOIS database. If it's enabled during domain creation, privacy protection is already included in the yearly domain registration fee for no additional cost. However, there are some scenarios, such as transferring the domain out, where you need to disable privacy protection, you can do that by:

+1. From the left navigation of the domain, select **Advanced domain management (preview)**. To disable privacy protection, select **Disable** in the **Domain Privacy** section.

+ :::image type="content" source="./media/custom-dns-web-site-buydomains-web-app/dncmntask-cname-buydomains-disable-privacy.png" alt-text="Screenshot showing where to disable privacy for a purchased domain." lightbox="./media/custom-dns-web-site-buydomains-web-app/dncmntask-cname-buydomains-disable-privacy.png" border="true":::

+## Cancel the purchase

+After you purchase the App Service domain, you have five days to cancel your purchase and get a full refund. After five days, you can delete the App Service domain but can't receive a refund.

+Free subscriptions, which don't require a confirmed credit card, don't have the permissions to buy App Service domains in Azure.

+The number of App Service domains a subscription can have depends on the subscription type. Subscriptions that have a monthly credit allotment, like the Visual Studio Enterprise subscription, have a limit of one App Service domain. To increase your limit, convert to a pay-per-use subscription.

+## Next step

+Learn how to bind a custom TLS/SSL certificate to help secure App Service.

+> [Secure a custom DNS name with a TLS/SSL binding in Azure App Service](configure-ssl-bindings.md)

+ Title: Overview of Azure App Service

+description: Learn how Azure App Service helps you develop and host web applications.

+*Azure App Service* is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and [Linux](#app-service-on-linux)-based environments.

+App Service adds the power of Microsoft Azure to your application, including improved security, load balancing, autoscaling, and automated management. Additionally, you can take advantage of its DevOps capabilities, such as continuous deployment from Azure DevOps, GitHub, Docker Hub, and other sources, package management, staging environments, custom domains, and TLS/SSL certificates.

+* **Multiple languages and frameworks** - App Service has first-class support for ASP.NET, ASP.NET Core, Java, Node.js, PHP, and Python. You can also run [PowerShell and other scripts or executables](webjobs-create.md) as background services.

+* **Global scale with high availability** - Scale [up](manage-scale-up.md) or [out](/azure/azure-monitor/autoscale/autoscale-get-started) manually or automatically. Host your apps anywhere in the global Microsoft datacenter infrastructure, and the App Service [SLA](https://azure.microsoft.com/support/legal/sla/app-service/) promises high availability.

+* **Connections to SaaS platforms and on-premises data** - Choose from [many hundreds of connectors](/connectors/connector-reference/connector-reference-logicapps-connectors) for enterprise systems (such as SAP), SaaS services (such as Salesforce), and internet services (such as Facebook). Access on-premises data using [Hybrid Connections](app-service-hybrid-connections.md) and [Azure Virtual Network](./overview-vnet-integration.md).

+* **Security and compliance** - App Service is [ISO, SOC, and PCI compliant](https://www.microsoft.com/trust-center). Create [IP address restrictions](app-service-ip-restrictions.md) and [managed service identities](overview-managed-identity.md). [Protect against subdomain takeovers](reference-dangling-subdomain-prevention.md).

+* **Authentication** - [Authenticate users](overview-authentication-authorization.md) using the built-in authentication component. Authenticate users with [Microsoft Entra ID](configure-authentication-provider-aad.md), [Google](configure-authentication-provider-google.md), [Facebook](configure-authentication-provider-facebook.md), [X](configure-authentication-provider-twitter.md), or [Microsoft accounts](configure-authentication-provider-microsoft.md).

+* **API and mobile features** - App Service provides turn-key CORS support for RESTful API scenarios and simplifies mobile app scenarios by enabling authentication, offline data sync, push notifications, and more.

+* **Serverless code** - Run a code snippet or script on-demand without having to explicitly provision or manage infrastructure, and pay only for the compute time your code actually uses. (See [Azure Functions](../azure-functions/index.yml).)

+Besides App Service, Azure offers other services that can be used for hosting websites and web applications. For most scenarios, App Service is the best choice. For a microservice architecture, consider [Azure Spring Apps](../spring-apps/index.yml) or [Service Fabric](/azure/service-fabric/). If you need more control over the VMs on which your code runs, consider [Azure Virtual Machines](/azure/virtual-machines/). For more information about how to choose among these Azure services, see [Azure App Service, Virtual Machines, Service Fabric, and Cloud Services comparison](/azure/architecture/guide/technology-choices/compute-decision-tree).

+App Service can also host web apps natively on Linux for supported application stacks. It can also run custom Linux containers (also known as *Web App for Containers*).

+App Service on Linux supports a number of language-specific built-in images. Just deploy your code. Supported languages include: Node.js, Java (Tomcat, JBoss, or with an embedded web server), PHP, Python, and .NET Core. Run [`az webapp list-runtimes --os linux`](/cli/azure/webapp#az-webapp-list-runtimes) to view the latest languages and supported versions. If the runtime your application requires isn't supported in the built-in images, you can deploy it with a custom container.

+Outdated runtimes are periodically removed from the Web Apps Create and Configuration blades in the portal. These runtimes are hidden from the portal when they're deprecated by the maintaining organization or found to have significant vulnerabilities. These options are hidden to guide customers to the latest runtimes, where they'll be the most successful.

+When an outdated runtime is hidden from the portal, any of your existing sites using that version will continue to run. If a runtime is fully removed from the App Service platform, your Azure subscription owner(s) will receive an email notice before the removal.

+If you need to create another web app with an outdated runtime version that's no longer shown on the portal, see the language configuration guides for instructions on how to get the runtime version of your site. You can use the Azure CLI to create another site with the same runtime. Alternatively, you can use the **Export Template** button on the web app blade in the portal to export an ARM template of the site. You can reuse this template to deploy a new site with the same runtime and configuration.

+* App Service on Linux isn't supported on the [Shared](https://azure.microsoft.com/pricing/details/app-service/plans/) pricing tier.

+* When deployed to built-in images, your code and content are allocated a storage volume for web content, backed by Azure Storage. The disk latency of this volume is higher and more variable than the latency of the container filesystem. Apps that require heavy read-only access to content files might benefit from the custom container option, which places files in the container filesystem instead of on the content volume.

+## App Service Environment

+App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for running App Service apps with improved security at high scale. Unlike the App Service offering, where supporting infrastructure is shared, with App Service Environment, compute is dedicated to a single customer. For more information on the differences between App Service Environment and App Service, see the [comparison](./environment/ase-multi-tenant-comparison.md).

+## Next step

+- If you added an "A record", make sure that a TXT record is also added. For more information, see [Create the DNS records](./app-service-web-tutorial-custom-domain.md#create-the-dns-records).

+To run Office 365 subscription services, you need an Office 365 service account with permissions to do what you want. You can use one permission management administrator account, one account per service, or have one function or script to execute. In any case, the service account requires a complex and secure password. See [Set up Office 365 for business](/microsoft-365/admin/setup/setup).

+* Increase the refresh interval, especially if your configuration values do not change frequently. Specify a new refresh interval using the [`SetCacheExpiration` method](/dotnet/api/microsoft.extensions.configuration.azureappconfiguration.azureappconfigurationrefreshoptions.setcacheexpiration).

+## Version 1.46 - September 2024

+- Fixed a bug causing the Guest Config agent to hang in extension creating state when the download of an extension package failed.

+- Fixed a bug where onboarding treated conflicting errors as success.

+### New features and enhancements

+- Improved error messaging for scenarios with extension installation and enablement blockage in the presence of a sideloaded extension.

+- Increased checks for recovery of sequence number if the previous request failed.

+- Removed casing requirements when reading the proxy from the configuration file.

+- Added supported for Azure Linux 3 (Mariner).

+- Added initial Linux ARM64 architecture support.

+- Added Gateway URL to the output of the show command.

+## Version 1.45 - August 2024

+Download for [Windows](https://download.microsoft.com/download/0/6/1/061e3c68-5603-4c0e-bb78-2e3fd10fef30/AzureConnectedMachineAgent.msi) or [Linux](manage-agent.md#installing-a-specific-version-of-the-agent)

+### Fixed

+ Title: 'Quickstart: Use Azure Cache for Redis with .NET Core'

+description: Modify a sample .NET Core app and connect the app to Azure Cache for Redis.

+#Customer intent: As a .NET Core developer who is new to Azure Cache for Redis, I want to create a new .NET Core app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a .NET Core app

+In this quickstart, you incorporate Azure Cache for Redis into a .NET Core app for access to a secure, dedicated cache that is accessible from any application in Azure. You specifically use the [StackExchange.Redis](https://github.com/StackExchange/StackExchange.Redis) client with C# code in a .NET Core console app.

+## Skip to the code

+This article describes how to modify the code for a sample app to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the sample code, see the [.NET Core quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/dotnet-core) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+Make a note of the values for **HOST NAME** and the **Primary** access key. You use these values later to construct the `CacheConnection` secret.

+In your Command Prompt window, execute the following command to store a new secret named `CacheConnection`. Replace the placeholders (including angle brackets) with your cache name (`<cache name>`) and primary access key (`<primary-access-key>`):

+## Connect to the cache by using RedisConnection

+The connection to your cache is managed by the `RedisConnection` class. First, make the connection in this statement in *Program.cs*:

+In *RedisConnection.cs*, the StackExchange.Redis namespace is added to the code. The namespace is required for the `RedisConnection` class.

+The `RedisConnection` class code ensures that there's always a healthy connection to the cache. The connection is managed by the `ConnectionMultiplexer` instance from StackExchange.Redis. The `RedisConnection` class re-creates the connection when a connection is lost and can't reconnect automatically.

+For more information, see [StackExchange.Redis](https://stackexchange.github.io/StackExchange.Redis/) and the code in the [StackExchange.Redis GitHub repo](https://github.com/StackExchange/StackExchange.Redis).

+## Execute cache commands

+In *Program.cs*, you can see the following code for the `RunRedisCommandsAsync` method in the `Program` class for the console application:

+You can store and retrieve cache items by using the `StringSetAsync` and `StringGetAsync` methods.

+In the example, you can see the `Message` key is set to a value. The app updated that cached value. The app also executed the `PING` and command.

+The Redis server stores most data in string format. The strings can contain many types of data, including serialized binary data. You can use serialized binary data when you store .NET objects in the cache.

+Azure Cache for Redis can cache both .NET objects and primitive data types, but before a .NET object can be cached, it must be serialized.

+The .NET object serialization is the responsibility of the application developer. The object serialization gives the developer flexibility in their choice of the serializer.

+The following `Employee` class was defined in *Program.cs* so that the sample could also show how to get and set a serialized object:

+If you opened any files, save the files. Then, build the app by using the following command:

+To test serialization of .NET objects, run this command:

+<!-- Clean up include -->

+## Related content

+- [Connection resilience best practices for your cache](cache-best-practices-connection.md)

+- [Development best practices for your cache](cache-best-practices-development.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with .NET'

+description: Modify a sample .NET app and connect the app to Azure Cache for Redis.

+#Customer intent: As a .NET developer who is new to Azure Cache for Redis, I want to create a new .NET app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a .NET app

+In this quickstart, you incorporate Azure Cache for Redis into a .NET app for access to a secure, dedicated cache that is accessible from any application in Azure. You specifically use the [StackExchange.Redis](https://github.com/StackExchange/StackExchange.Redis) client with C# code in a .NET console app.

+This article describes how to modify the code for a sample app to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the code, see the [.NET quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/dotnet) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+- [.NET Framework 4 or later](https://dotnet.microsoft.com/download/dotnet-framework) as required by the StackExchange.Redis client

+1. Create a file on your computer named *CacheSecrets.config*. Place it in the *C:\AppSecrets\* folder.

+ - Replace `<host-name>` with your cache host name.

+ - Replace `<access-key>` with the primary key for your cache.

+1. In Visual Studio, select **Tools** > **NuGet Package Manager** > **Package Manager Console**. Run the following command in the Package Manager Console window:

+

+1. When the installation is finished, the *StackExchange.Redis* cache client is available to use with your project.

+In Visual Studio, open your *App.config* file to verify it contains an `appSettings` `file` attribute that references the *CacheSecrets.config* file:

+Never store credentials in your source code. To keep this sample simple, we use an external secrets config file. A better approach would be to use [Azure Key Vault with certificates](/rest/api/keyvault/certificate-scenarios).

+## Connect to the cache by using RedisConnection

+The connection to your cache is managed by the `RedisConnection` class. First, make the connection in this statement in *Program.cs*:

+The value of the *CacheConnection* app setting is used to reference the cache connection string from the Azure portal as the password parameter.

+In *RedisConnection.cs*, the StackExchange.Redis namespace appears as a `using` statement that the `RedisConnection` class requires:

+The `RedisConnection` class code ensures that there's always a healthy connection to the cache. The connection is managed by the `ConnectionMultiplexer` instance from StackExchange.Redis. The `RedisConnection` class re-creates the connection when a connection is lost and can't reconnect automatically.

+For more information, see [StackExchange.Redis](https://stackexchange.github.io/StackExchange.Redis/) and the code in the [StackExchange.Redis GitHub repo](https://github.com/StackExchange/StackExchange.Redis).

+## Execute cache commands

+In *Program.cs*, you can see the following code for the `RunRedisCommandsAsync` method in the `Program` class for the console application:

+Azure Cache for Redis can cache both .NET objects and primitive data types, but before a .NET object can be cached, it must be serialized.

+This .NET object serialization is the responsibility of the application developer. You have some flexibility in your choice of the serializer.

+A simple way to serialize objects is to use the `JsonConvert` serialization methods in *System.text.Json*.

+Add the System.text.Json namespace in Visual Studio:

+1. Then, run the following command in the Package Manager Console window:

+<!-- :::image type="content" source="media/cache-dotnet-how-to-use-azure-redis-cache/cache-console-app-partial.png" alt-text="Screenshot that shows a partial console app."::: -->

+The following `Employee` class was defined in *Program.cs* so that the sample can show how to get and set a serialized object:

+To build and run the console app to test serialization of .NET objects, select Ctrl+F5.

+<!-- Clean up include -->

+## Related content

+- [Connection resilience best practices for your cache](cache-best-practices-connection.md)

+- [Development best practices for your cache](cache-best-practices-development.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with Go'

+description: Create a Go app and connect the app to Azure Cache for Redis.

+#Customer intent: As a Go developer who is new to Azure Cache for Redis, I want to create a new Go app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a Go app

+In this quickstart, you learn how to build a REST API in Go that stores and retrieves user information backed by a [HASH](https://redis.io/topics/data-types-intro#redis-hashes) data structure in [Azure Cache for Redis](./cache-overview.md).

+## Skip to the code

+This article describes how to create an app by using the Azure portal and then modify the code to end up with a working sample app.

+If you want to go straight to the code, see the [Go quickstart sample](https://github.com/Azure-Samples/azure-redis-cache-go-quickstart/) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+- [Go](https://go.dev/doc/install) (preferably version 1.13 or later)

+- An HTTP client like [curl](https://curl.se/)

+## Create a cache

+## Review the code (optional)

+If you're interested in learning how the code works, you can review the following code snippets. Feel free to skip ahead to [Run the application](#run-the-application).

+The open-source [go-redis](https://github.com/go-redis/redis) library is used to interact with Azure Cache for Redis.

+The `main` function starts by reading the host name and password (access key) for the Azure Cache for Redis instance.

+Then, you establish connection with Azure Cache for Redis. We use [tls.Config](https://go.dev/pkg/crypto/tls/#Config). Azure Cache for Redis supports only secure connections, and [TLS 1.2 as the minimum required version](cache-remove-tls-10-11.md).

+If the connection is successful, [HTTP handlers](https://go.dev/pkg/net/http/#HandleFunc) are configured to handle `POST` and `GET` operations, and the HTTP server is started.

+>The [gorilla mux library](https://github.com/gorilla/mux) is used for routing (although it's not required, and using the standard library for this sample application is an option).

+The `userHandler` struct encapsulates [redis.Client](https://pkg.go.dev/github.com/go-redis/redis/v8#Client). The `createUser` and `getUser` methods use redis.Client. For brevity, the code for these methods isn't included in this article.

+- `createUser`: Accepts a JSON payload (that has user information) and saves it as a `HASH` in Azure Cache for Redis.

+- `getUser`: Fetches user info from `HASH` or returns an HTTP `404` response if it's not found.

+Start by cloning the application on GitHub:

+1. In the Command Prompt window for your computer's root directory, create a folder named *git-samples*:

+1. Open a git terminal window, such as by using Git Bash. Use the `cd` command to go to the new folder to clone the sample app.

+1. In the [Azure portal](https://portal.azure.com/), get the host name and access key for the instance of Azure Cache for Redis.

+1. Set the host name and access key to the following environment variables:

+ set REDIS_HOST=<Host name>:<port> (for example, <name of cache>.redis.cache.windows.net:6380)

+1. In the terminal, go to the folder you created for the samples:

+ For example:

+1. In the terminal, start the application by using this command:

+The HTTP server starts on port `8080`.

+1. Create a few user entries.

+ The following example uses curl:

+1. Fetch an existing user by using the value for `id`:

+ The output is a JSON response that's similar to this example:

+1. If you try to fetch a user who doesn't exist, you get an HTTP `404` error message.

+ For example:

+<!-- Clean up include -->

+## Related content

+- [Create a basic ASP.NET web app that uses Azure Cache for Redis](./cache-web-app-howto.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with Java'

+description: Create a Java app and connect the app to Azure Cache for Redis.

+#Customer intent: As a Java developer who is new to Azure Cache for Redis, I want to create a new Java app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a Java app

+In this quickstart, you incorporate Azure Cache for Redis into a Java app by using the [Jedis](https://github.com/xetorthio/jedis) Redis client. Your app connects to a secure, dedicated cache that is accessible from any application in Azure.

+## Skip to the code

+This quickstart uses the Maven archetype feature to generate scaffolding for a Java app. The quickstart describes how to configure the code to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the code, see the [Java quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/java) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+## Create a cache

+Depending on your operating system, add environment variables for host name and primary access key that you noted earlier. In a Command Prompt window or terminal window, set the following values:

+- `<your-host-name>`: The DNS host name, obtained from the **Properties** section of your Azure Cache for Redis resource in the Azure portal.

+- `<your-primary-access-key>`: The primary access key, obtained from the **Access keys** section of your Azure Cache for Redis resource in the Azure portal.

+## Review the Java sample

+1. Go to the new *redistest* project directory.

+1. Open the *pom.xml* file. In the file, verify that a dependency for [Jedis](https://github.com/xetorthio/jedis) appears:

+1. Open *App.java* and verify that the following code appears:

+ // Perform cache operations by using the cache connection object.

+ This code shows you how to connect to an Azure Cache for Redis instance by using the cache host name and key environment variables. The code also stores and retrieves a string value in the cache. The `PING` and `CLIENT LIST` commands are also executed.

+1. Close *App.java*.

+1. Set the environment variables as noted earlier:

+1. To build and run the app, run the following Maven command:

+In the following output, you can see that the `Message` key previously had a cached value. The value was updated to a new value by using `jedis.set`. The app also executed the `PING` and `CLIENT LIST` commands.

+<!-- Clean up include -->

+## Related content

+- [Connection resilience best practices for your cache](cache-best-practices-connection.md)

+- [Development best practices for your cache](cache-best-practices-development.md)

+- [Use Azure Cache for Redis with Jakarta EE](/azure/developer/java/ee/how-to-deploy-java-liberty-jcache)

+- [Use Azure Cache for Redis with Spring](/azure/developer/java/spring-framework/configure-spring-boot-initializer-java-app-with-redis-cache)

+ Title: "Quickstart: Use Azure Cache for Redis with Java and Redisson Redis client"

+description: Create a Java app and connect the app to Azure Cache for Redis by using Redisson as the Redis client.

+#Customer intent: As a Java developer who is new to Azure Cache for Redis, I want to create a new Java app that uses Azure Cache for Redis and Redisson as the Redis client.

+# Quickstart: Use Azure Cache for Redis with a Java app and a Redisson Redis client

+In this quickstart, you incorporate Azure Cache for Redis into a Java app by using the [Redisson](https://redisson.org/) Redis client and the Java Community Practice (JCP) standard JCache API. These services give you access to a secure, dedicated cache that is accessible from any application in Azure.

+This article describes two options to select the Azure identity to use for the Redis connection:

+- Authentication by using a Redis key

+- Authentication by using Microsoft Entra ID

+## Skip to the code

+This quickstart uses the Maven archetype feature to generate scaffolding for a Java app. The quickstart describes how to configure the code to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the code, see the [Java quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/java-redisson-jcache) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+- [Microsoft Entra ID for cache authentication](cache-azure-active-directory-for-authentication.md)

+## Create a cache

+The steps in this section show you two options for selecting an Azure identity to use for the Redis connection. The sample code looks at the value of the `AUTH_TYPE` environment variable, and then takes action based on the value.

+### Authenticate by using a Redis key

+Depending on your operating system, add environment variables to hold your cache's host name and primary access key. In a Command Prompt window or terminal window, set the following values:

+In the preceding code, replace the placeholders with the following values:

+- `<your-host-name>`: The DNS host name, obtained from the **Properties** section of your Azure Cache for Redis resource in the Azure portal.

+- `<your-primary-access-key>`: The primary access key, obtained from the **Access keys** section of your Azure Cache for Redis resource in the Azure portal.

+### Authenticate by using Microsoft Entra ID

+Depending on your operating system, add environment variables to hold your cache's host name and user name. In a Command Prompt window or terminal window, set up the following values:

+In the preceding code, replace the placeholders with the following values:

+- `<your-host-name>`: The DNS host name, obtained from the **Properties** section of your Azure Cache for Redis resource in the Azure portal.

+- `<user-name>`: The object ID of your managed identity or service principal.

+ To get the user name:

+ 1. In the Azure portal, go to your Azure Cache for Redis instance.

+ 1. On the service menu, select **Data Access Configuration**.

+ 1. On the **Redis Users** tab, find the **Username** column and copy the value.

+Generate a new quickstart app by using Maven:

+Go to the new *redis-redisson-test* project directory.

+Open *App.java* and replace the existing code with the following code:

+This code shows you how to connect to an Azure Cache for Redis instance by using Microsoft Entra ID with the JCache API support from the Redisson client library. The code also stores and retrieves a string value in the cache. For more information, see the [JCache specification](https://jcp.org/en/jsr/detail?id=107).

+To build and run the app, run the following Maven command:

+In the following output, you can see that the `Message` key previously had a cached value that was set in the last run. The app updated that cached value.

+<!-- Clean up include -->

+## Related content

+- [Create an ASP.NET web app that uses Azure Cache for Redis](./cache-web-app-howto.md)

+- [Use Java with Azure Cache for Redis on Azure Kubernetes Service](/azure/developer/java/ee/how-to-deploy-java-liberty-jcache)

+ Title: 'Quickstart: Use Azure Cache for Redis with Node.js'

+description: Create a Node.js app and connect the app to Azure Cache for Redis by using node_redis.

+#Customer intent: As a Node.js developer who is new to Azure Cache for Redis, I want to create a new Node.js app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a Node.js app

+In this quickstart, you incorporate Azure Cache for Redis into a Node.js app for access to a secure, dedicated cache that is accessible from any application in Azure.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+- Node.js installed. For information about how to install Node and npm on a Windows computer, see [Install Node.js on Windows](/windows/dev-environment/javascript/nodejs-on-windows).

+## Create a cache

+The [node-redis](https://github.com/redis/node-redis) library is the primary Node.js client for Redis. You can install the client by using [npm](https://docs.npmjs.com/about-npm) and the following command:

+Create a Node.js app that uses either Microsoft Entra ID or access keys to connect to Azure Cache for Redis. We recommend that you use Microsoft Entra ID.

+## [Microsoft Entra ID authentication (recommended)](#tab/entraid)

+### Install the Azure Identity client library for JavaScript

+The [Azure Identity client library for JavaScript](/javascript/api/overview/azure/identity-readme) uses the required [Microsoft Authentication Library (MSAL)](/entra/identity-platform/msal-overview) to provide token authentication support. Install the library by using npm:

+### Create a Node.js app by using Microsoft Entra ID

+1. Add environment variables for your host name and service principal ID.

+ The service principal ID is the object ID of your Microsoft Entra ID service principal or user. In the Azure portal, this value appears as **Username**.

+1. Create a script file named *redistest.js*.

+1. Add the following example JavaScript to the file. This code shows you how to connect to an Azure Cache for Redis instance by using the cache host name and key environment variables. The code also stores and retrieves a string value in the cache. The `PING` and `CLIENT LIST` commands are also executed. For more examples of using Redis with the [node-redis](https://github.com/redis/node-redis) client, see [Node-Redis](https://redis.js.org/).

+1. Run the script by using Node.js:

+1. Verify that the output of your code looks like this example:

+### Create a sample JavaScript app that has reauthentication

+Microsoft Entra ID access tokens have a limited lifespan of approximately [75 minutes](/entra/identity-platform/configurable-token-lifetimes#token-lifetime-policies-for-access-saml-and-id-tokens). To maintain a connection to your cache, you must refresh the token.

+This example demonstrates how to refresh the token by using JavaScript:

+1. Create a script file named *redistestreauth.js*.

+1. Add the following example JavaScript to the file:

+1. Run the script by using Node.js:

+1. Check for output that looks similar to this example:

+> [!NOTE]

+> For more examples of how to use Microsoft Entra ID to authenticate to Redis via the node-redis library, see the [node-redis GitHub repository](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/samples/AzureCacheForRedis/node-redis.md).

+## [Access key authentication](#tab/accesskey)

+Add environment variables for your host name and primary access key. Use these variables from your code instead of including the sensitive information directly in your code.

+1. Create a new script file named *redistest.js*.

+1. Add the following example JavaScript to the file:

+ This code shows you how to connect to an Azure Cache for Redis instance by using the cache host name and key environment variables. The code also stores and retrieves a string value in the cache. The `PING` and `CLIENT LIST` commands are also executed. For more examples of using Redis with the [node_redis](https://github.com/redis/node-redis) client, see [Node-Redis](https://redis.js.org/).

+1. Run the script by using Node.js:

+1. Verify that the output looks similar to this example:

+Get the [Node.js quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/nodejs) on GitHub.

+- [Create an ASP.NET web app that uses an Azure Cache for Redis](cache-web-app-howto.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with Python'

+description: Create a Python app and connect the app to Azure Cache for Redis.

+#Customer intent: As a Python developer who is new to Azure Cache for Redis, I want to create a new Python app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a Python app

+In this quickstart, you incorporate Azure Cache for Redis into a Python script for access to a secure, dedicated cache that is accessible from any application in Azure.

+## Skip to the code

+This article describes how to create a Python app and then modify the code to end up with a working sample app.

+If you want to skip straight to the code, see the [Python quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/python) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+## Create a cache

+## Install the redis-py library

+[Redis-py](https://pypi.org/project/redis/) is a Python interface to Azure Cache for Redis. Use the Python packages tool pip to install the redis-py package at a command line.

+The following example uses `pip3` for Python 3 to install redis-py on Windows 11 in an Administrator Command Prompt window.

+Create a Python script that uses either Microsoft Entra ID or access keys to connect to Azure Cache for Redis. We recommend that you use Microsoft Entra ID.

+## [Microsoft Entra ID authentication (recommended)](#tab/entraid)

+### Install Microsoft Authentication Library

+[Microsoft Authentication Library (MSAL)](/entra/identity-platform/msal-overview) gets security tokens from the Microsoft identity platform to authenticate users.

+To install MSAL:

+1. Install [MSAL for Python](/entra/msal/python/).

+1. Install the [Python Azure identity client library](/python/api/overview/azure/identity-readme). The library uses MSAL to provide token authentication support.

+ Install this library by using pip:

+### Create a Python script by using Microsoft Entra ID

+1. Create a text file. Save the file as *PythonApplication1.py*.

+1. In *PythonApplication1.py*, add and modify the following script.

+ In the script:

+ - Replace `<Your Host Name>` with the value from your Azure Cache for Redis instance. Your host name has the form `<DNS name>.redis.cache.windows.net`.

+ - Replace `<Your Username>` with the value for your Microsoft Entra ID user.

+1. Before you run your Python code in a terminal, authorize the terminal to use Microsoft Entra ID:

+1. Run the *PythonApplication1.py* file by using Python. Verify that the output looks similar to this example:

+### Create a Python script by using reauthentication

+A Microsoft Entra ID access token has a limited lifespan of approximately [75 minutes](/entra/identity-platform/configurable-token-lifetimes#token-lifetime-policies-for-access-saml-and-id-tokens). To maintain a connection to your cache, you must refresh the token.

+This example demonstrates how to refresh a token by using Python.

+1. Create a text file. Save the file as *PythonApplication2.py*.

+1. In *PythonApplication2.py*, add and modify the following script.

+ In the script:

+ - Replace `<Your Host Name>` with the value from your Azure Cache for Redis instance. Your host name has the form `<DNS name>.redis.cache.windows.net`.

+ - Replace `<Your Username>` with the value for your Microsoft Entra ID user.

+1. Run the *PythonApplication2.py* file by using Python. Verify that the output looks similar to this example:

+ Unlike in the preceding example, if your token expires, the code in this example automatically refreshes the token.

+## [Access key authentication](#tab/accesskey)

+### Read and write to the cache at the command line

+To test your cache, run [Python from the command line](https://docs.python.org/3/faq/windows.html#id2).

+1. Initiate the Python interpreter in your command line by entering `py`.

+1. Modify and then run the following code.

+ In the code, replace `<Your Host Name>` and `<Your Access Key>` with the values from your Azure Cache for Redis instance. Your host name has the form `<DNS name>.redis.cache.windows.net`.

+ ```python

+ >>> import redis

+ >>> r = redis.Redis(host='<Your Host Name>',

+ port=6380, db=0, password='<Your Access Key>', ssl=True)

+ >>> r.set('foo', 'bar')

+ True

+ >>> r.get('foo')

+ b'bar'

+ ```

+### Create a Python script by using access keys

+1. Create a new text file. Save the file as *PythonApplication1.py*.

+1. In *PythonApplication1.py*, add and modify the following script.

+ In the script:

+ - Replace `<Your Host Name>` with the value from your Azure Cache for Redis instance. Your host name has the form `<DNS name>.redis.cache.windows.net`.

+ - Replace `<Your Access Key>` with the value for your Microsoft Entra ID user.

+ ```python

+ import redis

+

+ myHostname = "<Your Host Name>"

+ myPassword = "<Your Access Key>"

+

+ r = redis.Redis(host=myHostname, port=6380,

+ password=myPassword, ssl=True)

+

+ result = r.ping()

+ print("Ping returned : " + str(result))

+

+ result = r.set("Message", "Hello!, The cache is working with Python!")

+ print("SET Message returned : " + str(result))

+

+ result = r.get("Message")

+ print("GET Message returned : " + result)

+

+ result = r.client_list()

+ print("CLIENT LIST returned : ")

+ for c in result:

+ print(f"id : {c['id']}, addr : {c['addr']}")

+ ```

+1. Run the *PythonApplication1.py* file by using Python. Verify that results like the following example appear as output:

+ :::image type="content" source="media/cache-python-get-started/cache-python-completed.png" alt-text="Screenshot of a terminal showing a Python script to test cache access.":::

+- [Create a ASP.NET web app that uses Azure Cache for Redis](./cache-web-app-howto.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with Rust'

+description: Modify a sample Rust app and connect the app to Azure Cache for Redis.

+#Customer intent: As a Rust developer who is new to Azure Cache for Redis, I want to create a new Rust app that uses Azure Cache for Redis.

+# Quickstart: Use Azure Cache for Redis with a Rust app

+In this quickstart, you learn how to use the [Rust programming language](https://www.rust-lang.org/) to interact with [Azure Cache for Redis](./cache-overview.md). You also learn about commonly used Redis data structures:

+* [String](https://redis.io/topics/data-types-intro#redis-strings)

+* [Hash](https://redis.io/topics/data-types-intro#redis-hashes)

+* [List](https://redis.io/topics/data-types-intro#redis-lists)

+You start with a sample app and use the [redis-rs](https://github.com/mitsuhiko/redis-rs) library for Redis. The client exposes both high-level and low-level APIs, and you see both of these styles in action.

+## Skip to the code

+This article describes how to modify the code for a sample app to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the code, see the [Rust quickstart sample](https://github.com/Azure-Samples/azure-redis-cache-rust-quickstart/) on GitHub.

+* An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+* [Rust](https://www.rust-lang.org/tools/install) (version 1.39 or later)

+* [Git](https://git-scm.com/downloads)

+## Create a cache

+The `connect` function is used to establish a connection to Azure Cache for Redis. It expects the host name and the password (the access key) to be passed in via environment variables `REDIS_HOSTNAME` and `REDIS_PASSWORD` respectively. The format for the connection URL is `rediss://<username>:<password>@<hostname>`. Azure Cache for Redis accepts only secure connections. The minimum required version is [TLS 1.2](cache-remove-tls-10-11.md).

+The call to [redis::Client::open](https://docs.rs/redis/0.19.0/redis/struct.Client.html#method.open) does basic validation, and [get_connection()](https://docs.rs/redis/0.19.0/redis/struct.Client.html#method.get_connection) actually starts the connection. The program stops if the connectivity fails for any reason. For example, it fails if an incorrect password is used.

+The `basics` function covers the [SET](https://redis.io/commands/set), [GET](https://redis.io/commands/get), and [INCR](https://redis.io/commands/incr) commands.

+The low-level API is used for the `SET` and `GET` commands, which set and retrieve the value for a key named `foo`.

+The `INCRBY` command is executed by using a high-level API. The [incr](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.incr) method increments the value of a key (named `counter`) by `2` followed by a call to [get](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.get) to retrieve it.

+The following code snippet demonstrates the functionality of a Redis `HASH` data structure. [HSET](https://redis.io/commands/hset) is invoked by using the low-level API to store information (`name`, `version`, `repo`) about Redis drivers (clients). For example, details for the Rust driver (the one that's used in this sample code) are captured in the form of a [BTreeMap](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html). Then, the details are passed on to the low-level API. Finally, you retrieve the details by using [HGETALL](https://redis.io/commands/hgetall).

+`HSET` can also be executed by using a high-level API. [hset_multiple](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.hset_multiple) accepts an array of tuples. [hget](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.hget) is then executed to fetch the value for a single attribute (the value for `repo`, in this case).

+In the following function, you can see how to use a `LIST` data structure. [LPUSH](https://redis.io/commands/lpush) is executed (with the low-level API) to add an entry to the list. The high-level [lpop](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.lpop) method is used to retrieve that entry from the list. Then, the [rpush](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.rpush) method is used to add a couple of entries to the list, which are then fetched by using the low-level [lrange](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.lrange) method.

+Here you can see some of the `SET` operations. The [sadd](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.sadd) (high-level API) method adds a couple entries to a `SET` named `users`. [SISMEMBER](https://redis.io/commands/hset) is then executed (low-level API) to check whether `user1` exists. Finally, [smembers](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.smembers) is used to fetch and iterate over all the set entries in the form of a Vector ([Vec\<String\>](https://doc.rust-lang.org/std/vec/struct.Vec.html)).

+The `sorted_set` function demonstrates the Sorted Set data structure. [ZADD](https://redis.io/commands/zadd) is invoked with the low-level API to add a random integer score for a player (`player-1`). Next, the [zadd](https://docs.rs/redis/0.19.0/redis/trait.Commands.html#method.zadd) method (high-level API) is used to add more players (`player-2` to `player-5`) and their respective scores, which are randomly generated. The number of entries in the sorted set is determined by using [ZCARD](https://redis.io/commands/zcard). That number is the limit to the [ZRANGE](https://redis.io/commands/zrange) command (invoked with the low-level API) to list out the players with their scores in ascending order.

+Start by cloning the application repository on GitHub.

+1. In a Command Prompt window, create a folder named *git-samples*.

+1. Open a git terminal window, like in Git Bash. Use the `cd` command to go to the new folder where you will clone the sample app.

+1. Run the following command to clone the samples repository. This command creates a copy of the sample app on your computer.

+The application accepts connectivity and credentials in the form of environment variables.

+1. In the [Azure portal](https://portal.azure.com/), get the host name and access key for the Azure Cache for Redis instance.

+1. Set the values to the respective environment variables:

+ set REDIS_HOSTNAME=<Host name>:<port> (for example, <name of cache>.redis.cache.windows.net:6380)

+1. In the terminal window, go to the relevant folder.

+ For example:

+1. In the terminal, run the following command to start the application:

+ The output looks similar to this example:

+ If you want to run a specific function, comment-out other functions inside the `main` function:

+<!-- Clean up include -->

+## Related content

+* [Create a basic ASP.NET web app that uses Azure Cache for Redis](./cache-web-app-howto.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with ASP.NET Core'

+description: Modify a sample ASP.NET Core web app and connect the app to Azure Cache for Redis.

+#Customer intent: As an ASP.NET Core developer who is new to Azure Cache for Redis, I want to create a new ASP.NET Core app that uses Azure Cache for Redis.

+In this quickstart, you incorporate Azure Cache for Redis into an ASP.NET Core web application that connects to Azure Cache for Redis to store and get data from the cache.

+You can use a caching provider in your ASP.NET Core web app. To quickly start using Redis with minimal changes to your existing code, see:

+- [ASP.NET Core output cache provider](/aspnet/core/performance/caching/output#redis-cache)

+- [ASP.NET Core distributed caching provider](/aspnet/core/performance/caching/distributed#distributed-redis-cache)

+- [ASP.NET Core Redis session provider](/aspnet/core/fundamentals/app-state#configure-session-state)

+## Skip to the code

+This article describes how to modify the code for a sample app to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the code, see the [ASP.NET Core quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/aspnet-core) on GitHub.

+You can clone the [Azure Cache for Redis samples](https://github.com/Azure-Samples/azure-cache-redis-samples) GitHub repository, and then go to the *quickstart/aspnet-core* directory to view the completed source code for the steps that are described in this article.

+The *quickstart/aspnet-core* directory is also configured as an [Azure Developer CLI](/azure/developer/azure-developer-cli/overview) template. Use the open-source azd tool to streamline provisioning and deployment from a local environment to Azure. Optionally, run the `azd up` command to automatically provision an Azure Cache for Redis instance, and to configure the local sample app to connect to it:

+As a next step, you can see a real-world scenario eShop application that demonstrates the ASP.NET Core caching providers: [ASP.NET Core eShop by using Redis caching providers](https://github.com/Azure-Samples/azure-cache-redis-demos).

+Features include:

+- Redis distributed caching

+Deployment instructions are in the *README.md* file in the [ASP.NET Core quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/aspnet-core) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/)

+In your command window, run the following command to store a new secret named *RedisHostName*. In the code, replace the placeholders, including angle brackets, with your cache name and primary access key:

+## Connect to the cache by using RedisConnection

+The `RedisConnection` class manages the connection to your cache. The connection is made in this statement in *HomeController.cs* in the *Controllers* folder:

+The *RedisConnection.cs* file includes the StackExchange.Redis and Azure.Identity namespaces at the top of the file to include essential types to connect to Azure Cache for Redis:

+The `RedisConnection` class code ensures that there's always a healthy connection to the cache. The connection is managed by the `ConnectionMultiplexer` instance from StackExchange.Redis. The `RedisConnection` class re-creates the connection when a connection is lost and can't reconnect automatically.

+For more information, see [StackExchange.Redis](https://stackexchange.github.io/StackExchange.Redis/) and the code in the [StackExchange.Redis GitHub repo](https://github.com/StackExchange/StackExchange.Redis).

+## Verify layout views in the sample

+The home page layout for this sample is stored in the *_Layout.cshtml* file. In the next section, you test the cache by using the controller that you add here.

+1. Verify that the following line is in `<div class="navbar-header">`:

+### Show data from the cache

+On the home page, select **Azure Cache for Redis Test** in the navigation bar to see the sample output.

+1. In Solution Explorer, expand the **Views** folder, and then right-click the **Home** folder.

+1. Verify that the following code is in the *RedisCache.cshtml* file:

+1. In a Command Prompt window, build the app by using the following command:

+1. Run the app by using this command:

+1. In a web browser, go to `https://localhost:5001`.

+1. On the webpage navigation bar, select **Azure Cache for Redis Test** to test cache access.

+- [Connection resilience best practices for your cache](cache-best-practices-connection.md)

+- [Development best practices for your cache](cache-best-practices-development.md)

+ Title: 'Quickstart: Use Azure Cache for Redis with ASP.NET'

+description: Modify a sample ASP.NET web app and connect the app to Azure Cache for Redis.

+#Customer intent: As an ASP.NET web app developer who is new to Azure Cache for Redis, I want to create a new ASP.NET web app that uses Azure Cache for Redis.

+In this quickstart, you use Visual Studio 2019 to modify an ASP.NET web application that connects to Azure Cache for Redis to store and get data from the cache. Then, you deploy the app to Azure App Service.

+## Skip to the code

+This article describes how to modify the code for a sample app to create a working app that connects to Azure Cache for Redis.

+If you want to go straight to the sample code, see the [ASP.NET quickstart sample](https://github.com/Azure-Samples/azure-cache-redis-samples/tree/main/quickstart/aspnet) on GitHub.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/dotnet)

+Next, create the cache to use with the app.

+### Edit the CacheSecrets.config file

+1. On your computer, create a file named *CacheSecrets.config*. Put the file in a location where it isn't checked in with the source code of your sample application. For this quickstart, the *CacheSecrets.config* file is in the *C:\AppSecrets\\* folder.

+1. Edit the *CacheSecrets.config* file to add the following content.

+ In the code:

+ - Replace `<cache-name>` with your cache host name.

+ - Replace `<access-key>` with the primary access key for your cache.

+ > [!TIP]

+ > You can use the secondary access key during key rotation as an alternate key while you regenerate the primary access key.

+ >

+In this section, a model-view-controller (MVC) application displays a simple test for the connection to Azure Cache for Redis.

+When you run the application locally, the information in *CacheSecrets.config* is used to connect to your Azure Cache for Redis instance. Later, you can deploy this application to Azure. At that time, you configure an app setting in Azure that the application uses to retrieve the cache connection information instead of using the config file.

+Because the *CacheSecrets.config* file isn't deployed to Azure with your application, you use it only when you test the application locally. Keep this information as secure as possible to help prevent malicious access to your cache data.

+### Update the web.config file

+1. In Solution Explorer, open the *web.config* file.

+ :::image type="content" source="media/cache-web-app-howto/cache-web-config.png" alt-text="Screenshot that shows the web.config file in Visual Studio Solution Explorer.":::

+1. In the *web.config* file, set the `<appSettings>` element to run the application locally:

+ `<appSettings file="C:\AppSecrets\CacheSecrets.config">`

+Your solution requires the `StackExchange.Redis` package to run.

+To install the `StackExchange.Redis` package:

+1. To configure the app to use the [StackExchange.Redis](https://github.com/StackExchange/StackExchange.Redis) NuGet package for Visual Studio, select **Tools** > **NuGet Package Manager** > **Package Manager Console**.

+1. In the Package Manager Console window, run the following command:

+The NuGet package downloads and adds the required assembly references for your client application to access Azure Cache for Redis by using the `StackExchange.Redis` client.

+## Connect to the cache by using RedisConnection

+The connection to your cache is managed by the `RedisConnection` class. The connection is first made in this statement that's in *ContosoTeamStats/Controllers/HomeController.cs*:

+The value of the `CacheConnection` secret is accessed by using the Secret Manager configuration provider and is used as the password parameter.

+In *RedisConnection.cs*, you can see that the StackExchange.Redis namespace is added to the code. The `RedisConnection` class requires the namespace.

+The `RedisConnection` code ensures that there's always a healthy connection to the cache. The connection is managed via the `ConnectionMultiplexer` instance in StackExchange.Redis. The `RedisConnection` class re-creates the connection when a connection is lost and unable to reconnect automatically.

+## Verify layout views in the sample

+The home page layout for this sample is stored in the *_Layout.cshtml* file. From this page, you start the actual cache testing by selecting **Azure Cache for Redis Test** on this page.

+1. In Solution Explorer, select **Views**, and then right-click the **Shared** folder. Then, open the *_Layout.cshtml* file.

+1. Verify that the following line is in `<div class="navbar-header">`:

+ :::image type="content" source="media/cache-web-app-howto/cache-welcome-page.png" alt-text="Screenshot that shows welcome and navigation options on a webpage.":::

+### Show data from the cache

+On the home page, select **Azure Cache for Redis Test** in the navigation bar to see the sample output.

+1. In Solution Explorer, select **Views**, and then right-click the **Home** folder.

+1. Verify that the following code is in the *RedisCache.cshtml* file:

+To run the app locally:

+ :::image type="content" source="media/cache-web-app-howto/cache-simple-test-complete-local.png" alt-text="Screenshot that shows a simple test completed locally.":::

+To publish the app to Azure:

+1. In Visual Studio, in Solution Explorer, right-click the project node and select **Publish**.

+ :::image type="content" source="media/cache-web-app-howto/cache-publish-app.png" alt-text="Screenshot that shows the Publish menu command highlighted in Azure.":::

+1. Select **Microsoft Azure App Service** > **Create New** > **Publish**.

+ :::image type="content" source="media/cache-web-app-howto/cache-publish-to-app-service.png" alt-text="Screenshot that shows menu options to set to publish to App Service.":::

+ | Setting | Action | Description |

+ | **App name** | Use the default. | The app name is the host name for the app when it's deployed to Azure. The name might have a timestamp suffix added to it to make the app name unique. |

+ | **Subscription** | Select your Azure subscription. | This subscription is charged for any related hosting costs. If you have multiple Azure subscriptions, verify that the subscription that you want to use is selected.|

+ | **Resource group** | Use the same resource group that you used to create the cache (for example, **TestResourceGroup**). | The resource group helps you manage all resources as a group. Later, when you want to delete the app, you can delete the resource group to delete all related resources. |

+ | **App Service plan** | Select **New**, and then create a new App Service plan named **TestingPlan**. <br />Use the same value for **Location** that you used when you created your cache. <br />For size, select **Free**. | An App Service plan defines a set of compute resources for a web app to run with. |

+ :::image type="content" source="media/cache-web-app-howto/cache-create-app-service-dialog.png" alt-text="Screenshot that shows the App Service dialog box in Azure.":::

+1. After you configure the App Service host settings, select **Create**.

+1. In the Output window, check the publishing status. After the app is published, the URL for the app appears as output:

+ :::image type="content" source="media/cache-web-app-howto/cache-publishing-output.png" alt-text="Screenshot that shows the publishing output window in Visual Studio.":::

+### Add an app setting for the cache

+After the new app is published, add a new app setting in the Azure portal. This setting stores the cache connection information.

+To add the app setting:

+1. In the Azure portal, enter the name of the app in the search bar.

+ :::image type="content" source="media/cache-web-app-howto/cache-find-app-service.png" alt-text="Screenshot that shows searching for an app in the Azure portal.":::

+1. Add a new app setting named **CacheConnection** for the app to use to connect to the cache. Use the same value that you used for `CacheConnection` in the *CacheSecrets.config* file. The value contains the cache host name and access key.

+ :::image type="content" source="media/cache-web-app-howto/cache-add-app-setting.png" alt-text="Screenshot that shows adding an app setting.":::

+1. In your browser, go to the URL for the app. The URL appears in the results of the publishing operation in the Visual Studio Output window. It also appears in the Azure portal on the Overview pane of your app.

+1. On the webpage navigation bar, select **Azure Cache for Redis Test** to test cache access like you did with the local version.

+<!-- Clean up include -->

+## Related content

+- [Connection resilience best practices for your cache](cache-best-practices-connection.md)

+- [Development best practices for your cache](cache-best-practices-development.md)

+description: Learn how to create an instance of Azure Cache for Redis to use in the Enterprise tier.

+#Customer intent: As a Redis Enterprise developer who is new to Azure Cache for Redis, I want to create a new cache in the Enterprise tier of Azure Cache for Redis.

+The Enterprise tiers for Azure Cache for Redis provide fully integrated and managed [Redis Enterprise](https://redislabs.com/redis-enterprise/) on Azure.

+The Enterprise tiers include two tier options:

+- **Enterprise**: This tier uses volatile memory (dynamic random access memory (DRAM)) on a virtual machine to store data.

+- **Enterprise Flash**: This tier uses both volatile and nonvolatile memory (NVM Express (NVMe) or solid-state drive (SSD)) to store data.

+- An Azure subscription. [Create one for free](https://azure.microsoft.com/free/). For more information, see [Special considerations for Enterprise tiers](cache-overview.md#special-considerations-for-enterprise-tiers).

+Azure Cache for Redis continually expands to new regions in Azure. To check the availability by region for all tiers, see [Products available by region](https://azure.microsoft.com/global-infrastructure/services/?products=redis-cache&regions=all).

+1. To create a cache, sign in to the [Azure portal](https://portal.azure.com). On the portal menu, select **Create a resource**.

+1. On the **New** pane, select **Databases**. In the search results, select **Azure Cache for Redis**.

+ :::image type="content" source="media/cache-create/new-cache-menu.png" alt-text="Screenshot that highlights Azure Cache for Redis in search results on the New pane to create a new Azure resource.":::

+1. On the **New Redis Cache** pane, on the **Basics** tab, configure the following settings for your cache:

+ | Setting | Action | Description |

+ | **Subscription** | Select your Azure subscription. | The subscription to use to create the new instance of Azure Cache for Redis. |

+ | **Resource group** | Select a resource group, or select **Create new** and enter a new resource group name. | A name for the resource group in which to create your cache and other resources. By putting all your app resources in one resource group, you can easily manage or delete them together. |

+ | **DNS name** | Enter a name that is unique in the Azure region. | The cache name must be a string of 1 to 63 characters that contains only numbers, letters, and hyphens. (If the cache name is fewer than 45 characters long, it should work in all currently available regions.) The name must start and end with a number or letter, and it can't contain consecutive hyphens. Your cache instance's _host name_ is `\<DNS name\>.\<Azure region\>.redisenterprise.cache.azure.net`. |

+ | **Location** | Select a location. | An [Azure region](https://azure.microsoft.com/regions/) that is near other services that use your cache. Enterprise tiers are available in selected Azure regions. |

+ | **Cache type** | Select **Enterprise** or **Enterprise Flash** tier and a cache size. | The tier determines the size, performance, and features that are available for your cache. |

+ :::image type="content" source="media/cache-create/enterprise-tier-basics.png" alt-text="Screenshot that shows the Enterprise tier Basics tab on the New Redis Cache pane.":::

+ > Be sure to select the checkbox for **Terms** before you proceed.

+1. On the **Advanced** tab, configure these settings:

+ 1. Select the **Non-TLS access only** checkbox _only_ if you plan to connect to the new cache without using Transport Layer Security (TLS). We recommend that you don't disable TLS.

+ 1. For **Clustering Policy**, for a nonclustered cache, select **Enterprise**. For a clustered cache, select **OSS**.

+ For more information about choosing the clustering policy to use for your cache, see [Clustering on Enterprise](cache-best-practices-enterprise-tiers.md#clustering-on-enterprise).

+ :::image type="content" source="media/cache-create/cache-clustering-policy.png" alt-text="Screenshot that shows the Enterprise tier Advanced tab on the New Redis Cache pane.":::

+ > - The Enterprise tier and the Enterprise Flash tier are inherently clustered, in contrast to the Basic, Standard, and Premium tiers. Redis Enterprise offers two clustering policies:

+ > - Use the **Enterprise** clustering policy to access your cache by using the Redis API.

+ > - Use the **OSS** clustering policy to use the OSS Cluster API.

+ > For more information, see [Clustering on Enterprise](cache-best-practices-enterprise-tiers.md#clustering-on-enterprise).

+ >

+ > - You can't change the clustering policy of an Enterprise cache after you create it. If you use [RediSearch](cache-redis-modules.md#redisearch), the Enterprise clustering policy is required, and `NoEviction` is the only supported eviction policy.

+ >

+ > - If you use this cache in a geo-replication group, you can't change eviction policies after you create the cache. Be sure to know the eviction policies of your primary nodes before you create the cache.

+ >

+ > For more information about active geo-replication, see [Active geo-replication prerequisites](cache-how-to-active-geo-replication.md#active-geo-replication-prerequisites).

+ >

+ > - You can't change modules after you create a cache. Modules must be enabled at the time you create your instance of Azure Cache for Redis. There is no option to enable the configuration of a module after you create a cache.

+1. Select **Next: Tags** (skip), and then select **Next: Review + create**.

+ :::image type="content" source="media/cache-create/enterprise-tier-summary.png" alt-text="Screenshot that shows the Enterprise tier Review + create tab on the New Redis Cache pane.":::

+1. On the **Review + create** tab, review the settings, and then select **Create**.

+It takes some time for the cache deployment to finish. You can monitor progress on the Azure Cache for Redis Overview pane. When **Status** displays **Running**, the cache is ready to use.

+

+- [Create an ASP.NET web app that uses Azure Cache for Redis](cache-web-app-aspnet-core-howto.md)

+Event-driven scaling automatically reduces capacity when demand for your functions is reduced. It does this by draining instances of their current function executions and then removes those instances. This behavior is logged as drain mode. The grace period for functions that are currently executing can extend up to 10 minutes for Consumption plan apps and up to 60 minutes for Flex Consumption and Premium plan apps. Event-driven scaling and this behavior don't apply to Dedicated plan apps.

+1. Follow [Authorize from application](./howto-authorize-from-application.md) to enable Microsoft Entra ID.

+1. Get the Microsoft Entra token.

+1. Use the Microsoft Entra token to invoke `:generateToken`.

+ identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name" }

+subscription_id = "yyyy-yyy-yyy-yyy-yyy"

+resource_group_name = "TestRG"

+user_assigned_identity_name = "testUMI"

+resource_id = f"/subscriptions/{subscription_id}/resourceGroups/{resource_group_name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{user_assigned_identity_name}"

+ identity_reference = ComputeNodeIdentityReference(resource_id = resource_id))

+ identityReference: new ComputeNodeIdentityReference() { ResourceId = "/subscriptions/SUB/resourceGroups/RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity-name" }

+);

+a managed identity can be used to authenticate with the service. To use a managed identity,

+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).

+// TODO: Replace <storage-account-name> with your actual storage account name

+Uri accountUri = new Uri("https://<storage-account-name>.blob.core.windows.net/");

+BlobServiceClient blobClient = new BlobServiceClient(accountUri, new DefaultAzureCredential());

+```

+The app creates a reference to the [BatchAccountResource](/dotnet/api/azure.resourcemanager.batch.batchaccountresource) via the Resource manager's [ArmClient](/dotnet/api/azure.resourcemanager.armclient) to create the pool in the Batch service. The Arm client in the sample uses [DefaultAzureCredential](/dotnet/api/azure.identity.defaultazurecredential) authentication.

+```csharp

+ArmClient _armClient = new ArmClient(new DefaultAzureCredential());

+var batchAccountIdentifier = ResourceIdentifier.Parse(BatchAccountResourceID);

+BatchAccountResource batchAccount = await _armClient.GetBatchAccountResource(batchAccountIdentifier).GetAsync();

+The app creates a [BatchClient](/dotnet/api/azure.compute.batch.batchclient) object to create and jobs and tasks in the Batch service. The Batch client in the sample uses [DefaultAzureCredential](/dotnet/api/azure.identity.defaultazurecredential) authentication.

+// TODO: Replace <batch-account-name> with your actual storage account name

+Uri batchUri = new Uri("https://<batch-account-name>t.eastus.batch.azure.com");

+BatchClient _batchClient = new BatchClient(batchUri, new DefaultAzureCredential());

+The app passes the `blobServerClient` object to the `CreateContainerIfNotExistc` method to create a storage container for the input files (MP4 format) and a container for the task output.

+CreateContainerIfNotExist(blobClient, inputContainerName);

+CreateContainerIfNotExist(blobClient, outputContainerName);

+Then, files are uploaded to the input container from the local *InputFiles* folder. The files in storage are defined as Batch [ResourceFile](/dotnet/api/azure.compute.batch.resourcefile) objects that Batch can later download to compute nodes.

+Next, the sample creates a pool of compute nodes in the Batch account with a call to `CreatePoolIfNotExistAsync`. This defined method uses the [BatchAccountResource.GetBatchAccountPools().CreateOrUpdateAsync](/dotnet/api/azure.resourcemanager.batch.batchaccountpoolcollection.createorupdateasync) method to set the number of nodes, VM size, and a pool configuration. Here, a [BatchVmConfiguration](/dotnet/api/azure.resourcemanager.batch.models.batchvmconfiguration) object specifies an [BatchImageReference ](/dotnet/api/azure.resourcemanager.batch.models.batchimagereference) to a Windows Server image published in the Azure Marketplace. Batch supports a wide range of VM images in the Azure Marketplace, as well as custom VM images.

+var credential = new DefaultAzureCredential();

+ArmClient _armClient = new ArmClient(credential);

+var batchAccountIdentifier = ResourceIdentifier.Parse(BatchAccountResourceID);

+BatchAccountResource batchAccount = await _armClient.GetBatchAccountResource(batchAccountIdentifier).GetAsync();

+BatchAccountPoolCollection collection = batchAccount.GetBatchAccountPools();

+if (collection.Exists(poolId) == false)

+{

+ var poolName = poolId;

+ var imageReference = new BatchImageReference()

+ {

+ Publisher = "MicrosoftWindowsServer",

+ Offer = "WindowsServer",

+ Sku = "2019-datacenter-smalldisk",

+ Version = "latest"

+ };

+ string nodeAgentSku = "batch.node.windows amd64";

+ ArmOperation<BatchAccountPoolResource> armOperation = await batchAccount.GetBatchAccountPools().CreateOrUpdateAsync(

+ WaitUntil.Completed, poolName, new BatchAccountPoolData()

+ {

+ VmSize = "Standard_DS1_v2",

+ DeploymentConfiguration = new BatchDeploymentConfiguration()

+ {

+ VmConfiguration = new BatchVmConfiguration(imageReference, nodeAgentSku)

+ },

+ ScaleSettings = new BatchAccountPoolScaleSettings()

+ {

+ FixedScale = new BatchAccountFixedScaleSettings()

+ {

+ TargetDedicatedNodes = DedicatedNodeCount,

+ TargetLowPriorityNodes = LowPriorityNodeCount

+ }

+ },

+ Identity = new ManagedServiceIdentity(ManagedServiceIdentityType.UserAssigned)

+ {

+ UserAssignedIdentities =

+ {

+ [new ResourceIdentifier(ManagedIdentityId)] = new Azure.ResourceManager.Models.UserAssignedIdentity(),

+ },

+ },

+ ApplicationPackages =

+ {

+ new Azure.ResourceManager.Batch.Models.BatchApplicationPackageReference(new ResourceIdentifier(appPacakgeResourceID))

+ {

+ Version = appPackageVersion,

+ }

+ },

+ });

+ BatchAccountPoolResource pool = armOperation.Value;

+A Batch job specifies a pool to run tasks on and optional settings such as a priority and schedule for the work. The sample creates a job with a call to `CreateJobAsync`. This defined method uses the [BatchClient.CreateJobAsync](/dotnet/api/azure.compute.batch.batchclient.createjobasync) method to create a job on your pool.

+ BatchJobCreateContent batchJobCreateContent = new BatchJobCreateContent(jobId, new BatchPoolInfo { PoolId = poolId });

+ await batchClient.CreateJobAsync(batchJobCreateContent);

+The sample creates tasks in the job with a call to the `AddTasksAsync` method, which creates a list of [BatchTask ](/dotnet/api/azure.compute.batch.batchtask) objects. Each `BatchTask` runs ffmpeg to process an input `ResourceFile` object using a [CommandLine](/dotnet/api/azure.compute.batch.batchtask.commandline) property. ffmpeg was previously installed on each node when the pool was created. Here, the command line runs ffmpeg to convert each input MP4 (video) file to an MP3 (audio) file.

+The sample creates an [OutputFile](/dotnet/api/azure.compute.batch.outputfile) object for the MP3 file after running the command line. Each task's output files (one, in this case) are uploaded to a container in the linked storage account, using the task's [OutputFiles](/dotnet/api/azure.compute.batch.batchtask.outputfiles) property. Note the conditions set on the `outputFile` object. An output file from a task is only uploaded to the container after the task has successfully completed (`OutputFileUploadCondition.TaskSuccess`). See the full [code sample](https://github.com/Azure-Samples/batch-dotnet-ffmpeg-tutorial) on GitHub for further implementation details.

+Then, the sample adds tasks to the job with the [CreateTaskAsync ](/dotnet/api/azure.compute.batch.batchclient.createtaskasync) method, which queues them to run on the compute nodes.

+// Create a collection to hold the tasks added to the job:

+List<BatchTaskCreateContent> tasks = new List<BatchTaskCreateContent>();

+ // Assign a task ID for each iteration

+ // Define task command line to convert the video format from MP4 to MP3 using ffmpeg.

+ // Note that ffmpeg syntax specifies the format as the file extension of the input file

+ // and the output file respectively. In this case inputs are MP4.

+ string inputMediaFile = inputFiles[i].StorageContainerUrl;

+ string taskCommandLine = String.Format("cmd /c {0}\\ffmpeg-4.3.1-2020-11-08-full_build\\bin\\ffmpeg.exe -i {1} {2}", appPath, inputMediaFile, outputMediaFile);

+ // Create a batch task (with the task ID and command line) and add it to the task list

+ BatchTaskCreateContent batchTaskCreateContent = new BatchTaskCreateContent(taskId, taskCommandLine);

+ batchTaskCreateContent.ResourceFiles.Add(inputFiles[i]);

+ // Task output file will be uploaded to the output container in Storage.

+ // TODO: Replace <storage-account-name> with your actual storage account name

+ OutputFileBlobContainerDestination outputContainer = new OutputFileBlobContainerDestination("https://<storage-account-name>.blob.core.windows.net/output/" + outputMediaFile)

+ {

+ IdentityReference = inputFiles[i].IdentityReference,

+ };

+ OutputFile outputFile = new OutputFile(outputMediaFile,

+ new OutputFileDestination() { Container = outputContainer },

+ new OutputFileUploadConfig(OutputFileUploadCondition.TaskSuccess));

+ batchTaskCreateContent.OutputFiles.Add(outputFile);

+ tasks.Add(batchTaskCreateContent);

+// Call BatchClient.CreateTaskCollectionAsync() to add the tasks as a collection rather than making a

+// separate call for each. Bulk task submission helps to ensure efficient underlying API

+// calls to the Batch service.

+await batchClient.CreateTaskCollectionAsync(jobId, new BatchTaskGroup(tasks));

+After it runs the tasks, the app automatically deletes the input storage container it created, and gives you the option to delete the Batch pool and job. The BatchClient has a method to delete a job [DeleteJobAsync](/dotnet/api/azure.compute.batch.batchclient.deletejobasync) and delete a pool [DeletePoolAsync](/dotnet/api/azure.compute.batch.batchclient.deletepoolasync), which are called if you confirm deletion. Although you're not charged for jobs and tasks themselves, you are charged for compute nodes. Thus, we recommend that you allocate pools only as needed. When you delete the pool, all task output on the nodes is deleted. However, the output files remain in the storage account.

+If you're using the Azure CLI with a Consumption only environment and the [platformReservedCidr](vnet-custom-internal.md?pivots=azure-cli&tabs=bash#networking-parameters) range is defined, the subnet must not overlap with the IP range defined in `platformReservedCidr`.

+ - Microsoft Online Service Program (MOSP), also known as pay-as-you-go

+ - Cloud Solution Provider (CSP) - MCA managed by partner

+ - Others like Visual Studio, EOPEN, Azure Pass, and Free Trial

+## Parent subscription cancellation and transfer limitations

+If your subscription contains an active Microsoft Azure Consumption Commitment (MACC) agreement, you can't cancel or transfer the subscription because of the contractual obligation to fulfill the terms of the MACC commitment. The parent subscription must remain active as long as it contains an active MACC. Once the MACC expires, the subscription is able to be canceled or transferred.

+| EA | MOSP (pay-as-you-go) | ΓÇó Transfer from an EA enrollment to a MOSP subscription requires a [billing support ticket](https://azure.microsoft.com/support/create-ticket/).<br><br> ΓÇó Reservations and savings plans don't automatically transfer and transferring them isn't supported. |

+| MCA-online | MOSP (pay-as-you-go) | ΓÇó Microsoft doesn't support the transfer, so you must move resources yourself. For more information, see [Move resources to a new resource group or subscription](../../azure-resource-manager/management/move-resource-group-and-subscription.md).<br><br> ΓÇó Reservations and savings plans don't automatically transfer and transferring them isn't supported. |

+| MOSP (pay-as-you-go) | MOSP (pay-as-you-go) | ΓÇó If you're changing the billing owner of the subscription, see [Transfer billing ownership of an Azure subscription to another account](billing-subscription-transfer.md).<br><br> ΓÇó Reservations don't automatically transfer so you must open a [billing support ticket](https://azure.microsoft.com/support/create-ticket/) to transfer them. |

+| MOSP (pay-as-you-go) | MCA-online | ΓÇó For details, see [Transfer Azure subscription billing ownership for a Microsoft Customer Agreement](mca-request-billing-ownership.md).<br><br> ΓÇó Self-service reservation transfers are supported. |

+| MOSP (pay-as-you-go) | EA | ΓÇó If you're transferring the admin account to the EA enrollment, see [Transfer a subscription to an EA](mosp-ea-transfer.md#transfer-the-subscription-to-the-ea).<br><br> ΓÇó If you're transferring subscriptions to the EA enrollment, you must create a [billing support ticket](https://azure.microsoft.com/support/create-ticket/). |

+| MOSP (pay-as-you-go) | MCA-E | ΓÇó For details, see [Transfer Azure subscription billing ownership for a Microsoft Customer Agreement](mca-request-billing-ownership.md).<br><br> ΓÇó Self-service reservation transfers are supported. |

+| objectApiName | The Salesforce Service Cloud object name to retrieve data from. The applicable self-hosted integration runtime version is 5.44.8984.1 or above. | No for source (if "query" in source is specified), Yes for sink |

+| reportId | The ID of the Salesforce Service Cloud report to retrieve data from. It is not supported in sink. Note that there are [limitations](https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_limits_limitations.htm) when you use reports. The applicable self-hosted integration runtime version is 5.44.8984.1 or above. | No for source (if "query" in source is specified), not support sink |

+| query | Use the custom query to read data. You can only use [Salesforce Object Query Language (SOQL)](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) query with limitations. For SOQL limitations, see this [article](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). If query is not specified, all the data of the Salesforce object specified in "objectApiName/reportId" in dataset will be retrieved. | No (if "objectApiName/reportId" in the dataset is specified) |

+ "query": "SELECT Col_Currency__c, Col_Date__c, Col_Email__c FROM AllDataType__c",

+|Support SOQL within [Salesforce Bulk API 2.0](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). <br>For SOQL queries: <br>ΓÇó GROUP BY, LIMIT, ORDER BY, OFFSET, or TYPEOF clauses aren't supported. <br>ΓÇó Aggregate Functions such as COUNT() aren't supported, you can use Salesforce reports to implement them. <br>ΓÇó Date functions in GROUP BY clauses aren't supported, but they're supported in the WHERE clause. <br>ΓÇó Compound address fields or compound geolocation fields aren't supported. As an alternative, query the individual components of compound fields. <br>ΓÇó Parent-to-child relationship queries aren't supported, whereas child-to-parent relationship queries are supported. |Support both SQL and SOQL syntax. |

+| Objects that contain binary fields aren't supported when specifying query. | Objects that contain binary fields are supported when specifying query.|

+| Support objects within Bulk API when specifying query. | Support objects that are unsupported with Bulk API when specifying query.|

+| objectApiName | The Salesforce object name to retrieve data from. The applicable self-hosted integration runtime version is 5.44.8984.1 or above. | No for source (if "query" in source is specified), Yes for sink |

+| reportId | The ID of the Salesforce report to retrieve data from. It isn't supported in sink. There are [limitations](https://developer.salesforce.com/docs/atlas.en-us.api_analytics.meta/api_analytics/sforce_analytics_rest_api_limits_limitations.htm) when you use reports. The applicable self-hosted integration runtime version is 5.44.8984.1 or above. | No for source (if "query" in source is specified), not support sink |

+| query | Use the custom query to read data. You can only use [Salesforce Object Query Language (SOQL)](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) query with limitations. For SOQL limitations, see this [article](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/queries.htm#SOQL%20Considerations). If query isn't specified, all the data of the Salesforce object specified in "objectApiName/reportId" in dataset is retrieved. | No (if "objectApiName/reportId" in the dataset is specified) |

+| Objects that contain binary fields aren't supported when specifying query. | Objects that contain binary fields are supported when specifying query.|

+| Support objects within Bulk API when specifying query. | Support objects that are unsupported with Bulk API when specifying query.|

+The model looks like this:

+To upload this model to your twins instance, run the following Azure CLI command, which uploads the above model as inline JSON. You can run the command in [Azure Cloud Shell](../cloud-shell/overview.md) in your browser (use the Bash environment), or on your machine if you have the [CLI installed locally](/cli/azure/install-azure-cli). There's one placeholder for the instance's host name (you can also use the instance's friendly name with a slight decrease in performance).

+```azurecli-interactive

+az dt model create --dt-name <instance-hostname-or-name> --models '{ "@id": "dtmi:contosocom:DigitalTwins:Thermostat;1", "@type": "Interface", "@context": "dtmi:dtdl:context;2", "contents": [ { "@type": "Property", "name": "Temperature", "schema": "double" } ]}'

+```

+>[!NOTE]

+>If you're using anything other than Cloud Shell in the Bash environment, you may need to escape certain characters in the inline JSON so that it's parsed correctly. For more information, see [Use special characters in different shells](concepts-cli.md#use-special-characters-in-different-shells).

+1. Select the **Overview** tab of ExpressRoute circuit

+1. Select **Add Global Reach** to open the *Add Global Reach* configuration page.

+ * [Link a VNet to an ExpressRoute circuit](expressroute-howto-linkvnet-arm.md)

+ 10 On-Prem 20.33.0.1 ffff.eeee.dddd

+ 0 Microsoft 20.33.0.2 aaaa.bbbb.cccc

+ 10 On-Prem 20.33.0.1 ffff.eeee.dddd

+ 0 Microsoft 20.33.0.2 aaaa.bbbb.cccc

+ 10 On-Prem 20.33.0.1 ffff.eeee.dddd

+ 0 On-Prem 20.33.0.1 Incomplete

+ 0 Microsoft 20.33.0.2 aaaa.bbbb.cccc

+ 0 Microsoft 20.33.0.2 aaaa.bbbb.cccc

+* Provide additional information needed by the connectivity provider (for example, VLAN ID).

+Configure routing domains. If your connectivity provider manages Layer 3 configuration, they configure routing for your circuit. If your connectivity provider only offers Layer 2 services or if you're using ExpressRoute Direct, you must configure routing per the guidelines described in the [Routing requirements](expressroute-routing.md) and [Routing configuration](expressroute-howto-routing-arm.md) articles.

+ * **Name** - Enter a unique name for the new Front Door endpoint. Azure Front Door generates a unique endpoint hostname based on the endpoint name in the form of `<endpointname>-*.z01.azurefd.net`.

+ * **Endpoint hostname** - A deterministic DNS (domain name system) name that helps prevent subdomain takeover. This name is used to access your resources through your Azure Front Door at the domainΓÇ»`<endpointname>-*.z01.azurefd.net`.

+## Risk Based Transaction Monitoring

+### Risk Based Transaction Monitoring-20.1

+|[A vulnerability assessment solution should be enabled on your virtual machines](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F501541f7-f7e7-4cd6-868c-4190fdad3ac9) |Audits virtual machines to detect whether they are running a supported vulnerability assessment solution. A core component of every cyber risk and security program is the identification and analysis of vulnerabilities. Azure Security Center's standard pricing tier includes vulnerability scanning for your virtual machines at no extra cost. Additionally, Security Center can automatically deploy this tool for you. |AuditIfNotExists, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Security%20Center/ASC_ServerVulnerabilityAssessment_Audit.json) |

+|[Email notification for high severity alerts should be enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F6e2593d9-add6-4083-9c9b-4b7d2188c899) |To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, enable email notifications for high severity alerts in Security Center. |AuditIfNotExists, Disabled |[1.2.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Security%20Center/ASC_Email_notification.json) |

+|[Email notification to subscription owner for high severity alerts should be enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0b15565f-aa9e-48ba-8619-45960f2c314d) |To ensure your subscription owners are notified when there is a potential security breach in their subscription, set email notifications to subscription owners for high severity alerts in Security Center. |AuditIfNotExists, Disabled |[2.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Security%20Center/ASC_Email_notification_to_subscription_owner.json) |

+|[Subscriptions should have a contact email address for security issues](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F4f4f78b8-e367-4b10-a341-d9a4ad5cf1c7) |To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, set a security contact to receive email notifications from Security Center. |AuditIfNotExists, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Security%20Center/ASC_Security_contact_email.json) |

+|[Vulnerability assessment should be enabled on SQL Managed Instance](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1b7aa243-30e4-4c9e-bca8-d0d3022b634a) |Audit each SQL Managed Instance which doesn't have recurring vulnerability assessment scans enabled. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities. |AuditIfNotExists, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/VulnerabilityAssessmentOnManagedInstance_Audit.json) |

+|[Vulnerability assessment should be enabled on your SQL servers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fef2a8f2a-b3d9-49cd-a8a8-9a3aaaf647d9) |Audit Azure SQL servers which do not have vulnerability assessment properly configured. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities. |AuditIfNotExists, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/VulnerabilityAssessmentOnServer_Audit.json) |

+## Maintenance, Monitoring, And Analysis Of Audit Logs

+### Maintenance, Monitoring, And Analysis Of Audit Logs-16.1

+|[All flow log resources should be in enabled state](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F27960feb-a23c-4577-8d36-ef8b5f35e0be) |Audit for flow log resources to verify if flow log status is enabled. Enabling flow logs allows to log information about IP traffic flowing. It can be used for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more. |Audit, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Network/NetworkWatcherFlowLog_Enabled_Audit.json) |

+|[Azure Monitor should collect activity logs from all regions](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F41388f1c-2db0-4c25-95b2-35d7f5ccbfa9) |This policy audits the Azure Monitor log profile which does not export activities from all Azure supported regions including global. |AuditIfNotExists, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_CaptureAllRegions.json) |

+|[Flow logs should be configured for every network security group](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc251913d-7d24-4958-af87-478ed3b9ba41) |Audit for network security groups to verify if flow logs are configured. Enabling flow logs allows to log information about IP traffic flowing through network security group. It can be used for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more. |Audit, Disabled |[1.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Network/NetworkSecurityGroup_FlowLog_Audit.json) |

+|[Log duration should be enabled for PostgreSQL database servers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Feb6f77b9-bd53-4e35-a23d-7f65d5f0e8f3) |This policy helps audit any PostgreSQL databases in your environment without log_duration setting enabled. |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/PostgreSQL_EnableLogDuration_Audit.json) |

+|[Network Watcher flow logs should have traffic analytics enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F2f080164-9f4d-497e-9db6-416dc9f7b48a) |Traffic analytics analyzes flow logs to provide insights into traffic flow in your Azure cloud. It can be used to visualize network activity across your Azure subscriptions and identify hot spots, identify security threats, understand traffic flow patterns, pinpoint network misconfigurations and more. |Audit, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Network/NetworkWatcher_FlowLog_TrafficAnalytics_Audit.json) |

+### Maintenance, Monitoring, And Analysis Of Audit Logs-16.2

+|[\[Preview\]: Log Analytics extension should be installed on your Linux Azure Arc machines](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F842c54e8-c2f9-4d79-ae8d-38d8b8019373) |This policy audits Linux Azure Arc machines if the Log Analytics extension is not installed. |AuditIfNotExists, Disabled |[1.0.1-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/Arc_Linux_LogAnalytics_Audit.json) |

+|[\[Preview\]: Log Analytics extension should be installed on your Windows Azure Arc machines](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd69b1763-b96d-40b8-a2d9-ca31e9fd0d3e) |This policy audits Windows Azure Arc machines if the Log Analytics extension is not installed. |AuditIfNotExists, Disabled |[1.0.1-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/Arc_Windows_LogAnalytics_Audit.json) |

+|[Azure Monitor log profile should collect logs for categories 'write,' 'delete,' and 'action'](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1a4e592a-6a6e-44a5-9814-e36264ca96e7) |This policy ensures that a log profile collects logs for categories 'write,' 'delete,' and 'action' |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_CaptureAllCategories.json) |

+|[Azure subscriptions should have a log profile for Activity Log](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F7796937f-307b-4598-941c-67d3a05ebfe7) |This policy ensures if a log profile is enabled for exporting activity logs. It audits if there is no log profile created to export the logs either to a storage account or to an event hub. |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/Logprofile_activityLogs_Audit.json) |

+### Maintenance, Monitoring, And Analysis Of Audit Logs-16.3

+|[\[Preview\]: Network traffic data collection agent should be installed on Linux virtual machines](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F04c4380f-3fae-46e8-96c9-30193528f602) |Security Center uses the Microsoft Dependency agent to collect network traffic data from your Azure virtual machines to enable advanced network protection features such as traffic visualization on the network map, network hardening recommendations and specific network threats. |AuditIfNotExists, Disabled |[1.0.2-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ASC_Dependency_Agent_Audit_Linux.json) |

+|[\[Preview\]: Network traffic data collection agent should be installed on Windows virtual machines](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F2f2ee1de-44aa-4762-b6bd-0893fc3f306d) |Security Center uses the Microsoft Dependency agent to collect network traffic data from your Azure virtual machines to enable advanced network protection features such as traffic visualization on the network map, network hardening recommendations and specific network threats. |AuditIfNotExists, Disabled |[1.0.2-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ASC_Dependency_Agent_Audit_Windows.json) |

+|[Azure Monitor should collect activity logs from all regions](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F41388f1c-2db0-4c25-95b2-35d7f5ccbfa9) |This policy audits the Azure Monitor log profile which does not export activities from all Azure supported regions including global. |AuditIfNotExists, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_CaptureAllRegions.json) |

+|[Resource logs in Key Vault should be enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fcf820ca0-f99e-4f3e-84fb-66e913812d21) |Audit enabling of resource logs. This enables you to recreate activity trails to use for investigation purposes when a security incident occurs or when your network is compromised |AuditIfNotExists, Disabled |[5.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AuditDiagnosticLog_Audit.json) |

+## Metrics

+### Metrics-21.1

+**ID**:

+|Name<br />_{(Azure portal)} |Description |Effect(s) |Version<br />_(GitHub) |

+|||||

+|[Azure AI Services resources should encrypt data at rest with a customer-managed key (CMK)](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F67121cc7-ff39-4ab8-b7e3-95b84dab487d) |Using customer-managed keys to encrypt data at rest provides more control over the key lifecycle, including rotation and management. This is particularly relevant for organizations with related compliance requirements. This is not assessed by default and should only be applied when required by compliance or restrictive policy requirements. If not enabled, the data will be encrypted using platform-managed keys. To implement this, update the 'Effect' parameter in the Security Policy for the applicable scope. |Audit, Deny, Disabled |[2.2.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Cognitive%20Services/CustomerManagedKey_Audit.json) |

+|[Azure Cosmos DB accounts should use customer-managed keys to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1f905d99-2ab7-462c-a6b0-f709acca6c8f) |Use customer-managed keys to manage the encryption at rest of your Azure Cosmos DB. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at [https://aka.ms/cosmosdb-cmk](https://aka.ms/cosmosdb-cmk). |audit, Audit, deny, Deny, disabled, Disabled |[1.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Cosmos%20DB/Cosmos_CMK_Deny.json) |

+|[Azure Defender for Key Vault should be enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0e6763cc-5078-4e64-889d-ff4d9a839047) |Azure Defender for Key Vault provides an additional layer of protection and security intelligence by detecting unusual and potentially harmful attempts to access or exploit key vault accounts. |AuditIfNotExists, Disabled |[1.0.3](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Security%20Center/ASC_EnableAdvancedThreatProtectionOnKeyVaults_Audit.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. Optionally, you can configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](/azure/key-vault/general/network-security) |Audit, Deny, Disabled |[3.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/FirewallEnabled_Audit.json) |

+|[Azure Key Vaults should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fa6abeaec-4d90-4a02-805f-6b26c4d3fbe9) |Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to key vault, you can reduce data leakage risks. Learn more about private links at: [https://aka.ms/akvprivatelink](https://aka.ms/akvprivatelink). |[parameters('audit_effect')] |[1.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Should_Use_PrivateEndpoint_Audit.json) |

+|[Azure Machine Learning workspaces should be encrypted with a customer-managed key](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fba769a63-b8cc-4b2d-abf6-ac33c7204be8) |Manage encryption at rest of Azure Machine Learning workspace data with customer-managed keys. By default, customer data is encrypted with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at [https://aka.ms/azureml-workspaces-cmk](https://aka.ms/azureml-workspaces-cmk). |Audit, Deny, Disabled |[1.0.3](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Machine%20Learning/Workspace_CMKEnabled_Audit.json) |

+|[Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

+|[Container registries should be encrypted with a customer-managed key](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F5b9159ae-1701-4a6f-9a7a-aa9c8ddd0580) |Use customer-managed keys to manage the encryption at rest of the contents of your registries. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. Learn more at [https://aka.ms/acr/CMK](https://aka.ms/acr/CMK). |Audit, Deny, Disabled |[1.1.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_CMKEncryptionEnabled_Audit.json) |

+|[Key vaults should have deletion protection enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0b60c0b2-2dc2-4e1c-b5c9-abbed971de53) |Malicious deletion of a key vault can lead to permanent data loss. You can prevent permanent data loss by enabling purge protection and soft delete. Purge protection protects you from insider attacks by enforcing a mandatory retention period for soft deleted key vaults. No one inside your organization or Microsoft will be able to purge your key vaults during the soft delete retention period. Keep in mind that key vaults created after September 1st 2019 have soft-delete enabled by default. |Audit, Deny, Disabled |[2.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Recoverable_Audit.json) |

+|[Key vaults should have soft delete enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1e66c121-a66a-4b1f-9b83-0fd99bf0fc2d) |Deleting a key vault without soft delete enabled permanently deletes all secrets, keys, and certificates stored in the key vault. Accidental deletion of a key vault can lead to permanent data loss. Soft delete allows you to recover an accidentally deleted key vault for a configurable retention period. |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/SoftDeleteMustBeEnabled_Audit.json) |

+|[MySQL servers should use customer-managed keys to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F83cef61d-dbd1-4b20-a4fc-5fbc7da10833) |Use customer-managed keys to manage the encryption at rest of your MySQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. |AuditIfNotExists, Disabled |[1.0.4](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/MySQL_EnableByok_Audit.json) |

+|[PostgreSQL servers should use customer-managed keys to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F18adea5e-f416-4d0f-8aa8-d24321e3e274) |Use customer-managed keys to manage the encryption at rest of your PostgreSQL servers. By default, the data is encrypted at rest with service-managed keys, but customer-managed keys are commonly required to meet regulatory compliance standards. Customer-managed keys enable the data to be encrypted with an Azure Key Vault key created and owned by you. You have full control and responsibility for the key lifecycle, including rotation and management. |AuditIfNotExists, Disabled |[1.0.4](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/PostgreSQL_EnableByok_Audit.json) |

+|[SQL managed instances should use customer-managed keys to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fac01ad65-10e5-46df-bdd9-6b0cad13e1d2) |Implementing Transparent Data Encryption (TDE) with your own key provides you with increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement. |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/SqlManagedInstance_EnsureServerTDEisEncrypted_Deny.json) |

+|[SQL servers should use customer-managed keys to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a370ff3-6cab-4e85-8995-295fd854c5b8) |Implementing Transparent Data Encryption (TDE) with your own key provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties. This recommendation applies to organizations with a related compliance requirement. |Audit, Deny, Disabled |[2.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/SqlServer_EnsureServerTDEisEncryptedWithYourOwnKey_Deny.json) |

+|[Storage accounts should use customer-managed key for encryption](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F6fac406b-40ca-413b-bf8e-0bf964659c25) |Secure your blob and file storage account with greater flexibility using customer-managed keys. When you specify a customer-managed key, that key is used to protect and control access to the key that encrypts your data. Using customer-managed keys provides additional capabilities to control rotation of the key encryption key or cryptographically erase data. |Audit, Disabled |[1.0.3](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Storage/StorageAccountCustomerManagedKeyEnabled_Audit.json) |

+### Metrics-21.2

+**ID**:

+|Name<br />_{(Azure portal)} |Description |Effect(s) |Version<br />_(GitHub) |

+|||||

+|[Hotpatch should be enabled for Windows Server Azure Edition VMs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F6d02d2f7-e38b-4bdc-96f3-adc0a8726abc) |Minimize reboots and install updates quickly with hotpatch. Learn more at [https://docs.microsoft.com/azure/automanage/automanage-hotpatch](/azure/automanage/automanage-hotpatch) |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Automanage/HotpatchShouldBeEnabledforWindowsServerAzureEditionVMs.json) |

+The FHIR service supports create, conditional create, update, and conditional update as defined by the FHIR specification. One useful header in these scenarios is the [If-Match](https://www.hl7.org/fhir/http.html#concurrency) header. The `If-Match` header is used to validate the version being updated before making the update. If the `ETag` doesnΓÇÖt match the expected `ETag`, it produces the error message *412 Precondition Failed*.

+**Delete can be performed for an individual resource id, or in bulk. To learn more on deleting resources in bulk, visit [$bulk-delete operation](fhir-bulk-delete.md).**

+Delete defined by the FHIR specification requires that after deleting a resource, subsequent nonversion reads of that resource return a 410 HTTP status code. As a result, the resource is no longer found through searching. Additionally, the FHIR service enables you to fully delete the resource (including all history). To fully delete the resource, pass a parameter `true` setting to `hardDelete`: `(DELETE {{FHIR_URL}}/{resource}/{id}?hardDelete=true)`. If you don't pass this parameter or set `hardDelete` to false, the historic versions of the resource are still available.

+ Conditional delete allows you to pass search criteria to delete a resource. By default, the Conditional delete allows you to delete one item at a time. You can also specify the `_count` parameter to delete up to 100 items at a time. Following are some examples of using conditional delete.

+To search with history, use the following interactions.

+* `_count` : defines the number of resources returned on single page.

+* `_since` : includes resource versions created at or after the given instant in time.

+* `_before` : includes resource versions that were created before the given instant in time.

+For more information on history and version management visit [FHIR versioning policy and history management](fhir-versioning-policy-and-history-management.md).

+Patch is a valuable RESTful operation when you need to update only a portion of the FHIR resource. Using patch allows you to specify the element that you want to update in the resource without having to update the entire record. FHIR defines three ways to patch resources: JSON Patch, XML Patch, and FHIRPath Patch. The FHIR service supports JSON Patch and FHIRPath Patch, along with Conditional JSON Patch and Conditional FHIRPath Patch (which allows you to patch a resource based on a search criteria instead of a resource ID).

+For examples, refer to the [FHIRPath Patch REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/FhirPatchRequests.http) and the [JSON Patch REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/JsonPatchRequests.http). For more information, see [HL7 documentation for patch operations with FHIR](https://www.hl7.org/fhir/http.html#patch).

+This method of patch is the most powerful as it uses [FHIRPath](https://hl7.org/fhirpath/) for selecting which element to target. One common scenario is using FHIRPath Patch to update an element in a list without knowing the order of the list. For example, if you want to delete a patientΓÇÖs home telecom information without knowing the index, you can use the following example.

+JSON Patch in the FHIR service conforms to the well-used [specification defined by the Internet Engineering Task Force](https://datatracker.ietf.org/doc/html/rfc6902). The payload format doesn't use FHIR resources and instead uses a JSON document using JSON-Pointers for element selection. JSON Patch is more compact and has a test operation that allows you to validate that a condition is true before doing the patch. For example, if you want to set a patient as deceased only if they're not already marked as deceased, you can use the following example.

+By default, JSON Patch isn't supported in bundle resources because a bundle only supports FHIR resources, and the JSON Patch payload isn't a FHIR resource. To work around this constraint, use binary resources with a content type `"application/json-patch+json"` and the base64 encoding of the JSON payload inside of a bundle. For more information, see the [FHIR Chat Zulip](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Transaction.20with.20PATCH.20request).

+In the following example, we change the gender for the patient to female. We take the JSON Patch `[{"op":"replace","path":"/gender","value":"female"}]` and encoded it to base64.

+Following are examples of Fast Healthcare Interoperability Resources (FHIR&#174;) search API calls featuring various search parameters, modifiers, chained and reverse chained searches, composite searches, `POST` search requests, and more. For a general introduction to FHIR search concepts, see [Overview of FHIR Search](overview-of-search.md).

+`_include` lets you search for resource instances, and include in the results other resources referenced by the target resource instances. For example, you can use `_include` to query for `MedicationRequest` resources and limit the search to prescriptions for a specific patient. The FHIR service would then return the `MedicationRequest` resources and the referenced `Patient` resource. In the following example, the request pulls all `MedicationRequest` resource instances in the database and all patients that referenced by the `MedicationRequest` instances.

+`_revinclude` allows you to search for resource instances, and include in the results other resources that reference the target resource instances. For example, you can search for patients and then reverse include all encounters that reference the patients.

+`_elements` narrows the information in the search results to a subset of the elements defined for a resource type. The `_elements` parameter accepts a comma-separated list of base elements.

+The preceding request returns a bundle of patients. Each entry only includes the identifiers and the patient's active status. The entries in the response contain a `meta.tag` value of `SUBSETTED` to indicate that not all elements defined for the resource are included.

+`:not` allows you to find resources with an element that doesn't have a given value. For example, you could search for patients who aren't female.

+In return, you would get all `Patient` resources whose `gender` element value isn't `female`, including any patients with no gender value specified. This is different from searching for `Patient` resources with the `male` gender value since that would ignore patients with no specified gender.

+`:missing` returns all resources that don't have a value for the specified element when `:missing=true`. Additionally, `:missing` returns all resources that contain the specified element when `:missing=false`. For simple data type elements, `:missing=true` matches on all resources where an element is present but has an empty value. For example, if you want to find all `Patient` resources that are missing information on `birthdate`, you can make the following call.

+This request returns `Patient` resources that have the `given` or `family` name of `Jon`. If there were patients with names such as `Jonathan` or `JON`, the search would ignore those resources as their names don't match the specified value exactly.

+`:contains` is used to query for `string` type elements and allows for matches with the specified value anywhere within the field. `contains` isn't case sensitive, and recognizes matching strings concatenated with other characters. For example:

+This request would return all `Patient` resources with `address` element fields that contain the string "Meadow" (case insensitive). This means you could have addresses with values such as "Meadows Lane," "Pinemeadow Place", or "Meadowlark St" that return positive matches.

+To perform search operations that cover elements contained within a referenced resource, you can "chain" a series of parameters together with `.`. For example, if you want to view all `DiagnosticReport` resources with a `subject` reference to a patient specified by `name`, use the following query.

+This request returns all `DiagnosticReport` resources with a patient subject named "Sarah". The `.` points the chained search to the `name` element within the referenced `Patient` resource.

+Another common use of FHIR search is finding all encounters for a specific patient. To do a regular (non-chained) search for `Encounter` resources that reference a `Patient` with a given `id` use the following.

+Using chained search, you can find all `Encounter` resources that reference patients whose details match a search parameter. The following example demonstrates how to search for encounters referencing patients narrowed by `birthdate`.

+In addition, you can initiate multiple chained searches by using the `&` operator, which allows searching against multiple references in one request. In cases with `&`, chained search "independently" scans for each element value.

+This returns all `Patient` resources that have a reference to "Sarah" as a `generalPractitioner` plus a reference to a `generalPractitioner` that has an address in the state of Washington. In other words, if a patient had a `generalPractitioner` named Sarah from New York state and another `generalPractitioner` named Bill from Washington state, both would meet the conditions for a positive match when doing this search.

+For scenarios in which the search requires a logical AND condition that strictly checks for paired element values, refer to the following **composite search** examples.

+Using reverse chained search in FHIR allows you to search for target resource instances referenced by other resources. In other words, you can search for resources based on the properties of resources that refer to them. This is accomplished with the `_has` parameter. For example, the `Observation` resource has a search parameter `patient` that checks for a reference to a `Patient` resource. To find all `Patient` resources referenced by an `Observation` with a specific `code`, use the following code.

+In addition, reverse chained search can have a recursive structure. For example, if you want to search for all patients referenced by an `Observation` where the observation is referenced by an `AuditEvent` from a specific practitioner named `janedoe`, use:

+To search for resources that contain elements grouped together as logically connected pairs, FHIR defines composite search, which joins single parameter values together with the `$` operator ΓÇô forming a connected pair of parameters. In a composite search, a positive match occurs when the intersection of element values satisfies all conditions set in the paired search parameters. The following example queries for all `DiagnosticReport` resources that contain a potassium value less than `9.2`:

+The maximum number of resources that can be returned at once from a search query is 1000. However, you might have more than 1,000 resource instances that match the search query, and you want to retrieve the next set of results after the first 1,000 entries. In this case, you would use the continuation (that is, `"next"`) token `url` value in the `searchset` bundle returned from the search as follows.

+This returns the next set of entries for your search results. The `searchset` bundle is the complete set of search result entries, and the continuation token `url` is the link provided by the FHIR service to retrieve the entries that don't fit in the first subset (due to the restriction on the maximum number of entries returned for one page).

+All of the search examples mentioned here use `GET` requests. However, you can also make FHIR search API calls using `POST` with the `_search` parameter as follows.

+This request returns the `Patient` resource instance with the given `id` value. As with `GET` requests, the server determines which resource instances satisfy the conditions and returns a bundle in the HTTP response.

+Another feature of searching with `POST` is that it lets you submit the query parameters as a form body.

+To perform status updates on search parameters, follow these steps:

+To get the status across all search parameters, use the following request, which returns a list of all the search parameters and their status. Scroll through the list to find the search parameter you need.

+To identify the status of individual or a subset of search parameters, use the following filters.

+* **Name**. To identify search parameter status by name, use this request.

+* **URL**. To identify search parameter status by its canonical identifier, use this request.

+```

+* **Resource type**. In FHIR, search parameters are enabled at the individual resource level to allow filtering and retrieving of a specific subset of resources. To identify the status of all the search parameters mapped to a resource, use this request.

+In response to the GET request to $status endpoint, the parameters resource type is returned with the status of the search parameter. Here's an example response.

+To update the status of a single search parameter, use the following API request.

+Depending on your use case, you can keep the status state value either ΓÇÿSupportedΓÇÖ or ΓÇÖDisabledΓÇÖ for a search parameter. When you send the state `Disabled` in the request, the response returns as `PendingDisable` because a reindex job must run to fully remove associations.

+If you receive a 400 HTTP status code in the response, it means there's no unique match for the identified search Parameter. Check the search parameter ID.

+> A capability statement document is a set of behaviors for a FHIR server. `Enabled` search parameters are listed in the capability statement for your FHIR service. A capability statement is available for the /metadata endpoint.

+The search parameter in the 'Supported' state needs to be reindexed. Until then, the search parameter isn't activated. If a query is executed on a non-active search parameter, the FHIR service renders a response without considering that search parameter. In the response, there will be a warning message indicating that the search parameter wasn't indexed and not used in the query. To render an error in such situations, use the 'Prefer: handling' header with the value 'strict'. By setting this header, warnings are reported as errors.

+Substitutable Medical Applications and Reusable Technologies ([SMART on FHIR](https://docs.smarthealthit.org/)) is a healthcare standard through which applications can access clinical information through a data store. It adds a security layer based on open standards including OAuth2 and OpenID Connect, to FHIR&reg; interfaces to enable integration with EHR systems. Using SMART on FHIR provides at least three important benefits:

+The following tutorials provide steps to enable SMART on FHIR applications with FHIR Service.

+ - After registering the application, make note of the `applicationId` for client application.

+- Ensure you have access to an Azure Subscription of FHIR service, to create resources and add role assignments.

+Follow the steps listed in section [Manage Users: Assign Users to Role](../../role-based-access-control/role-assignments-portal.yml). Any user added to this role will be able to access the FHIR Service, provided their requests comply with the SMART on FHIR implementation Guide. The access granted to the users in this role will then be limited by the resources associated to their fhirUser compartment and the restrictions in the clinical scopes.

+> SMART on FHIR Implementation Guide defines access to FHIR resource types with scopes. These scopes impact the access an application may have to FHIR resources. A user with the SMART user role has access to perform read API interactions on FHIR service. SMART user role does not grant write access to FHIR service.

+**[Click on this link](https://github.com/Azure-Samples/azure-health-data-and-ai-samples/tree/main/samples/smartonfhir)** to navigate to Azure Health Data and AI Samples open source solution. The steps listed in the document enable integration of FHIR server with other Azure Services (such as APIM, Azure functions and more).

+> Samples are open-source code, and you should review the information and licensing terms on GitHub before using it. They are not part of the Azure Health Data Service and are not supported by Microsoft Support. These samples are used to demonstrate how Azure Health Data Services (AHDS) and other open-source tools can be used together to demonstrate [§170.315(g)(10) Standardized API for patient and population services criterion](https://www.healthit.gov/test-method/standardized-api-patient-and-population-services#ccg) compliance, using Microsoft Entra ID as the identity provider workflow.

+> This is another option to SMART on FHIR(Enhanced) using the AHDS Samples previously mentioned. We suggest you to adopt SMART on FHIR(Enhanced). SMART on FHIR Proxy option is a legacy option.

+> SMART on FHIR(Enhanced) provides added capabilities to SMART on FHIR proxy. SMART on FHIR(Enhanced) meets requirements in [SMART on FHIR Implementation Guide (v 1.0.0)](https://hl7.org/fhir/smart-app-launch/1.0.0/) and [§170.315(g)(10) Standardized API for patient and population services criterion](https://www.healthit.gov/test-method/standardized-api-patient-and-population-services#ccg).

+To use SMART on FHIR, you must first authenticate and authorize the app. The first time you use SMART on FHIR, you must also get administrative consent to let the app access your FHIR resources.

+If you do have administrative privileges, complete the following steps to grant admin consent to yourself directly. (You can also grant admin consent to yourself later when prompted in the app.) You can use these same steps to add other users as owners, so they can view and edit the app registration.

+Because of this two-step relay of the authentication code, you need to set the reply URL (callback) for your Microsoft Entra client application to a URL that is a combination of the reply URL for the SMART on FHIR proxy, and the reply URL for the SMART on FHIR app. The combined reply URL takes the following form.

+In the reply, `aHR0cHM6Ly9sb2NhbGhvc3Q6NTAwMS9zYW1wbGVhcHAvaW5kZXguaHRtbA` is a URL-safe, base64-encoded version of the reply URL for the SMART on FHIR app. For the SMART on FHIR app launcher, when the app is running locally, the reply URL is `https://localhost:5001/sampleapp/https://docsupdatetracker.net/index.html`.

+You can generate the combined reply URL by using a script like the following.

+Add the reply URL to the public client application that you created previously for Microsoft Entra ID.

+To test the FHIR service and the SMART on FHIR proxy, you need to have at least one patient in the database. If you've not used the API yet, and you don't have data in the database, see [Access the FHIR service using Postman](./../fhir/use-postman.md) to load a patient. Make a note of the ID of a specific patient.

+The open-source [FHIR Server for Azure repository](https://github.com/Microsoft/fhir-server) includes a simple SMART on FHIR app launcher and a sample SMART on FHIR app. In this tutorial, use this SMART on FHIR app launcher locally to test the setup.

+You can clone the GitHub repository and go to the application by using the following commands.

+We recommend you use the `dotnet user-secrets` feature:

+Use the following command to run the application:

+After you start the SMART on FHIR app launcher, you can point your browser to `https://localhost:5001`, where you should see the following:

+The SMART on FHIR proxy uses this information to populate fields in the token response. The SMART on FHIR app *can* use these fields to control which patient it requests data for, and how it renders the application on the screen. The SMART on FHIR proxy supports the following fields.

+Notice that the SMART on FHIR app launcher updates the **Launch URL** information at the bottom of the page. Select **Launch** to start the sample app, and you should see something like the following.

+HL7 Fast Healthcare Interoperability Resources (FHIR&#174;) defines a standard and interoperable way to store and exchange healthcare data. Even within the base FHIR specification, it can be helpful to define other rules or extensions based on the context in which FHIR is being used. For context-specific uses of FHIR, **FHIR profiles** are used for the extra layer of specifications. [FHIR profile](https://www.hl7.org/fhir/profiling.html) allows you to narrow down and customize resource definitions using constraints and extensions.

+The Azure Health Data Services FHIR service allows validating resources against profiles to see if the resources conform to the profiles. This article guides you through the basics of FHIR profiles, and how to store them. For more information about FHIR profiles, visit [HL7.org](https://www.hl7.org/fhir/profiling.html).

+A profile sets additional context on the resource that's represented as a `StructureDefinition` resource. A `StructureDefinition` defines a set of rules on the content of a resource or a data type, such as what elements a resource has, and what values these elements can take.

+Following are some examples of how profiles can modify the base resource.

+- `http://hl7.org/fhir/us/core/StructureDefinition/us-core-allergyintolerance` is a US Core profile that sets minimum expectations for the `AllergyIntolerance` resource associated with a patient, and it identifies mandatory fields such as extensions and value sets.

+When a resource conforms to a profile, the profile is specified inside the `profile` element of the resource. You can see in the following example the beginning of a 'Patient' resource, which has http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Patient profile.

+Profiles are also specified by various Implementation Guides (IGs). The following is a list of common IGs. For more information, visit the specific IG site to learn more about the IG and the profiles defined within it.

+This returns the `StructureDefinition` resource for US Core Goal profile that starts as follows.

+FHIR service doesn't return `StructureDefinition` instances for the base profiles, but they can be found easily on the HL7 website, such as the following.

+The `Capability Statement` lists all possible behaviors of your FHIR service. The FHIR service updates the capability statement with details of the stored profiles in the following forms.

+For example, if you `POST` a US Core Patient profile, which starts as follows:

+A `CapabilityStatement` is returned that includes the following information on the US Core Patient profile you uploaded to your FHIR server.

+A terminology service is a set of functions that can perform operations on medical ΓÇ£terminologies,ΓÇ¥ such as validating codes, translating codes, and expanding value sets. The FHIR service doesn't support terminology service. Information for supported operations ($), resource types, and interactions can be found in the service's CapabilityStatement. Resource types ValueSet, StructureDefinition and CodeSystem are supported with basic CRUD operations and Search (as defined in the CapabilityStatement) as well as being leveraged by the system for use in $validate.

+ValueSets can contain a complex set of rules and external references. Presently, the service will only consider the pre-expanded inline codes. Customers need to upload supported ValueSets to the FHIR server prior to utilizing the $validate operation. The ValueSet resources must be uploaded to the FHIR server, using PUT or conditional update as mentioned under Storing Profiles section above.

+In this article, you learned about FHIR profiles. Next, you learn how you can use $validate to ensure that resources conform to these profiles.

+API version 2023-12-01 of the FHIR&reg; service in Azure Health Data Services supports two identity providers in addition to [Microsoft Entra ID](/entra/identity/). To provide scoped access to users, configure the two identity providers by populating the `smartIdentityProviders` section of the `authenticationConfiguration` object.

+Here are the error messages that occur if the FHIR service SMART identity providers fail, with recommended actions to take to resolve the issue.

+| **One or more SMART application `allowedDataActions` values are null or empty.** | The `allowedDataActions` array in one or more application configurations is null or empty. | The only acceptable value in the `allowedDataActions` array is `Read`. |

+5. **Verify the request method is GET**. The only supported request type is `GET`, because the `allowedDataActions` values only support `Read`.

+The `smartIdentityProviders` element is a JSON array that contains one or two `identity provider configurations`. An `identity provider configuration` consists of

+The $member-match operation was created to help with the payer-to-payer data exchange, by allowing a new payer to get a unique identifier for a patient from the patientΓÇÖs previous payer. The $member-match operation requires three pieces of information to be passed in the body of the request.

+After the data is passed in, the FHIR&reg; service in Azure Health Data Services validates that it can find a patient that exactly matches the demographics passed in with the old coverage information. If a result is found, the response is a bundle with the original patient data plus a new identifier added in from the old payer, and the old coverage information.

+To use $member-match, use the following call.

+You need to include a parameters resource in the body that includes the patient, the old coverage, and the new coverage. To see a JSON representation, see [$member-match example request](http://hl7.org/fhir/us/davinci-hrex/2020Sep/Parameters-member-match-in.json.html).

+If a single match is found, you receive a 200 response with another identifier added.

+If the $member-match can't find a unique match, you receive a 422 response with an error code.

+In this article, you learned how to add data to audit logs by using custom headers in the FHIR&reg; service. For information about FHIR service, see

+[Enable diagnostic logging in the de-identification service (preview)](./deidentification/monitor-deidentification-service-reference.md)

+[Private Link](../private-link/index.yml) is a network isolation technique that allows access to Azure services, including Azure Health Data Services. Private Link allows data to flow over private Microsoft networks instead of the public internet. By using Private Link, you can allow access only to specified virtual networks, and lock down access to provisioned services. For more information, see [Configure Private Link](configure-private-link.md).

+### De-identification service (preview)

+- **De-identify documents in Azure Storage**: [Allow trusted services access to Azure Storage accounts](../storage/common/storage-network-security.md)

+When you transition away from Azure Lab Services, DevTest Labs (DTL) is a first party option that can be considered. This document outlines when to and not to consider transitioning to use DevTest Labs. An outline of steps to follow is also included.

+## Scenario guidance

+### What are the target scenarios for DevTest Labs?

+DevTest Labs is targeted at enterprise customers. The primary scenario for which DevTest Labs is designed is the test box scenario, where a professional developer needs temporary access to a virtual machine (VM) that has a prereleased version of the software they need to test. A secondary scenario is professional developer training, when a developer needs temporary access to a VM for internal training.

+- Customer needs access to Linux VMs - DevTest Labs is the only first party service that provides access to Linux. Cloud PC, Azure Virtual Desktop, Microsoft Dev Box don't provide access to native Linux VMs.

+- Customer needs to use an image with nested virtualization - DevTest Labs works well with images that use nested virtualization because it provides a dedicated VM for each student. Nested virtualization isn't well-suited for multi-user session VMs because there's no concept of isolation between user sessions.

+- Technical Computer Programming classes - DevTest Labs resources are available using the Azure portal. Only students comfortable with the Azure portal should use DTL. DTL APIs can be used if you want to create a custom portal to access DTL VMs outside of the Azure portal.

+### When should a customer not use DevTest Labs?

+- Customer requires complex start and stop schedules. DevTest Labs is designed for enterprise developers; it supports daily start and stop schedules.

+- Customer requires flexible login methods. DevTest Labs requires that the user exists in the Microsoft Entra ID tenant for the subscription in which the lab is hosted. RBAC permissions are used to control who has access to labs and VMs.

+## Frequently Asked Questions

+There are no costs for using the service; it's free to use. Customers are charged for resources used by the DevTest Labs service. This cost includes, but isn't limited to, the cost of storage, networking, and running time for any VMs in a lab.

+DevTest Labs is integrated into [Microsoft Cost Management](/azure/cost-management-billing/costs/overview-cost-management) for cost budgeting and analysis. [Allow tag inheritance and add tags to lab resource](/azure/devtest-labs/devtest-lab-configure-cost-management) to track per-lab costs.

+Yes. Check the [VM series](/azure/virtual-machines/sizes/overview) documentation to verify nested virtualization is included in the list of supported features.

+Yes. We recommend [connecting your DevTest Labs to a Shared Image Gallery](/azure/devtest-labs/configure-shared-image-gallery). The Shared Image Gallery can be the same one that is connected to your Azure Lab Services lab account or lab plan.

+We recommend using a Shared Image Gallery over the DTL [custom images feature](/azure/devtest-labs/devtest-lab-create-custom-image-from-vm-using-portal) and [formulas](/azure/devtest-labs/devtest-lab-manage-formulas) features. Shared Image Galleries are compatible with several other Azure services and can be used in multiple labs.

+[Azure Deployment Environments](https://azure.microsoft.com/products/deployment-environments/) is recommended for multi-VM environments.

+DevTest Labs supports an optional daily start and/or stop schedule.

+1. **Claimable VMs** - Optionally, precreate claimable VMs to ensure VMs are created with expected settings. Students can use the 'claim any' command to assign a precreated claimable VM to themselves.

+> [!Important]

+- [Azure Lab Services Retirement Guide](/azure/lab-services/retirement-guide)

+>[!Important]

+> On September 30, 2027, Inbound NAT rules v1 will be retired. If you are currently using Inbound NAT rules v1, make sure to upgrade to Inbound NAT rules v2 prior to the retirement date.

+- A public load balancer in your subscription. For more information on creating an Azure Load Balancer, see [Quickstart: Create a public load balancer to load balance VMs using the Azure portal](quickstart-load-balancer-standard-public-portal.md). The load balancer name for the examples in this article is **myLoadBalancer**.

+## Analyzing Load Balancer Traffic with VNet flow logs

+[Virtual network flow logs](../network-watcher/vnet-flow-logs-overview.md) are a feature of Azure Network Watcher that logs information about IP traffic flowing through a virtual network. Flow data from virtual network flow logs is sent to Azure Storage. From there, you can access the data and export it to any visualization tool, security information and event management (SIEM) solution, or intrusion detection system (IDS).

+For general guidance on creating and managing virtual network flow logs, see [Manage virtual network flow logs](../network-watcher/vnet-flow-logs-portal.md). Once you have created your virtual network flow logs, you can access the data on [Log Analytics workspaces](/azure/azure-monitor/logs/log-analytics-overview) where you can also query and filter the data to identify traffic flowing through your Load Balancer. See [Traffic analytics schema and data aggregation](../network-watcher/traffic-analytics-schema.md) for more details on the virtual network flow logs schema.

+You can also enable [Traffic Analytics](../network-watcher/traffic-analytics.md) when you are creating your virtual network flow logs which provides insights and visualizations on the flow log data such as traffic distribution, traffic pattern, application ports utilized, and top talkers in your virtual network.

+## Log Analytics query for VNet flow logs

+To view logs for inbound flows connected to a specific Load Balancer:

+```Kusto

+NTANetAnalytics

+| where DestLoadBalancer == '<Subscription ID>/<Resource Group name>/<Load Balancer name>'

+```

+1. Use the query above in your Log Analytics workspace and update the string with the valid values for your Load Balancer. To learn more about using Log Analytics, see [Log Analytics tutorial](/azure/azure-monitor/logs/log-analytics-tutorial).

+1. To view the source IP of the connection, either the `SrcIp` or `SrcPublicIps` column will be populated. All traffic originating from public non-malicious or Azure service-owned IP addresses will appear in `SrcPublicIps` and all other source IPs will appear in `SrcIP`. If you want more details on the type of traffic, you can use the `FlowType` column to filter for different types of IP addresses involved in the flow. See [Traffic analytics schema and data aggregation notes](../network-watcher/traffic-analytics-schema.md#notes) for `FlowType` field definitions.

+1. Identify the backend pool instances being used in the inbound connection through any of the following columns: `DestIP`, `MacAddress`, `DestVM`, `TargetResourceID`, `DestNic`.

+1. Through these logs, you can gather further information about the connections going through your Load Balancer such as port information, protocol, and traffic size through packet and byte count sent from destination and source.

+ > [!NOTE]

+ >

+ > In stateless workflows, you can only use [push triggers](../connectors/introduction.md#triggers)

+ > where you don't specify a schedule for running for your workflow. These webhook-based triggers wait for an

+ > event to happen or data to become available. For example, the Recurrence trigger is available only for stateful

+ > workflows. To start your workflow, select a push trigger such as the Request, Event Hubs, or Service Bus trigger.

+ > For more information about limited, unavailable, or unsupported triggers, actions, and connectors, see

+ > [Changed, limited, unavailable, or unsupported capabilities](#limited-unavailable-unsupported).

+ Stateless workflows can use only [*push* triggers](../connectors/introduction.md#triggers) where you don't specify a schedule for running for your workflow. These webhook-based triggers wait for an event to happen or data to become available. For example, the Recurrence trigger is available only for stateful workflows. To start your workflow, select a push trigger such as the Request, Event Hubs, or Service Bus trigger. Although you can enable managed connectors for stateless workflows, the connector gallery doesn't show any managed connector [*polling* triggers](../connectors/introduction.md#triggers) for you to add.

+ >

+The innovative design of the Modeling and Simulation Workbench allows for two-way privacy between collaborating parties. This ensures that the intellectual property of each team remains protected within their own secure chamber, while also facilitating efficient collaboration through shared storage volumes that can be dynamically provisioned and connected to specific chambers.

+[NAT gateway](./nat-overview.md#azure-nat-gateway-basics) supports IPv4 User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) protocols.

+> [!NOTE]

+> ICMP protocol is not supported by NAT Gateway. Ping using ICMP protocol isn't supported and is expected to fail.

+### Can't use public IPs with internet routing preference together with NAT gateway

+When NAT gateway is configured with a public IP address, traffic is routed via the [Microsoft network](/azure/virtual-network/ip-services/routing-preference-overview#routing-via-microsoft-global-network). NAT gateway can't be associated with public IPs with routing preference choice **Internet**. NAT gateway can only be associated with public IPs with routing preference choice **Microsoft Global Network**. See [supported services](/azure/virtual-network/ip-services/routing-preference-overview#supported-services) for a list of all Azure services that do support public IPs with the Internet routing preference.

+- Azure AI Services

+- [Use a domain verification ID when adding custom domains in Azure App Service](../../app-service/app-service-web-tutorial-custom-domain.md#configure-a-custom-domain)

+- Find and enable incident enrichment playbooks for [ReversingLabs](https://www.reversinglabs.com/products/file-reputation-service) in the [Microsoft Sentinel GitHub repository](https://github.com/Azure/Azure-Sentinel/tree/master/Solutions/ReversingLabs/Playbooks/).

+## Next step

+> [Azure Storage samples and developer guides for .NET](../common/storage-samples-dotnet.md?toc=/azure/storage/blobs/toc.json)

+## Next step

+> [Azure Blob Storage developer guides for Go](storage-blob-go-get-started.md#build-your-app)

+## Next step

+> [Azure Storage samples and developer guides for Java](../common/storage-samples-java.md?toc=/azure/storage/blobs/toc.json)

+## Next step

+> [Azure Storage samples and developer guides for JavaScript and TypeScript](../common/storage-samples-javascript.md?toc=/azure/storage/blobs/toc.json)

+## Next step

+> [Azure Storage samples and developer guides for JavaScript and TypeScript](../common/storage-samples-javascript.md?toc=/azure/storage/blobs/toc.json)

+## Next step

+> [Azure Storage samples and developer guides for Python](../common/storage-samples-python.md?toc=/azure/storage/blobs/toc.json)

+`2.0;2022-01-03T20:34:54.4617505Z;PutBlob;SASSuccess;201;7;7;sas;;logsamples;blob;https://logsamples.blob.core.windows.net/container1/1.txt?se=2022-02-02T20:34:54Z&amp;sig=XXXXX&amp;sp=rwl&amp;sr=c&amp;sv=2020-04-08&amp;timeout=901;"/logsamples/container1/1.txt";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0:53371;2019-12-12;654;13;337;0;13;"xxxxxxxxxxxxxxxxxxxxx==";"xxxxxxxxxxxxxxxxxxxxx==";"&quot;0x8D9CEF88004E296&quot;";Monday, 03-Jan-22 20:34:54 GMT;;"Microsoft Azure Storage Explorer, 1.20.1, win32, azcopy-node, 2.0.0, win32, AzCopy/10.11.0 Azure-Storage/0.13 (go1.15; Windows_NT)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;`

+`2.0;2022-01-04T22:50:56.0000775Z;RenamePathFile;Success;201;49;49;authenticated;logsamples;logsamples;blob;"https://logsamples.dfs.core.windows.net/my-container/myfileorig.png?mode=legacy";"/logsamples/my-container/myfilerenamed.png";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0;2020-04-08;591;0;224;0;0;;;;Friday, 11-Jun-21 17:58:15 GMT;;"Microsoft Azure Storage Explorer, 1.19.1, win32 azsdk-js-storagedatalake/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;`

+`2.0;2022-01-03T20:35:04.6097590Z;PeekMessages;Success;200;5;5;authenticated;logsamples;logsamples;queue;https://logsamples.queue.core.windows.net/queue1/messages?numofmessages=32&amp;peekonly=true&amp;timeout=30;"/logsamples/queue1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0:53385;2020-04-08;536;0;232;62;0;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32 azsdk-js-storagequeue/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;`

+`1.0;2022-01-03T20:35:13.0719766Z;CreateTable;Success;204;30;30;authenticated;logsamples;logsamples;table;https://logsamples.table.core.windows.net/Tables;"/logsamples/Table1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;172.16.0.0:53389;2018-03-28;601;22;339;0;22;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32, Azure-Storage/2.10.3 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"`

+Developer guides are collections of articles that provide detailed information and code examples for specific scenarios related to Azure Storage services. To learn more about the Blob Storage developer guides for JavaScript or TypeScript, see the following articles:

+- [Get started with Azure Blob Storage and JavaScript](../blobs/storage-blob-javascript-get-started.md)

+- [Get started with Azure Blob Storage and TypeScript](../blobs/storage-blob-typescript-get-started.md)

+| Authentication/authorization | Authorize access and connect to Blob Storage:</br>[JavaScript](../blobs/storage-blob-javascript-get-started.md#authorize-access-and-connect-to-blob-storage)</br>[TypeScript](../blobs/storage-blob-typescript-get-started.md#authorize-access-and-connect-to-blob-storage)</br></br>[Create a user delegation SAS for a blob](../blobs/storage-blob-create-user-delegation-sas-javascript.md)</br></br>[Create a service SAS for a blob](../blobs/sas-service-create-javascript.md)</br></br>[Create an account SAS](../blobs/storage-blob-account-delegation-sas-create-javascript.md) | Authenticate using Microsoft Entra ID:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/azureAdAuth.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/azureAdAuth.ts)</br></br>Authenticate using shared key credential:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/sharedKeyAuth.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/sharedKeyAuth.ts)</br></br>Authenticate using connection string:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/connectionStringAuth.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/connectionStringAuth.ts) |

+| Create container | Create a container:</br>[JavaScript](../blobs/storage-blob-container-create-javascript.md)</br>[TypeScript](../blobs/storage-blob-container-create-typescript.md) | Create container:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/errorsAndResponses.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/errorsAndResponses.ts) |

+| Upload | Upload a blob:</br>[JavaScript](../blobs/storage-blob-upload-javascript.md)</br>[TypeScript](../blobs/storage-blob-upload-typescript.md) | Upload a blob:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/errorsAndResponses.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/errorsAndResponses.ts)</br></br>Parallel upload a stream to a blob:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/advancedRequestOptions.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/advancedRequestOptions.ts) |

+| Download | Download a blob:</br>[JavaScript](../blobs/storage-blob-download-javascript.md)</br>[TypeScript](../blobs/storage-blob-download-typescript.md) | Download a blob:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/errorsAndResponses.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/errorsAndResponses.ts)</br></br>Parallel download block blob:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/advancedRequestOptions.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/advancedRequestOptions.ts) |

+| List | List containers:</br>[JavaScript](../blobs/storage-blob-containers-list-javascript.md)</br>[TypeScript](../blobs/storage-blob-containers-list-typescript.md)</br></br>List blobs:</br>[JavaScript](../blobs/storage-blobs-list-javascript.md)</br>[TypeScript](../blobs/storage-blobs-list-typescript.md) | List containers:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listContainers.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listContainers.ts)</br></br>List containers using an iterator:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listContainers.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listContainers.ts)</br></br>List containers by page:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listContainers.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listContainers.ts)</br></br>List blobs using an iterator:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listBlobsFlat.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listBlobsFlat.ts)</br></br>List blobs by page:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listBlobsFlat.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listBlobsFlat.ts)</br></br>List blobs by hierarchy:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listBlobsByHierarchy.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listBlobsByHierarchy.ts) |

+| Delete | Delete containers:</br>[JavaScript](../blobs/storage-blob-container-delete-javascript.md)</br>[TypeScript](../blobs/storage-blob-container-delete-typescript.md)</br></br>Delete blobs:</br>[JavaScript](../blobs/storage-blob-delete-javascript.md)</br>[TypeScript](../blobs/storage-blob-delete-typescript.md) | Delete a container:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/errorsAndResponses.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/errorsAndResponses.ts) |

+| Copy | Overview of copy operations:</br>[JavaScript](../blobs/storage-blob-copy-javascript.md)</br>[TypeScript](../blobs/storage-blob-copy-typescript.md)</br></br>Copy a blob from a source object URL:</br>[JavaScript](../blobs/storage-blob-copy-url-javascript.md)</br>[TypeScript](../blobs/storage-blob-copy-url-typescript.md)</br></br>Copy a blob with asynchronous scheduling:</br>[JavaScript](../blobs/storage-blob-copy-async-javascript.md)</br>[TypeScript](../blobs/storage-blob-copy-async-typescript.md) | |

+| Lease | Create and manage container leases:</br>[JavaScript](../blobs/storage-blob-container-lease-javascript.md)</br>[TypeScript](../blobs/storage-blob-container-lease-typescript.md)</br></br>Create and manage blob leases:</br>[JavaScript](../blobs/storage-blob-lease-javascript.md)</br>[TypeScript](../blobs/storage-blob-lease-typescript.md) | |

+| Properties and metadata | Manage container properties and metadata:</br>[JavaScript](../blobs/storage-blob-container-properties-metadata-javascript.md)</br>[TypeScript](../blobs/storage-blob-container-properties-metadata-typescript.md)</br></br>Manage blob properties and metadata:</br>[JavaScript](../blobs/storage-blob-properties-metadata-javascript.md)</br>[TypeScript](../blobs/storage-blob-properties-metadata-typescript.md) | |

+| Index tags | Use blob index tags to manage and find data:</br>[JavaScript](../blobs/storage-blob-tags-javascript.md)</br>[TypeScript](../blobs/storage-blob-tags-typescript.md) | |

+| Access tiers | Set or change a block blob's access tier:</br>[JavaScript](../blobs/storage-blob-use-access-tier-javascript.md)</br>[TypeScript](../blobs/storage-blob-use-access-tier-typescript.md) | Set the access tier on a blob:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/advancedRequestOptions.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/advancedRequestOptions.ts) |

+| Blob service | | Create a blob service client:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/listContainers.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/listContainers.ts)</br></br>Create blob service client using a SAS URL:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/advancedRequestOptions.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/advancedRequestOptions.ts) |

+| Snapshot | | Create a blob snapshot:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/snapshots.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/snapshots.ts)</br></br>Download a blob snapshot:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/snapshots.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/snapshots.ts) |

+| Troubleshooting | | Trigger a recoverable error using a container client:</br>[JavaScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/javascript/errorsAndResponses.js)</br>[TypeScript](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-blob/samples/v12/typescript/src/errorsAndResponses.ts) |

+| [Root squash](nfs-root-squash.md)| ✔️ |

+ Title: Configure root squash settings for NFS Azure file shares

+description: Root squash is a security feature that prevents unauthorized root-level access to the NFS server by client machines. Learn how to configure root squash for NFS Azure file shares.

+# Configure root squash for Azure Files

+Permissions for NFS file shares are enforced by the client OS rather than the Azure Files service. Root squash is an administrative security feature in NFS that prevents unauthorized root-level access to the NFS server by client machines. This functionality is an important part of protecting user data and system settings from manipulation by untrusted or compromised clients.

+Administrators should enable root squash in environments where multiple users or systems access the NFS share, especially in scenarios where client machines aren't fully trusted. By converting root users to anonymous users, root squash ensures that even if a client machine is compromised, the attacker can't exploit root privileges to access or modify critical files on the NFS server.

+In this article, you learn how to configure and change root squash settings for NFS Azure file shares.

+## Applies to

+| File share type | SMB | NFS |

+|-|:-:|:-:|

+| Standard file shares (GPv2), LRS/ZRS |  |  |

+| Standard file shares (GPv2), GRS/GZRS |  |  |

+| Premium file shares (FileStorage), LRS/ZRS |  |  |

+## How root squash works with Azure Files

+Root squash works by re-mapping the user ID (UID) and the group ID (GID) of the root user to a UID and GID belonging to the anonymous user on server. Root users accessing the file system are automatically converted to the anonymous, less-privileged user/group with limited permissions.

+Although root squash is the default behavior in NFS, it's not the default option when creating an NFS Azure file share. You must explicitly enable root squash on the file share. You can do this when you create an NFS Azure file share, or later on.

+## Root squash settings

+You can choose from three root squash settings:

+- **No root squash:** Turn off root squashing. This option is mainly useful for diskless clients or workloads as specified by workload documentation. This is the default setting when creating a new NFS Azure file share.

+- **All squash:** Map all UIDs and GIDs to the anonymous user. Useful for shares that require read-only access by all clients.

+- **Root squash:** Map requests from UID/GID 0 (root) to the anonymous UID/GID. This doesn't apply to any other UIDs or GIDs that might be equally sensitive, such as user bin or group staff.

+The following table highlights the UID behavior observed from the server when specific root squash options are configured.

+| **Option** | **Client UID** | **Server UID** |

+||-|-|

+| root_squash | 0 | 65534 |

+| root_squash | 1000 | 1000 |

+| no_root_squash | 0 | 0 |

+| no_root_squash | 1000 | 1000 |

+| all_squash | 0 | 65534 |

+| all_squash | 1000 | 65534 |

+## Configure root squash on an existing NFS file share

+You can configure root squash settings via the Azure portal, Azure PowerShell, or Azure CLI.

+# [Portal](#tab/azure-portal)

+1. Sign in to the Azure portal and navigate to the FileStorage storage account containing the NFS Azure file share.

+1. In the service menu, under **Data storage**, select **File shares**.

+1. Select the file share for which you want to modify the root squash setting.

+1. In the service menu, select **Properties**. Then toggle the **Root squash** setting as desired.

+ :::image type="content" source="media/nfs-root-squash/toggle-root-squash.png" alt-text="Screenshot showing how to configure root squash settings for an NFS file share in the Azure portal." lightbox="media/nfs-root-squash/toggle-root-squash.png":::

+1. Select **Save** to update the root squash value.

+# [Azure PowerShell](#tab/azure-powershell)

+1. Sign in to Azure and select your subscription.

+ ```azurepowershell-interactive

+ Connect-AzAccount

+ Select-AzSubscription -SubscriptionId "<your-subscription-id>"

+ ```

+1. To enable root squash on the file share, run the following command. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurepowershell-interactive

+ Update-AzRmStorageShare `

+ -ResourceGroupName <resource-group-name> `

+ -StorageAccountName <storage-account-name> `

+ -Name <file-share-name> `

+ -RootSquash RootSquash

+ ```

+1. To disable root squash on the file share, run the following command. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurepowershell-interactive

+ Update-AzRmStorageShare `

+ -ResourceGroupName <resource-group-name> `

+ -StorageAccountName <storage-account-name> `

+ -Name <file-share-name> `

+ -RootSquash NoRootSquash

+ ```

+1. To force squash for all users, run the following command to map all user IDs to anonymous. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurepowershell-interactive

+ Update-AzRmStorageShare `

+ -ResourceGroupName <resource-group-name> `

+ -StorageAccountName <storage-account-name> `

+ -Name <file-share-name> `

+ -RootSquash AllSquash

+ ```

+1. To view the root squash property for a file share, run the following command. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurepowershell-interactive

+ Get-AzRmStorageShare `

+ -ResourceGroupName <resource-group-name> `

+ -StorageAccountName <storage-account-name> `

+ -Name <file-share-name> | fl -Property ResourceGroupName, StorageAccountName, Name, QuotaGiB,AccessTier,EnabledProtocols,RootSquash

+ ```

+# [Azure CLI](#tab/azure-cli)

+1. Sign in to Azure and set your subscription.

+ ```azurecli-interactive

+ az login

+ az account set --subscription "<your-subscription-id>"

+ ```

+1. To enable root squash on the file share, run the following command. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurecli-interactive

+ az storage share-rm update \

+ --resource-group <resource-group-name> \

+ --storage-account <storage-account-name> \

+ --name <file-share-name> \

+ --root-squash RootSquash

+ ```

+1. To disable root squash on the file share, run the following command. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurecli-interactive

+ az storage share-rm update \

+ --resource-group <resource-group-name> \

+ --storage-account <storage-account-name> \

+ --name <file-share-name> \

+ --root-squash NoRootSquash

+ ```

+1. To force squash for all users, run the following command to map all user IDs to anonymous. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurecli-interactive

+ az storage share-rm update \

+ --resource-group <resource-group-name> \

+ --storage-account <storage-account-name> \

+ --name <file-share-name> \

+ --root-squash AllSquash

+ ```

+1. To view the root squash property for a file share, run the following command. Replace `<resouce-group-name>`, `<storage-account-name>`, and `<file-share-name>` with your own values.

+ ```azurecli-interactive

+ az storage share-rm show \

+ --resource-group <resource-group-name> \

+ --storage-account <storage-account-name> \

+ --name <file-share-name>

+ ```

+## See also

+- [NFS Azure file shares](files-nfs-protocol.md)

+Synapse access control can be simplified by aligning roles and personas in your organization with security groups. This enables you to manage access to security groups simply by adding and removing users.

+| **Container** | `container1` | The container in storage1 that the workspace will use by default. |

+| **Microsoft Entra ID tenant** | `contoso` | The Microsoft Entra ID tenant name.|

+|**Service principal**|`SERVICEPRINCIPAL`| A [service principal](/entra/identity-platform/howto-create-service-principal-portal#register-an-application-with-microsoft-entra-id-and-create-a-service-principal) in your Microsoft Entra ID tenant.|

+>[!TIP]

+>You're encourage to use granular options to control access to your workspace, granting developers access to individual resources, rather than an entire workspace. [Learn more](./synapse-workspace-synapse-rbac.md) about Synapse RBAC.

+- **`workspace1_SynapseAdministrators`**, for users who need complete control over a workspace. Add yourself to this security group, at least initially.

+You'll assign Synapse roles to these groups at the workspace scope shortly.

+>- Learn how to create a security group in this article: [Create a basic group and add members using Microsoft Entra ID](../../active-directory/fundamentals/active-directory-groups-create-azure-portal.md#create-a-basic-group-and-add-members).

+>- Learn how to add a security group from another security group in this article: [Add or remove a group from another group using Microsoft Entra ID](../../active-directory/fundamentals/active-directory-groups-membership-azure-portal.md#add-a-group-to-another-group).

+ | Assign access to |`SERVICEPRINCIPAL` |

+- Open `workspace1` in Synapse Studio

+To run pipelines and perform system tasks, Azure Synapse requires managed service identity (MSI) to have access to `container1` in the default ADLS Gen2 account, for the workspace. For more information, see [Azure Synapse workspace managed identity](../synapse-service-identity.md).

+To create SQL pools, Apache Spark pools, and Integration runtimes, users need an Azure Contributor role for the workspace, at minimum. A Contributor role also allows users to manage resources, including pausing and scaling. To use Azure portal or Synapse Studio to create SQL pools, Apache Spark pools, and Integration runtimes, you need a Contributor role at the resource group level.

+ | Role | Contributor (Listed under 'Privileged administrator roles')|

+ | Assign access to | `SERVICEPRINCIPAL` |

+The *workspace creator* is automatically assigned as *SQL Active Directory Admin* for the workspace. Only a single user or a group can be granted this role. In this step, you assign the SQL Active Directory Admin for the workspace to the `workspace1_SQLAdmins` security group. This gives the group highly privileged admin access to all SQL pools and databases in the workspace.

+>Step 6 is optional. You might choose to grant the `workspace1_SQLAdmins` group a less privileged role. To assign `db_owner` or other SQL roles, you must run scripts on each SQL database.

+Access to SQL pools for other users is controlled by SQL permissions. Assigning SQL permissions requires SQL scripts to be run on each SQL database post-creation. The following are examples that require you to run these scripts:

+1. To grant access to a dedicated SQL pool database, scripts can be run by the workspace creator or any member of the `workspace1_SynapseAdministrators` group.

+>You can grant access to all SQL databases by taking the following steps for **each** SQL pool. Section [Configure Workspace-scoped permissions](#configure-workspace-scoped-permissions) is an exception to the rule and it allows you to assign a user a sysadmin role at the workspace level.

+- Alternatively, you can connect to your workspace using a [managed private endpoint](synapse-workspace-managed-private-endpoints.md) and [private Link](/azure/azure-sql/database/private-endpoint-overview). Azure Synapse workspaces without the [Azure Synapse Analytics Managed Virtual Network](synapse-workspace-managed-vnet.md) don't have the ability to connect via managed private endpoints.

+This guide has focused on setting up a basic access control system. You can support more advanced scenarios by creating other security groups and assigning these groups more granular roles at more specific scopes. Consider the following cases:

+**Enable Git-support** for the workspace for more advanced development scenarios including CI/CD. While in Git mode, Git permissions and Synapse RBAC will determine whether a user can commit changes to their working branch. Publishing to the service only takes place from the collaboration branch. Consider creating a security group for developers who need to develop and debug updates in a working branch but don't need to publish changes to the live service.

+**Restrict developer access** to specific resources. Create other finer-grained security groups for developers who need access only to specific resources. Assign these groups appropriate Azure Synapse roles that are scoped to specific Spark pools, Integration runtimes, or credentials.

+**Restrict operators from accessing code artifacts**. Create security groups for operators who need to monitor operational status of Synapse compute resources and view logs but who don't need access to code or to publish updates to the service. Assign these groups the Compute Operator role scoped to specific Spark pools and Integration runtimes.

+**Disable local authentication**. By allowing only Microsoft Entra authentication, you can centrally manage access to Azure Synapse resources, such as SQL pools. Local authentication for all resources within the workspace can be disabled during or after workspace creation. For more information on Microsoft Entra-only authentication, see [Disabling local authentication in Azure Synapse Analytics](../sql/active-directory-authentication.md#disable-local-authentication).

+There's no charge for resources reserved. You are only being charged for the data processed by queries you run, hence this model is a true pay-per-use model.

+If you use Apache Spark for Azure Synapse in your data pipeline, for data preparation, cleansing or enrichment, you can [query external Spark tables](develop-storage-files-spark-tables.md) you've created in the process, directly from serverless SQL pool. Use [Private Link](../security/how-to-connect-to-workspace-with-private-links.md) to bring your serverless SQL pool endpoint into your [managed workspace virtual network](../security/synapse-workspace-managed-vnet.md).

+If you need to explore data in the data lake, gain insights from it or optimize your existing data transformation pipeline, you can benefit from using serverless SQL pool. It's suitable for the following scenarios:

+Serverless SQL pool endpoint is provided within every Azure Synapse workspace. You can create a workspace and start querying data instantly using tools you're familiar with.

+Make sure that you're applying [the best practices](best-practices-serverless-sql-pool.md) to get the best performance.

+### Microsoft Entra integration and multifactor authentication

+Serverless SQL pool enables you to centrally manage identities of database user and other Microsoft services with [Microsoft Entra integration](/azure/azure-sql/database/authentication-aad-configure). This capability simplifies permission management and enhances security. Microsoft Entra ID supports [multifactor authentication](/azure/azure-sql/database/authentication-mfa-ssms-configure) (MFA) to increase data and application security while supporting a single sign-on process.

+ This authentication method uses identities managed by Microsoft Entra ID. For Microsoft Entra users, multifactor authentication can be enabled. Use Active Directory authentication (integrated security) [whenever possible](/sql/relational-databases/security/choose-an-authentication-mode?view=azure-sqldw-latest&preserve-view=true).

+A user that is logged into the serverless SQL pool service must be authorized to access and query the files in Azure Storage. Serverless SQL pool supports the following authorization types:

+# [Windows IoT Enterprise on Arc enabled servers (preview)](#tab/winio-arc)

+### Support for Windows IoT Enterprise on Arc enabled servers

+Public preview: Azure Update Manager now supports Windows IoT Enterprise on Arc enabled servers. For more information, see [supported Windows IoT enterprise releases](/azure/update-manager/support-matrix?tabs=winio-arc%2Cpublic%2Cthird-party-win#support-for-check-for-updatesone-time-updateperiodic-assessment-and-scheduled-patching).

+# Use Microsoft OneDrive with a RemoteApp in Azure Virtual Desktop

+You can use Microsoft OneDrive alongside a RemoteApp in Azure Virtual Desktop, allowing users to access and synchronize their files while using a RemoteApp. When a user connects to a RemoteApp, OneDrive can automatically launch as a companion to the RemoteApp. This article describes how to configure OneDrive to automatically launch alongside a RemoteApp in Azure Virtual Desktop.

+> You can't use the setting **Start OneDrive automatically when I sign in to Windows** in the OneDrive preferences, which starts OneDrive when a user signs in. Instead, you need to configure OneDrive to launch by configuring a registry value, which is described in this article.

+- Session hosts in a host pool that:

+ - Are running Windows 11, version 23H2 with cumulative and noncumulative updates for Windows 11 ([KB5039302](https://support.microsoft.com/en-us/topic/june-25-2024-kb5039302-os-builds-22621-3810-and-22631-3810-preview-0ab34e3f-bca9-4a52-a1a4-404bf8162f58)) or later installed.

+

+ - Have the latest version of FSLogix installed. For more information, see [Install FSLogix applications](/fslogix/how-to-install-fslogix).

+1. On your session hosts:

+ 1. Install the latest Windows Update (ensure that [KB Article 5039302](https://support.microsoft.com/en-us/topic/june-25-2024-kb5039302-os-builds-22621-3810-and-22631-3810-preview-0ab34e3f-bca9-4a52-a1a4-404bf8162f58) is included) on the session host.

+ 2. Set the following policy:

+

+ Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Enable enhanced shell experience for RemoteApp

+ 3. Set the following registry value:

+ - **Key**: `HKLM\Software\Microsoft\Windows\CurrentVersion\Run`

+ - **Type**: `REG_SZ`

+ - **Name**: `OneDrive`

+ - **Data**: `"C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background`

+ You can configure the registry using an enterprise deployment tool such as Intune, Configuration Manager, or Group Policy. Alternatively, to set this registry value using PowerShell, open PowerShell as an administrator and run the following command:

+

+ ```powershell

+ New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name OneDrive -PropertyType String -Value '"C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background' -Force

+ ```

+

+ 4. Ensure the Stack on the session host is version 2404.16770 or higher.

+ 5. Reboot your session host.

+### Utilize the Private Subnet parameter (public preview)

+> [!IMPORTANT]

+> Private Subnets are currently in public preview.

+> This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.

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

+* Routing intent is the only mechanism in Virtual WAN to enable inter-hub traffic inspection via security appliances deployed in the hub. Inter-hub traffic inspection also requires routing intent to be enabled on all hubs to ensure traffic is routed symmetrically between security appliances deployed in Virtual WAN hubs.

+* Routing intent sends Virtual Network and on-premises traffic to the next hop resource specified in the routing policy. Virtual WAN programs the underlying Azure platform to route your on-premises and Virtual Network traffic in accordance with the configured routing policy and does not process the traffic through the Virtual Hub router. Because packets routed via routing intent are not processed by the router, you do not need to allocate additional [routing infrastructure units](hub-settings.md#capacity) for data-plane packet forwarding on hubs configured with routing intent. However, you may need to allocate additional routing infastructure units based on the number of Virtual Machines in Virtual Networks connected to the Virtual WAN Hub.