-6. Search for a user by first name, last name, display name, user principal name, or email address. Alternatively, you can search for a group and pick up to 5 users.

-The on-demand provisioning process attempts to show the steps that the provisioning service takes when provisioning a user. There are typically five steps to provision a user. One or more of those steps, explained in the following sections, will be shown during the on-demand provisioning experience.

-* Make sure that you've defined a valid scoping role. For example, avoid using the [Greater_Than operator](./define-conditional-rules-for-provisioning-user-accounts.md#create-a-scoping-filter) with a non-integer value.

-The **View details** page shows the properties of the users that were matched in the target system. The properties that you see in the context pane vary as follows:

-* If no users are matched in the target system, you won't see any properties.

-* If there's one user matched in the target system, you'll see the properties of that matched user from the target system.

-* If multiple users are matched, you'll see the properties of both matched users.

-* On-demand provisioning says the group or user can't be provisioned because they're not assigned to the application. Note that there's a replicate delay of up to a few minutes between when an object is assigned to an application and that assignment being honored by on-demand provisioning. You may need to wait a few minutes and try again.

-* **Do you need to turn provisioning off to use on-demand provisioning?** For applications that use a long-lived bearer token or a user name and password for authorization, no additional steps are required. Applications that use OAuth for authorization currently require the provisioning job to be stopped before using on-demand provisioning. Applications such as G Suite, Box, Workplace by Facebook, and Slack fall into this category. Work is in progress to support on-demand provisioning for all applications without having to stop provisioning jobs.

-* On-demand provisioning of groups supports updating up to 5 members at a time

-* Restoring a previously soft-deleted user in the target tenant with on-demand provisioning isn't supported. If you try to soft delete a user with on-demand provisioning and then restore the user, it can result in duplicate users.

-* On-demand provisioning supports disabling users that have been unassigned from the application. However, it doesn't support disabling or deleting users that have been disabled or deleted from Azure AD. Those users won't appear when you search for a user.

-* On-demand provisioning does not support nested groups that are not directly assigned to the application.

-description: Learn how to override the default behavior of de-provisioning out of scope users in Azure Active Directory.

-* If ***SkipOutOfScopeDeletions*** is set to 0 (false), accounts that go out of scope will be disabled in the target.

-* If ***SkipOutOfScopeDeletions*** is set to 1 (true), accounts that go out of scope won't be disabled in the target. This flag is set at the *Provisioning App* level and can be configured using the Graph API.

-Because this configuration is widely used with the *Workday to Active Directory user provisioning* app, the following steps include screenshots of the Workday application. However, the configuration can also be used with *all other apps*, such as ServiceNow, Salesforce, and Dropbox and [cross-tenant synchronization](../multi-tenant-organizations/cross-tenant-synchronization-configure.md). Note that in order to successfully complete this procedure you must have first set up app provisioning for the app. Each app has its own configuration article. For example, to configure the Workday application, see [Tutorial: Configure Workday to Azure AD user provisioning](../saas-apps/workday-inbound-cloud-only-tutorial.md).

-1. Launch the [Azure portal](https://portal.azure.com), and navigate to the Properties section of your provisioning application. For e.g. if you want to export your *Workday to AD User Provisioning application* mapping navigate to the Properties section of that app.

-1. In the Properties section of your provisioning app, copy the GUID value associated with the *Object ID* field. This value is also called the **ServicePrincipalId** of your App and it will be used in Graph Explorer operations.

-1. Upon successful sign-in, you'll see the user account details in the left-hand pane.

-Copy the Response into a text file. It will look like the JSON text shown below, with values highlighted in yellow specific to your deployment. Add the lines highlighted in green to the end and update the Workday connection password highlighted in blue.

-In the Graph Explorer, run the command below to update the secrets endpoint with the ***SkipOutOfScopeDeletions*** flag.

-In the URL below replace [servicePrincipalId] with the **ServicePrincipalId** extracted from the [Step 1](#step-1-retrieve-your-provisioning-app-service-principal-id-object-id).

-You can test this flag results in expected behavior by updating your scoping rules to skip a specific user. In the example below, we're excluding the employee with ID 21173 (who was earlier in scope) by adding a new scoping rule:

-In the next provisioning cycle, the Azure AD provisioning service will identify that the user 21173 has gone out of scope and if the SkipOutOfScopeDeletions property is enabled, then the synchronization rule for that user will display a message as shown below:

-Before combined registration, users registered authentication methods for Azure AD Multi-Factor Authentication and self-service password reset (SSPR) separately. People were confused that similar methods were used for multifactor authentication and SSPR but they had to register for both features. Now, with combined registration, users can register once and get the benefits of both multifactor authentication and SSPR. We recommend this video on [How to enable and configure SSPR in Azure AD](https://www.youtube.com/watch?v=rA8TvhNcCvQ)

-> <b>Alternate phone</b> can only be registered in *manage mode* on the [Security info](https://mysignins.microsoft.com/security-info) page and requires Voice calls to be enabled in the Authentication methods policy. <br />

-> <b>Office phone</b> can only be registered in *Interrupt mode* if the users *Business phone* property has been set. Office phone can be added by users in *Managed mode from the [Security info](https://mysignins.microsoft.com/security-info)* without this requirement. <br />

-> <b>App passwords</b> are available only to users who have been enforced for per-user MFA. App passwords aren't available to users who are enabled for Azure AD Multi-Factor Authentication by a Conditional Access policy. <br />

-> <b>FIDO2 security keys</b>, can only be added in *manage mode only* on the [Security info](https://mysignins.microsoft.com/security-info) page.

-When self-service password reset (SSPR) is used to change or reset a password in Azure AD, the password policy is checked. If the password doesn't meet the policy requirements, the user is prompted to try again. Azure administrators have some restrictions on using SSPR that are different to regular user accounts.

-This article describes the password policy settings and complexity requirements associated with user accounts in your Azure AD tenant, and how you can use PowerShell to check or set password expiration settings.

-Every account that signs in to Azure AD must have a unique user principal name (UPN) attribute value associated with their account. In hybrid environments with an on-premises Active Directory Domain Services (AD DS) environment synchronized to Azure AD using Azure AD Connect, by default the Azure AD UPN is set to the on-prem UPN.

-By default, an account is locked out after 10 unsuccessful sign-in attempts with the wrong password. The user is locked out for one minute. Further incorrect sign-in attempts lock out the user for increasing durations of time. [Smart lockout](howto-password-smart-lockout.md) tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior will not cause the account to lock out. You can define the smart lockout threshold and duration.

-| Password restrictions |A minimum of 8 characters and a maximum of 256 characters.<br>Requires three out of four of the following:<br>- Lowercase characters<br>- Uppercase characters<br>- Numbers (0-9)<br>- Symbols (see the previous password restrictions) |

-With a two-gate policy, administrators don't have the ability to use security questions.

-The two-gate policy requires two pieces of authentication data, such as an email address, authenticator app, or a phone number. A two-gate policy applies in the following circumstances:

-A *global administrator* or *user administrator* can use the [Microsoft Azure AD Module for Windows PowerShell](/powershell/module/Azuread/) to set user passwords not to expire.

-1. Open a PowerShell prompt and [connect to your Azure AD tenant](/powershell/module/azuread/connect-azuread#examples) using a *global administrator* or *user administrator* account.

-1. Open a PowerShell prompt and [connect to your Azure AD tenant](/powershell/module/azuread/connect-azuread#examples) using a *global administrator* or *user administrator* account.

-1. Open a PowerShell prompt and [connect to your Azure AD tenant](/powershell/module/azuread/connect-azuread#examples) using a *global administrator* or *user administrator* account.

-1. To make sure that the changes have taken effect, run `Test-AzureADPasswordProtectionDCAgentHealth -TestAll`. For help resolving errors, see [Troubleshoot: On-premises Azure AD Password Protection](howto-password-ban-bad-on-premises-troubleshoot.md).

-1. To make sure that the changes have taken effect, run `Test-AzureADPasswordProtectionDCAgentHealth -TestAll`. For help resolving errors, see [Troubleshoot: On-premises Azure AD Password Protection](howto-password-ban-bad-on-premises-troubleshoot.md).

-The SSO through authentication broker isn't available on macOS.

-Microsoft provides apps called brokers, that enable SSO between applications from different vendors as long as the mobile device is registered with Azure Active Directory (Azure AD). This type of SSO requires a broker application be installed on the user's device.

-MSAL Objective-C supports migration and SSO with ADAL Objective-C-based apps. The apps must be distributed by the same Apple Developer.

-> 1. Unzip the sample, `cd` into the folder that contains `package.json`, then run the following commands:

-> 1. Unzip the sample, `cd` into the folder that contains `package.json`, then run the following commands:

-> 1. Unzip the sample, `cd` into the app root folder, then run the following commands:

-> cd App && npm install && npm start

-> 1. Make sure you've installed Make sure you've installed [.NET SDK v7](https://dotnet.microsoft.com/download/dotnet/7.0) or later.

-> 1. Unzip the sample, `cd` into the app root folder, then run the following command:

-> 1. Unzip the sample, `cd` into the folder that contains `package.json`, then run the following commands:

->This information last updated on April 20th, 2023.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).

-| Microsoft Teams Premium | Microsoft_Teams_Premium | 989a1621-93bc-4be0-835c-fe30171d6463 | MICROSOFT_ECDN (85704d55-2e73-47ee-93b4-4b8ea14db92b)<br/>TEAMSPRO_MGMT (0504111f-feb8-4a3c-992a-70280f9a2869)<br/>TEAMSPRO_CUST (cc8c0802-a325-43df-8cba-995d0c6cb373)<br/>TEAMSPRO_PROTECTION (f8b44f54-18bb-46a3-9658-44ab58712968)<br/>TEAMSPRO_VIRTUALAPPT (9104f592-f2a7-4f77-904c-ca5a5715883f)<br/>MCO_VIRTUAL_APPT (711413d0-b36e-4cd4-93db-0a50a4ab7ea3)<br/>TEAMSPRO_WEBINAR (78b58230-ec7e-4309-913c-93a45cc4735b) | Microsoft eCDN (85704d55-2e73-47ee-93b4-4b8ea14db92b)<br/>Microsoft Teams Premium Intelligent (0504111f-feb8-4a3c-992a-70280f9a2869)<br/>Microsoft Teams Premium Personalized (cc8c0802-a325-43df-8cba-995d0c6cb373)<br/>Microsoft Teams Premium Secure (f8b44f54-18bb-46a3-9658-44ab58712968)<br/>Microsoft Teams Premium Virtual Appointment (9104f592-f2a7-4f77-904c-ca5a5715883f)<br/>Microsoft Teams Premium Virtual Appointments (711413d0-b36e-4cd4-93db-0a50a4ab7ea3)<br/>Microsoft Teams Premium Webinar (78b58230-ec7e-4309-913c-93a45cc4735b) |

-This property indicates the userΓÇÖs primary identity provider. A user can have several identity providers, which can be viewed by selecting the link next to **Identities** in the userΓÇÖs profile or by querying the `onPremisesSyncEnabled` property via the Microsoft Graph API.

-In this tutorial, learn how to integrate Azure Active Directory

-(Azure AD) with Cloudflare Zero Trust. Using this solution, you can build rules based on user identity and group membership. Users can authenticate with their Azure AD credentials and connect to Zero Trust protected applications.

-To get started, you need:

- - If you don't have one, you can get an [Azure free account](https://azure.microsoft.com/free/).

- - See, [Quickstart: Create a new tenant in Azure Active Directory](../fundamentals/active-directory-access-create-new-tenant.md).

- - If you don't have one, go to [Get started with Cloudflare's Zero Trust

- platform](https://dash.cloudflare.com/sign-up/teams)

-Cloudflare Zero Trust Access helps enforce default-deny, Zero Trust

-rules that limit access to corporate applications, private IP spaces,

-and hostnames. This feature connects users faster and safer than a virtual private network (VPN).

-Organizations can use multiple Identity Providers (IdPs) simultaneously, reducing friction when working with partners

-or contractors.

-To add an IdP as a sign-in method, configure [Cloudflare Zero Trust

-dashboard](https://dash.teams.cloudflare.com/) and Azure

-AD.

-The following architecture diagram shows the implementation.

-

-To integrate Cloudflare Zero Trust account with an instance of Azure AD:

-1. On the [Cloudflare Zero Trust

- dashboard](https://dash.teams.cloudflare.com/),

- navigate to **Settings > Authentication**.

-2. For **Login methods**, select **Add new**.

- 

-3. Under **Select an identity provider**, select **Azure AD.**

- 

-4. The **Add Azure ID** dialog appears. Enter credentials from your Azure AD instance and make necessary selections.

- 

-5. Select **Save**.

-4. Select the **+ New registration tab**.

-5. Name your application and enter your [team

- domain](https://developers.cloudflare.com/cloudflare-one/glossary#team-domain), with **callback** at the end of the path: /cdn-cgi/access/callback.

- For example, `https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback`

-6. Select **Register**.

- 

-1. On the **Cloudflare Access** screen, under **Essentials**, copy and save the Application (client) ID and the Directory (tenant) ID.

- [  ](./media/cloudflare-azure-ad-integration/cloudflare-access.png#lightbox)

-2. In the left menu, under **Manage**, select **Certificates &

- secrets**.

- 

-3. Under **Client secrets**, select **+ New client secret**.

-4. In **Description**, name the client secret.

-7. Under **Client secrets**, from the **Value** field, copy the value. Consider the value an application password. This example's value is visible, Azure values appear in the Cloudflare Access configuration.

- 

-2. Select **+** **Add a permission**.

- 

-5. Under **Manage**, select **+** **Add permissions**.

- [  ](./media/cloudflare-azure-ad-integration/request-api-permissions.png#lightbox)

- [  ](./media/cloudflare-azure-ad-integration/grant-admin-consent.png#lightbox)

-7. On the [Cloudflare Zero Trust dashboard](https://dash.teams.cloudflare.com/),

- navigate to **Settings> Authentication**.

-10. Enter the Application ID, Application secret, and Directory ID values.

- >[!NOTE]

- >For Azure AD groups, in **Edit your Azure AD identity provider**, for **Support Groups** select **On**.

-## Test the integration

-1. To test the integration on the Cloudflare Zero Trust dashboard,

- navigate to **Settings** > **Authentication**.

- 

- 

-## Next steps

-> When you request the `signInActivity` property while listing users, the maximum page size is 120 users. Requests with $top set higher than 120 will fail. The `signInActivity` property supports `$filter` (`eq`, `ne`, `not`, `ge`, `le`) *but not with any other filterable properties*.

-If you need to view the latest sign-in activity for a user you can view the user's sign-in details in Azure AD. You can also use the Microsoft Graph **users by name** scenario described in the [previous section](#detect-inactive-user-accounts-with-microsoft-graph).

-The last sign-in date and time shown on this tile may take up to 24 hours to update, which means the date and time may not be current. If you need to see the activity in near real time, select the **See all sign-ins** link on the **Sign-ins** tile to view all sign-in activity for that user.

-The nodeosupgradechannel isn't supported on Mariner and Windows OS nodepools.

-| `SecurityPatch`|AKS updates the node's virtual hard disk (VHD) with patches from the image maintainer labeled "security only" on a regular basis. There maybe disruptions when the security patches are applied to the nodes. When the patches are applied, the VHD is updated and existing machines are upgraded to that VHD, honoring maintenance windows and surge settings. This option incurs the extra cost of hosting the VHDs in your node resource group. If you use this channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default.|N/A|

- - `LeastConnections` - sends connections to the backend pod with the fewest connections

-> IPVS load balancing operates in each node independently and is still only aware of connections flowing through the local node. This means that while `LeastConnections` results in more even load under higher number of connections, when low numbers of connections (# connects < 2 * node count) occur traffic may still be relatively unbalanced.

-By default, AKS clusters use [kubenet][kubenet], and an Azure virtual network and subnet are created for you. With *kubenet*, nodes get an IP address from the Azure virtual network subnet. Pods receive an IP address from a logically different address space to the Azure virtual network subnet of the nodes. Network address translation (NAT) is then configured so that the pods can reach resources on the Azure virtual network. The source IP address of the traffic is NAT'd to the node's primary IP address. This approach greatly reduces the number of IP addresses that you need to reserve in your network space for pods to use.

-With [Azure Container Networking Interface (CNI)][cni-networking], every pod gets an IP address from the subnet and can be accessed directly. These IP addresses must be unique across your network space, and must be planned in advance. Each node has a configuration parameter for the maximum number of pods that it supports. The equivalent number of IP addresses per node are then reserved up front for that node. This approach requires more planning, and often leads to IP address exhaustion or the need to rebuild clusters in a larger subnet as your application demands grow. You can configure the maximum pods deployable to a node at cluster create time or when creating new node pools. If you don't specify maxPods when creating new node pools, you receive a default value of 110 for kubenet.

-This article shows you how to use *kubenet* networking to create and use a virtual network subnet for an AKS cluster. For more information on network options and considerations, see [Network concepts for Kubernetes and AKS][aks-network-concepts].

-* AKS clusters may not use `169.254.0.0/16`, `172.30.0.0/16`, `172.31.0.0/16`, or `192.0.2.0/24` for the Kubernetes service address range, pod address range, or cluster virtual network address range. This range can't be updated after you create your cluster.

-* The cluster identity used by the AKS cluster must have at least [Network Contributor](../role-based-access-control/built-in-roles.md#network-contributor) role on the subnet within your virtual network. CLI helps do the role assignment automatically. If you are using ARM template or other clients, the role assignment needs to be done manually. You must also have the appropriate permissions, such as the subscription owner, to create a cluster identity and assign it permissions. If you wish to define a [custom role](../role-based-access-control/custom-roles.md) instead of using the built-in Network Contributor role, the following permissions are required:

-> To use Windows Server node pools, you must use Azure CNI. The use of kubenet as the network model is not available for Windows Server containers.

-In many environments, you have defined virtual networks and subnets with allocated IP address ranges. These virtual network resources are used to support multiple services and applications. To provide network connectivity, AKS clusters can use *kubenet* (basic networking) or Azure CNI (*advanced networking*).

-With *kubenet*, only the nodes receive an IP address in the virtual network subnet. Pods can't communicate directly with each other. Instead, User Defined Routing (UDR) and IP forwarding is used for connectivity between pods across nodes. By default, UDRs and IP forwarding configuration is created and maintained by the AKS service, but you have the option to [bring your own route table for custom route management][byo-subnet-route-table]. You could also deploy pods behind a service that receives an assigned IP address and load balances traffic for the application. The following diagram shows how the AKS nodes receive an IP address in the virtual network subnet, but not the pods:

-Azure supports a maximum of 400 routes in a UDR, so you can't have an AKS cluster larger than 400 nodes. AKS [Virtual Nodes][virtual-nodes] and Azure Network Policies aren't supported with *kubenet*. You can use [Calico Network Policies][calico-network-policies], as they are supported with kubenet.

-With *Azure CNI*, each pod receives an IP address in the IP subnet, and can directly communicate with other pods and services. Your clusters can be as large as the IP address range you specify. However, the IP address range must be planned in advance, and all of the IP addresses are consumed by the AKS nodes based on the maximum number of pods that they can support. Advanced network features and scenarios such as [Virtual Nodes][virtual-nodes] or Network Policies (either Azure or Calico) are supported with *Azure CNI*.

-* AKS doesn't apply Network Security Groups (NSGs) to its subnet and will not modify any of the NSGs associated with that subnet. If you provide your own subnet and add NSGs associated with that subnet, you must ensure the security rules in the NSGs allow traffic between the node and pod CIDR. For more details, see [Network security groups][aks-network-nsg].

- * [Azure network policies](use-network-policies.md#create-an-aks-cluster-and-enable-network-policy), but Calico network policies are supported on kubenet

- * [Windows node pools](./windows-faq.md)

- * [Virtual nodes add-on](virtual-nodes.md#network-requirements)

-With *Azure CNI*, a common issue is the assigned IP address range is too small to then add additional nodes when you scale or upgrade a cluster. The network team may also not be able to issue a large enough IP address range to support your expected application demands.

-As a compromise, you can create an AKS cluster that uses *kubenet* and connect to an existing virtual network subnet. This approach lets the nodes receive defined IP addresses, without the need to reserve a large number of IP addresses up front for all of the potential pods that could run in the cluster.

-With *kubenet*, you can use a much smaller IP address range and be able to support large clusters and application demands. For example, even with a */27* IP address range on your subnet, you could run a 20-25 node cluster with enough room to scale or upgrade. This cluster size would support up to *2,200-2,750* pods (with a default maximum of 110 pods per node). The maximum number of pods per node that you can configure with *kubenet* in AKS is 110.

- - This node count could support up to *27,610* pods (with a default maximum of 110 pods per node with *kubenet*)

- - This node count could only support up to *240* pods (with a default maximum of 30 pods per node with *Azure CNI*)

-> These maximums don't take into account upgrade or scale operations. In practice, you can't run the maximum number of nodes that the subnet IP address range supports. You must leave some IP addresses available for use during scale or upgrade operations.

-To provide on-premises connectivity, both *kubenet* and *Azure-CNI* network approaches can use [Azure virtual network peering][vnet-peering] or [ExpressRoute connections][express-route]. Plan your IP address ranges carefully to prevent overlap and incorrect traffic routing. For example, many on-premises networks use a *10.0.0.0/8* address range that is advertised over the ExpressRoute connection. It's recommended to create your AKS clusters into Azure virtual network subnets outside of this address range, such as *172.16.0.0/16*.

-The choice of which network plugin to use for your AKS cluster is usually a balance between flexibility and advanced configuration needs. The following considerations help outline when each network model may be the most appropriate.

-Use *kubenet* when:

-Use *Azure CNI* when:

-To get started with using *kubenet* and your own virtual network subnet, first create a resource group using the [az group create][az-group-create] command. The following example creates a resource group named *myResourceGroup* in the *eastus* location:

-```azurecli-interactive

-az group create --name myResourceGroup --location eastus

-```

-If you don't have an existing virtual network and subnet to use, create these network resources using the [az network vnet create][az-network-vnet-create] command. In the following example, the virtual network is named *myAKSVnet* with the address prefix of *192.168.0.0/16*. A subnet is created named *myAKSSubnet* with the address prefix *192.168.1.0/24*.

-```azurecli-interactive

-az network vnet create \

- --resource-group myResourceGroup \

- --name myAKSVnet \

- --address-prefixes 192.168.0.0/16 \

- --subnet-name myAKSSubnet \

- --subnet-prefix 192.168.1.0/24

-```

-Get the subnet resource ID and store as a variable:

-```azurecli-interactive

-SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

-```

-Now create an AKS cluster in your virtual network and subnet using the [az aks create][az-aks-create] command.

-You can create an AKS cluster using a system-assigned managed identity by running the following CLI command.

-> When using system-assigned identity, azure-cli will grant Network Contributor role to the system-assigned identity after the cluster is created.

-> If you are using an ARM template or other clients, you need to use the [user-assigned managed identity][Create an AKS cluster with user-assigned managed identities]

-```azurecli-interactive

-az aks create \

- --resource-group myResourceGroup \

- --name myAKSCluster \

- --network-plugin kubenet \

- --service-cidr 10.0.0.0/16 \

- --dns-service-ip 10.0.0.10 \

- --pod-cidr 10.244.0.0/16 \

- --docker-bridge-address 172.17.0.1/16 \

- --vnet-subnet-id $SUBNET_ID

-```

-* The *--service-cidr* is optional. This address is used to assign internal services in the AKS cluster an IP address. This IP address range should be an address space that isn't in use elsewhere in your network environment, including any on-premises network ranges if you connect, or plan to connect, your Azure virtual networks using Express Route or a Site-to-Site VPN connection. The default value is 10.0.0.0/16.

-* The *--dns-service-ip* is optional. The address should be the *.10* address of your service IP address range. The default value is 10.0.0.10.

-* The *--pod-cidr* is optional. This address should be a large address space that isn't in use elsewhere in your network environment. This range includes any on-premises network ranges if you connect, or plan to connect, your Azure virtual networks using Express Route or a Site-to-Site VPN connection. The default value is 10.244.0.0/16.

- * This address range must be large enough to accommodate the number of nodes that you expect to scale up to. You can't change this address range once the cluster is deployed if you need more addresses for additional nodes.

-* The *--docker-bridge-address* is optional. The address lets the AKS nodes communicate with the underlying management platform. This IP address must not be within the virtual network IP address range of your cluster, and shouldn't overlap with other address ranges in use on your network. The default value is 172.17.0.1/16.

-> [!Note]

-> If you wish to enable an AKS cluster to include a [Calico network policy][calico-network-policies] you can use the following command.

-```azurecli-interactive

-az aks create \

- --resource-group myResourceGroup \

- --name myAKSCluster \

- --node-count 3 \

- --network-plugin kubenet --network-policy calico \

- --vnet-subnet-id $SUBNET_ID

-```

-### Create an AKS cluster with user-assigned managed identities

-#### Create or obtain a managed identity

-If you don't have a managed identity, you should create one by running the [az identity][az-identity-create] command.

-```azurecli-interactive

-az identity create --name myIdentity --resource-group myResourceGroup

-```

-The output should resemble the following:

-```output

-{

- "clientId": "<client-id>",

- "clientSecretUrl": "<clientSecretUrl>",

- "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",

- "location": "westus2",

- "name": "myIdentity",

- "principalId": "<principal-id>",

- "resourceGroup": "myResourceGroup",

- "tags": {},

- "tenantId": "<tenant-id>",

- "type": "Microsoft.ManagedIdentity/userAssignedIdentities"

-}

-```

-If you have an existing managed identity, you can find the Principal ID by running the following command:

-```azurecli-interactive

-az identity show --ids <identity-resource-id>

-```

-The output should resemble the following:

-```output

-{

- "clientId": "<client-id>",

- "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",

- "location": "eastus",

- "name": "myIdentity",

- "principalId": "<principal-id>",

- "resourceGroup": "myResourceGroup",

- "tags": {},

- "tenantId": "<tenant-id>",

- "type": "Microsoft.ManagedIdentity/userAssignedIdentities"

-}

-```

-If you are using Azure CLI, the role will be added automatically and you can skip this step. If you are using an ARM template or other clients, you need to use the Principal ID of the cluster managed identity to perform a role assignment.

-To assign the correct delegations in the remaining steps, use the [az network vnet show][az-network-vnet-show] and [az network vnet subnet show][az-network-vnet-subnet-show] commands to get the required resource IDs. These resource IDs are stored as variables and referenced in the remaining steps:

-```azurecli-interactive

-VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

-```

-Now assign the managed identity for your AKS cluster *Network Contributor* permissions on the virtual network using the [az role assignment create][az-role-assignment-create] command. Provide the *\<principalId>* as shown in the output from the previous command to create the identity:

-```azurecli-interactive

-az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

-```

-Example:

-```azurecli-interactive

-az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

-```

-Now you can create an AKS cluster using the user-assigned managed identity by running the following CLI command. Provide the control plane identity resource ID via `assign-identity`

-```azurecli-interactive

-az aks create \

- --resource-group myResourceGroup \

- --name myAKSCluster \

- --node-count 3 \

- --network-plugin kubenet \

- --vnet-subnet-id $SUBNET_ID \

- --assign-identity <identity-resource-id>

-```

-With kubenet, a route table must exist on your cluster subnet(s). AKS supports bringing your own existing subnet and route table.

-If your custom subnet does not contain a route table, AKS creates one for you and adds rules to it throughout the cluster lifecycle. If your custom subnet contains a route table when you create your cluster, AKS acknowledges the existing route table during cluster operations and adds/updates rules accordingly for cloud provider operations.

-> Custom rules can be added to the custom route table and updated. However, rules are added by the Kubernetes cloud provider which must not be updated or removed. Rules such as 0.0.0.0/0 must always exist on a given route table and map to the target of your internet gateway, such as an NVA or other egress gateway. Take caution when updating rules that only your custom rules are being modified.

-Kubenet networking requires organized route table rules to successfully route requests. Due to this design, route tables must be carefully maintained for each cluster which relies on it. Multiple clusters cannot share a route table because pod CIDRs from different clusters may overlap which causes unexpected and broken routing. When configuring multiple clusters on the same virtual network or dedicating a virtual network to each cluster, ensure the following limitations are considered.

-Limitations:

-* The associated route table resource cannot be updated after cluster creation. While the route table resource cannot be updated, custom rules can be modified on the route table.

-* Each AKS cluster must use a single, unique route table for all subnets associated with the cluster. You cannot reuse a route table with multiple clusters due to the potential for overlapping pod CIDRs and conflicting routing rules.

-* For system-assigned managed identity, it's only supported to provide your own subnet and route table via Azure CLI. That's because CLI will add the role assignment automatically. If you are using an ARM template or other clients, you must use a [user-assigned managed identity][Create an AKS cluster with user-assigned managed identities], assign permissions before cluster creation, and ensure the user-assigned identity has write permissions to your custom subnet and custom route table.

-> To create and use your own VNet and route table with `kubenet` network plugin, you need to use [user-assigned control plane identity][bring-your-own-control-plane-managed-identity]. For system-assigned control plane identity, the identity ID cannot be retrieved before creating a cluster, which causes a delay during role assignment.

->

-> To create and use your own VNet and route table with `azure` network plugin, both system-assigned and user-assigned managed identities are supported. But user-assigned managed identity is more recommended for BYO scenarios.

-```azurecli-interactive

-# Find your subnet ID

-az network vnet subnet list --resource-group

- --vnet-name

- [--subscription]

-```

-```azurecli-interactive

-# Create a kubernetes cluster with with a custom subnet preconfigured with a route table

-az aks create -g myResourceGroup -n myManagedCluster --vnet-subnet-id mySubnetIDResourceID --enable-managed-identity --assign-identity controlPlaneIdentityResourceID

-```

-With an AKS cluster deployed into your existing virtual network subnet, you can now use the cluster as normal. Get started with [creating new apps using Helm][develop-helm] or [deploy existing apps using Helm][use-helm].

-[az-ad-sp-create-for-rbac]: /cli/azure/ad/sp#az_ad_sp_create_for_rbac

-[Azure Monitor for Container Health][azure-monitor] collects memory and processor performance metrics from containers, nodes, and controllers within your AKS clusters and deployed applications. You can review both container logs and [the Kubernetes logs][aks-master-logs], which are:

-* Stored in an [Azure Log Analytics][azure-logs] workspace.

-* Available through the Azure portal, Azure CLI, or a REST endpoint.

-For more information, see [Monitor AKS container health][container-health].

-[container-health]: ../azure-monitor/containers/container-insights-overview.md

-[azure-monitor]: /previous-versions/azure/azure-monitor/containers/containers

-[azure-logs]: ../azure-monitor/logs/log-analytics-overview.md

-Azure Kubernetes Service (AKS) is a managed Kubernetes service that lets you quickly deploy and manage clusters. In this quickstart, you'll:

-To access AKS nodes, you connect using an SSH key pair (public and private), which you generate using the `ssh-keygen` command. By default, these files are created in the *~/.ssh* directory. Running the `ssh-keygen` command will overwrite any SSH key pair with the same name already existing in the given location.

-1. Run the `ssh-keygen` command. The following example creates an SSH key pair using RSA encryption and a bit length of 4096:

-1. Deploy the Bicep file using either Azure CLI or Azure PowerShell.

- # [CLI](#tab/CLI)

- az group create --name myResourceGroup --location eastus

- az deployment group create --resource-group myResourceGroup --template-file main.bicep --parameters clusterName=<cluster-name> dnsPrefix=<dns-prefix> linuxAdminUsername=<linux-admin-username> sshRSAPublicKey='<ssh-key>'

- # [PowerShell](#tab/PowerShell)

- New-AzResourceGroupDeployment -ResourceGroupName myResourceGroup -TemplateFile ./main.bicep -clusterName=<cluster-name> -dnsPrefix=<dns-prefix> -linuxAdminUsername=<linux-admin-username> -sshRSAPublicKey="<ssh-key>"

- * **Cluster name**: Enter a unique name for the AKS cluster, such as *myAKSCluster*.

-

-To learn more about AKS, and walk through a complete code to deployment example, continue to the Kubernetes cluster tutorial.

-[azure-dev-spaces]: /previous-versions/azure/dev-spaces/

-[aks-monitor]: ../../azure-monitor/containers/container-insights-onboard.md

-[az-aks-browse]: /cli/azure/aks#az_aks_browse

-[az-aks-create]: /cli/azure/aks#az_aks_create

-[azure-cli-install]: /cli/azure/install-azure-cli

-[sp-delete]: ../kubernetes-service-principal.md#additional-considerations

-[azure-portal]: https://portal.azure.com

-[az-ad-sp-create-for-rbac]: /cli/azure/ad/sp#az_ad_sp_create_for_rbac

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-> The open source Azure AD pod-managed identity (preview) in Azure Kubernetes Service has been deprecated as of 10/24/2022 and the projected will be archived in Sept. 2023. For more information, see the [deprecation notice](https://github.com/Azure/aad-pod-identity#-announcement).

-> The AKS Managed add-on will begin deprecation in Sept. 2023.

-1. API Management stv2 requires a public IP with a `DomainNameLabel`:

- $gatewayHostname = "api.$domain" # API gateway host

- $portalHostname = "portal.$domain" # API developer portal host

- $managementHostname = "management.$domain" # API management endpoint host

- $gatewayCertPfxPath = "C:\Users\Contoso\gateway.pfx" # Full path to api.contoso.net .pfx file

- $portalCertPfxPath = "C:\Users\Contoso\portal.pfx" # Full path to portal.contoso.net .pfx file

- $managementCertPfxPath = "C:\Users\Contoso\management.pfx" # Full path to management.contoso.net .pfx file

- $gatewayCertPfxPassword = "certificatePassword123" # Password for api.contoso.net pfx certificate

- $portalCertPfxPassword = "certificatePassword123" # Password for portal.contoso.net pfx certificate

- $managementCertPfxPassword = "certificatePassword123" # Password for management.contoso.net pfx certificate

- $trustedRootCertCerPath = "C:\Users\Contoso\trustedroot.cer" # Full path to contoso.net trusted root .cer file

- endpointAddress: 'https://<EventHubsNamespace>.servicebus.windows.net/<EventHubName>'

- "endpointAddress": "https://<EventHubsNamespace>.servicebus.windows.net/<EventHubName>",

- endpointAddress: 'https://<EventHubsNamespace>.servicebus.windows.net/<EventHubName>'

- "endpointAddress": "https://<EventHubsNamespace>.servicebus.windows.net/<EventHubName>",

-The policy assumes that Dapr runtime is running in a sidecar container in the same pod as the gateway. Dapr runtime is responsible for invoking the external resource represented by the binding. Learn more about [Dapr integration with API Management](api-management-dapr-policies.md).

-Dapr support must be [enabled](api-management-dapr-policies.md#enable-dapr-support-in-the-self-hosted-gateway) in the self-hosted gateway.

-The policy assumes that Dapr runtime is running in a sidecar container in the same pod as the gateway. Dapr runtime implements the Pub/Sub semantics. Learn more about [Dapr integration with API Management](api-management-dapr-policies.md).

-Dapr support must be [enabled](api-management-dapr-policies.md#enable-dapr-support-in-the-self-hosted-gateway) in the self-hosted gateway.

-The policy assumes that Dapr runs in a sidecar container in the same pod as the gateway. Upon receiving the request, Dapr runtime performs service discovery and actual invocation, including possible protocol translation between HTTP and gRPC, retries, distributed tracing, and error handling. Learn more about [Dapr integration with API Management](api-management-dapr-policies.md).

-Dapr support must be [enabled](api-management-dapr-policies.md#enable-dapr-support-in-the-self-hosted-gateway) in the self-hosted gateway.

-If your vault is configured with [network restrictions](../key-vault/general/overview-vnet-service-endpoints.md), you will also need to ensure that the application has network access.

- "AzureWebJobsStorage": "[concat('@Microsoft.KeyVault(SecretUri=', reference(variables('storageConnectionStringResourceId')).secretUriWithVersion, ')')]",

- "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING": "[concat('@Microsoft.KeyVault(SecretUri=', reference(variables('storageConnectionStringResourceId')).secretUriWithVersion, ')')]",

- "APPINSIGHTS_INSTRUMENTATIONKEY": "[concat('@Microsoft.KeyVault(SecretUri=', reference(variables('appInsightsKeyResourceId')).secretUriWithVersion, ')')]",

-The certificate for custom domain suffix must be stored in an Azure Key Vault. App Service Environment will use the managed identity you selected to get the certificate. The key vault must be publicly accessible, however you can lock down the key vault by restricting access to your App Service Environment's outbound IPs. You can find your App Service Environment's outbound IPs under "Default outbound addresses" on the **IP addresses** page for your App Service Environment. You'll need to add both IPs to your key vault's firewall rules. For more information on key vault network security and firewall rules, see [Configure Azure Key Vault firewalls and virtual networks](../../key-vault/general/network-security.md#key-vault-firewall-enabled-ipv4-addresses-and-rangesstatic-ips). The key vault also must not have any [private endpoint connections](../../private-link/private-endpoint-overview.md).

-Some of the common reasons for the request to be non-compliant to RFC is listed.So review the urls/requests from the clients and ensure it's compliant to RFC.

-An HTTP 401 unauthorized response can be returned when backend pool is configured with [NTLM](/windows/win32/secauthn/microsoft-ntlm?redirectedfrom=MSDN) authentication.

- #### 403 ΓÇô Forbidden

-description: This article shows you how to migrate Azure Application Gateway and Web Application Firewall from v1 to v2

-* Creates a new Standard_v2 or WAF_v2 gateway in a virtual network subnet that you specify.

-* Seamlessly copies the configuration associated with the v1 Standard or WAF gateway to the newly created Standard_V2 or WAF_V2 gateway.

- -resourceId <v1 application gateway Resource ID>

- * **resourceId: [String]: Required** - This is the Azure Resource ID for your existing Standard v1 or WAF v1 gateway. To find this string value, navigate to the Azure portal, select your application gateway or WAF resource, and click the **Properties** link for the gateway. The Resource ID is located on that page.

- $appgw = Get-AzApplicationGateway -Name <v1 gateway name> -ResourceGroupName <resource group Name>

- * **subnetAddressRange: [String]: Required** - This is the IP address space that you've allocated (or want to allocate) for a new subnet that contains your new v2 gateway. This must be specified in the CIDR notation. For example: 10.0.0.0/24. You don't need to create this subnet in advance but the CIDR needs to be part of the VNET address space. The script creates it for you if it doesn't exist and if it exists, it will use the existing one (make sure the subnet is either empty, contains only v2 Gateway if any, and has enough available IPs).

- * **appgwName: [String]: Optional**. This is a string you specify to use as the name for the new Standard_v2 or WAF_v2 gateway. If this parameter isn't supplied, the name of your existing v1 gateway will be used with the suffix *_v2* appended.

- * **AppGwResourceGroupName: [String]: Optional**. Name of resource group where you want v2 Application Gateway resources to be created (default value will be `<v1-app-gw-rgname>`)

- * **sslCertificates: [PSApplicationGatewaySslCertificate]: Optional**. A comma-separated list of PSApplicationGatewaySslCertificate objects that you create to represent the TLS/SSL certs from your v1 gateway must be uploaded to the new v2 gateway. For each of your TLS/SSL certs configured for your Standard v1 or WAF v1 gateway, you can create a new PSApplicationGatewaySslCertificate object via the `New-AzApplicationGatewaySslCertificate` command shown here. You need the path to your TLS/SSL Cert file and the password.

- This parameter is only optional if you don't have HTTPS listeners configured for your v1 gateway or WAF. If you have at least one HTTPS listener setup, you must specify this parameter.

- * **privateIpAddress: [String]: Optional**. A specific private IP address that you want to associate to your new v2 gateway. This must be from the same VNet that you allocate for your new v2 gateway. If this isn't specified, the script allocates a private IP address for your v2 gateway.

- * **publicIpResourceId: [String]: Optional**. The resourceId of existing public IP address (standard SKU) resource in your subscription that you want to allocate to the new v2 gateway. If this isn't specified, the script allocates a new public IP in the same resource group. The name is the v2 gateway's name with *-IP* appended.

- * **validateMigration: [switch]: Optional**. Use this parameter if you want the script to do some basic configuration comparison validations after the v2 gateway creation and the configuration copy. By default, no validation is done.

- * **enableAutoScale: [switch]: Optional**. Use this parameter if you want the script to enable AutoScaling on the new v2 gateway after it's created. By default, AutoScaling is disabled. You can always manually enable it later on the newly created v2 gateway.

-* The new v2 gateway has new public and private IP addresses. It isn't possible to move the IP addresses associated with the existing v1 gateway seamlessly to v2. However, you can allocate an existing (unallocated) public or private IP address to the new v2 gateway.

-* You must provide an IP address space for another subnet within your virtual network where your v1 gateway is located. The script can't create the v2 gateway in any existing subnets that already have a v1 gateway. However, if the existing subnet already has a v2 gateway, that may still work provided there's enough IP address space.

-* If you have a network security group or user defined routes associated to the v2 gateway subnet, make sure they adhere to the [NSG requirements](../application-gateway/configuration-infrastructure.md#network-security-groups) and [UDR requirements](../application-gateway/configuration-infrastructure.md#supported-user-defined-routes) for a successful migration

-* To migrate a TLS/SSL configuration, you must specify all the TLS/SSL certs used in your v1 gateway.

-* If you have FIPS mode enabled for your V1 gateway, it won't be migrated to your new v2 gateway. FIPS mode isn't supported in v2.

-* Headers with names containing anything other than letters, digits, and hyphens are not passed to your application. This only applies to header names, not header values. This is a breaking change from v1.

-* NTLM and Kerberos authentication is not supported by Application Gateway v2. The script is unable to detect if the gateway is serving this type of traffic and may pose as a breaking change from v1 to v2 gateways if run.

-First, double check that the script successfully created a new v2 gateway with the exact configuration migrated over from your v1 gateway. You can verify this from the Azure portal.

-Also, send a small amount of traffic through the v2 gateway as a manual test.

-* **A custom DNS zone (for example, contoso.com) that points to the frontend IP address (using an A record) associated with your Standard v1 or WAF v1 gateway**.

- You can update your DNS record to point to the frontend IP or DNS label associated with your Standard_v2 application gateway. Depending on the TTL configured on your DNS record, it may take a while for all your client traffic to migrate to your new v2 gateway.

-* **A custom DNS zone (for example, contoso.com) that points to the DNS label (for example: *myappgw.eastus.cloudapp.azure.com* using a CNAME record) associated with your v1 gateway**.

- * If you use public IP addresses on your application gateway, you can do a controlled, granular migration using a Traffic Manager profile to incrementally route traffic (weighted traffic routing method) to the new v2 gateway.

- You can do this by adding the DNS labels of both the v1 and v2 application gateways to the [Traffic Manager profile](../traffic-manager/traffic-manager-routing-methods.md#weighted-traffic-routing-method), and CNAMEing your custom DNS record (for example, `www.contoso.com`) to the Traffic Manager domain (for example, contoso.trafficmanager.net).

- * Or, you can update your custom domain DNS record to point to the DNS label of the new v2 application gateway. Depending on the TTL configured on your DNS record, it may take a while for all your client traffic to migrate to your new v2 gateway.

- Update your clients to use the IP address(es) associated with the newly created v2 application gateway. We recommend that you don't use IP addresses directly. Consider using the DNS name label (for example, yourgateway.eastus.cloudapp.azure.com) associated with your application gateway that you can CNAME to your own custom DNS zone (for example, contoso.com).

-The pricing models are different for the Application Gateway v1 and v2 SKUs. V2 is charged based on consumption. See [Application Gateway pricing](https://azure.microsoft.com/pricing/details/application-gateway/) before migrating for pricing information.

-| SKU | v1 Fixed Price/mo | v2 Fixed Price/mo | Recommendation|

-[Learn about Application Gateway v2](application-gateway-autoscaling-zone-redundant.md)

-> **User-assigned managed identities (UAMI) are in general supported for Azure jobs only.** One other scenario in which user-assigned managed identities (UAMI) run successfully in Hybrid Workers is, when only the Hybrid Worker VM has a UAMI assigned (i.e., the Automation Account can't have any UAMI assigned, otherwise the VM UAMI will fail authenticating).

-```tsql

-## March 2021

-The March 2021 release was initially introduced on April 5th 2021, and the final stages of release were completed April 9th 2021.

-Azure Data CLI (`azdata`) version number: 20.3.2. You can install `azdata` from [Install Azure Data CLI (`azdata`)](/sql/azdata/install/deploy-install-azdata).

-### Data controller

-### Azure Arc-enabled PostgreSQL server

-Both custom resource definitions (CRD) for PostgreSQL have been consolidated into a single CRD. See the following table.

-|Release |CRD |

-|--|--|

-|February 2021 and prior| postgresql-11s.arcdata.microsoft.com<br/>postgresql-12s.arcdata.microsoft.com |

-|Beginning March 2021 | postgresqls.arcdata.microsoft.com

-### Azure Arc-enabled SQL Managed Instance

-## February 2021

-### New capabilities and features

-Azure Data CLI (`azdata`) version number: 20.3.1. You can install `azdata` from [Install Azure Data CLI (`azdata`)](/sql/azdata/install/deploy-install-azdata).

-Additional updates include:

- - High availability with Always On availability groups

- Azure Data Studio:

- - The overview page shows the status of the server group itemized per node

- - A new properties page shows more details about the server group

- - Configure Postgres engine parameters from **Node Parameters** page

-## January 2021

-### New capabilities and features

-Azure Data CLI (`azdata`) version number: 20.3.0. You can install `azdata` from [Install Azure Data CLI (`azdata`)](/sql/azdata/install/deploy-install-azdata).

-Additional updates include:

- In earlier releases, the status was aggregated at the server group level and not itemized at the PostgreSQL node level.

- It is now in the form: `ServergroupName{c, w}-n`. For example, a server group with three nodes, one coordinator node and two worker nodes is represented as:

- - `Postgres01c-0` (coordinator node)

- - `Postgres01w-0` (worker node)

- - `Postgres01w-1` (worker node)

-## December 2020

-### New capabilities & features

-Azure Data CLI (`azdata`) version number: 20.2.5. You can install `azdata` from [Install Azure Data CLI (`azdata`)](/sql/azdata/install/deploy-install-azdata).

-View endpoints for SQL Managed Instance and PostgreSQL server using the Azure Data CLI (`azdata`) with `azdata arc sql endpoint list` and `azdata arc postgres endpoint list` commands.

-Edit SQL Managed Instance resource (CPU core and memory) requests and limits using Azure Data Studio.

-Azure Arc-enabled PostgreSQL server now supports point in time restore in addition to full backup restore for both versions 11 and 12 of PostgreSQL. The point in time restore capability allows you to indicate a specific date and time to restore to.

-The naming convention of the pods for Azure Arc-enabled PostgreSQL server has changed. It is now in the form: ServergroupName{r, s}-_n_. For example, a server group with three nodes, one coordinator node and two worker nodes is represented as:

-### Breaking change

-#### New resource provider

-This release introduces an updated [resource provider](../../azure-resource-manager/management/azure-services-resource-providers.md) called `Microsoft.AzureArcData`. Before you can use this feature, you need to register this resource provider.

-To register this resource provider:

-1. In the Azure portal, select **Subscriptions**

-2. Choose your subscription

-3. Under **Settings**, select **Resource providers**

-4. Search for `Microsoft.AzureArcData` and select **Register**

-You can review detailed steps at [Azure resource providers and types](../../azure-resource-manager/management/resource-providers-and-types.md). This change also removes all the existing Azure resources that you have uploaded to the Azure portal. In order to use the resource provider, you need to update the data controller and use the latest `azdata` CLI.

-### Platform release notes

-#### Direct connectivity mode

-This release introduces direct connectivity mode. Direct connectivity mode enables the data controller to automatically upload the usage information to Azure. As part of the usage upload, the Arc data controller resource is automatically created in the portal, if it is not already created via `azdata` upload.

-You can specify direct connectivity when you create the data controller. The following example creates a data controller with `az arcdata dc create` named `arc` using direct connectivity mode (`connectivity-mode direct`). Before you run the example, replace `<subscription id>` with your subscription ID.

-```azurecli

-az arcdata dc create --profile-name azure-arc-aks-hci --k8s-namespace <namespace> --use-k8s --name arc --subscription <subscription id> --resource-group my-resource-group --location eastus --connectivity-mode direct

-```

-## October 2020

-Azure Data CLI (`azdata`) version number: 20.2.3. You can install `azdata` from [Install Azure Data CLI (`azdata`)](/sql/azdata/install/deploy-install-azdata).

-### Breaking changes

-This release introduces the following breaking changes:

-* In the PostgreSQL custom resource definition (CRD), the term `shards` is renamed to `workers`. This term (`workers`) matches the command-line parameter name.

-* `azdata arc postgres server delete` prompts for confirmation before deleting a postgres instance. Use `--force` to skip prompt.

-### Additional changes

-* A new optional parameter was added to `azdata arc postgres server create` called `--volume-claim mounts`. The value is a comma-separated list of volume claim mounts. A volume claim mount is a pair of volume type and PVC name. The only volume type currently supported is `backup`. In PostgreSQL, when volume type is `backup`, the PVC is mounted to `/mnt/db-backups`. This enables sharing backups between PostgreSQL instances so that the backup of one PostgreSQL instance can be restored in another instance.

-* New short names for PostgreSQL custom resource definitions:

- * `pg11`

- * `pg12`

-* Telemetry upload provides user with either:

- * Number of points uploaded to Azure

- or

- * If no data has been loaded to Azure, a prompt to try it again.

-* `az arcdata dc debug copy-logs` now also reads from `/var/opt/controller/log` folder and collects PostgreSQL engine logs on Linux.

-* Display a working indicator during creating and restoring backup with PostgreSQL server.

-* `azdata arc postrgres backup list` now includes backup size information.

-* SQL Managed Instance admin name property was added to right column of overview blade in the Azure portal.

-* Azure Data Studio supports configuring number of worker nodes, vCore, and memory settings for PostgreSQL server.

-* Preview supports backup/restore for Postgres version 11 and 12.

-## September 2020

-Azure Arc-enabled data services allow you to manage data services anywhere. This is a preview release.

-For instructions see [What are Azure Arc-enabled data services?](overview.md)

-[FunctionName("SayHello")]

- await context.CallActivityAsync("SendAlert", machineId);

- await context.CallActivityAsync("SendAlert", machineId);

- yield context.df.callActivity("SendAlert", machineId);

-```

-```bash

-```

-```bash

-```

-```powershell

-```

-```powershell

-```

-```cmd

-```

-```cmd

-| | Update Management | X (Public preview, independent of monitoring agents) | | |

-| | Update Management | X (Public preview, independent of monitoring agents) | X | |

- > - Configure the agents to send the data to different workspaces or different tables in the same workspace.

- > - Disable duplicate data collection from legacy agents by [removing the workspace configurations](./agent-data-sources.md#configure-data-sources).

- > - Defender for Cloud natively deduplicates data when you use both agents, and [you'll be billed once per machine](../../defender-for-cloud/auto-deploy-azure-monitoring-agent.md#impact-of-running-with-both-the-log-analytics-and-azure-monitor-agents) when you run the agents side by side.

- > - For Sentinel, you can easily [disable the legacy connector](../../sentinel/ama-migrate.md#recommended-migration-plan) to stop ingestion of logs from legacy agents.

-1. **Verify** that Azure Monitor Agent is collecting data as expected and all **downstream dependencies**, such as dashboards, alerts, and workbooks, function properly:

-## Define a custom log

-Use the following procedure to define a custom log file. Scroll to the end of this article for a walkthrough of a sample of adding a custom log.

-1. In the Azure portal, select **Log Analytics workspaces** > your workspace.

-1. Under the **Classic** section, select **Legacy custom logs**.

-1. By default, all configuration changes are automatically pushed to all agents. For Linux agents, a configuration file is sent to the Fluentd data collector.

-1. Select **Add** to open the Custom Log wizard.

-1. The Custom Log wizard uploads the file and lists the records that it identifies.

-## Remove a custom log

-Use the following process in the Azure portal to remove a custom log that you previously defined.

-1. On the left, under the **Classic** section for your workspace, select **Legacy custom Logs** to list all your custom logs.

-1. Select **Remove** next to the custom log to remove the log.

-Starting from version 3.2.0, if you want to set a custom dimension programmatically on your request telemetry and have it inherited by dependency telemetry that follows:

-## TelemetryInitializers and TelemetryProcessors

-The 2.x SDK TelemetryInitializers and TelemetryProcessors will not be run when using the 3.x agent.

-Many of the use cases that previously required these can be solved in Application Insights Java 3.x

-by configuring [custom dimensions](./java-standalone-config.md#custom-dimensions)

-or configuring [telemetry processors](./java-standalone-telemetry-processors.md).

-If you can't run the application or you aren't getting data as expected, wee the dedicated [troubleshooting article](/troubleshoot/azure/azure-monitor/app-insights/javascript-sdk-troubleshooting).

- > [!NOTE]

- > Servlet and Netty auto-instrumentation covers the majority of Java HTTP services, including Java EE, Jakarta EE, Spring Boot, Quarkus, and Micronaut.

-To ensure the security of data in transit, we strongly encourage you to configure Transport Layer Security (TLS). All destination endpoints support TLS 1.2.

-> For information about creating a custom table for logs you ingest with the deprecated Log Analytics agent, also known as MMA or OMS, see [Collect text logs with the Log Analytics agent](../agents/data-sources-custom-logs.md#define-a-custom-log).

-3. You use the managed identity to which the Azure Key Vault admin granted permissions in step one to authenticate access to Azure Key Vault via Azure Active Directory.

-* Switching from user-assigned identity to the system-assigned identity isn't currently supported.

- * To renew, you need to call the NetApp account operation `renewCredentials` if eligible for renewal. If it's not eligible, an error message will communicate the date of eligibility.

- * If the account isn't eligible for MSI certificate renewal, an error will communicate the date and time when the account is eligible. It's recommended you run this operation periodically (for example, daily) to prevent the certificate from expiring and from the customer-managed key volume going offline.

-1. Select the identity type that you want to use for authentication to the Azure Key Vault. If your Azure Key Vault is configured to use Vault access policy as its permission model, then both options are available. Otherwise, only the user-assigned option is available.

- * If you choose **User-assigned**, you must select an identity to use. Choosing **Select an identity** opens a context pane prompting you to select a user-assigned managed identity.

- If you've configured your Azure Key Vault use Vault access policy, the Azure portal configures the NetApp account automatically with the following process: The user-assigned identity you select is added to your NetApp account. An access policy is created on your Azure Key Vault with the key permissions Get, Encrypt, Decrypt.

- Although there are pre-defined roles with these permissions, they grant more privileges than are required. For the minimum level of privileges, you should create a custom role with only the required permissions. For details, see [Azure custom roles](../role-based-access-control/custom-roles.md).

-1. Once the custom role is created and available to use with the key vault, you can add a role assignment for your user-assigned identity.

-If you have already configured your NetApp account for customer-managed keys and has one or more volumes encrypted with customer-managed keys, you can change the key that is used to encrypt all volumes under the NetApp account. You can select any key that is in the same key vault, changing key vaults isn't supported.

-This section lists error messages and possible resolutions when Azure NetApp Files fails to configure customer-managed key encryption or create a volume using a customer-managed key.

- "version": "0.0.1-preview",

-description: Learn about using run commands in Azure VMware Solution.

-# Run command in Azure VMware Solution

-In Azure VMware Solution, vCenter Server has a built-in local user called *cloudadmin* assigned to the CloudAdmin role. The CloudAdmin role has vCenter Server [privileges](concepts-identity.md#vcenter-server-access-and-identity) that differ from other VMware cloud solutions and on-premises deployments. The Run command feature lets you perform operations that would normally require elevated privileges through a collection of PowerShell cmdlets.

->Run commands are executed one at a time in the order submitted.

-You can view the status of any executed run command, including the output, errors, warnings, and information logs of the cmdlets.

- :::image type="content" source="media/run-command/run-execution-status.png" alt-text="Screenshot showing Run execution status tab." lightbox="media/run-command/run-execution-status.png":::

-Now that you've learned about the Run command concepts, you can use the Run command feature to:

- The URLs and user credentials for private cloud vCenter Server and NSX-T Manager display.

-1. In the second tab of the browser, sign in to NSX-T Manager.

- <version>1.27.0</version>

- implementation 'com.microsoft.cognitiveservices.speech:client-sdk-embedded:1.27.0@aar'

-The add-on feature enables extra capability on AKS when running confidential computing Intel SGX capable node pools on the cluster. "Confcon" add-on on AKS enables the features below.

-# [bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [bash](#tab/bash)

-```azurepowershell

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- ```azurecli

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- ```azurecli

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- # [bash](#tab/bash)

- ```azurepowershell

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- # [bash](#tab/bash)

- ```azurecli

- ```azurepowershell

- ```azurecli

- # [bash](#tab/bash)

- ```bash

- ```azurepowershell

- # [bash](#tab/bash)

- ```azurecli

- ```azurecli

- # [bash](#tab/bash)

- ```azurecli

- ```azurecli

- # [bash](#tab/bash)

- ```azurecli

- ```azurecli

- ```azurecli

-# Deploy to Azure Container Apps from Azure Pipelines (preview)

-To build and deploy your container app, add the [`AzureContainerAppsRC`](https://marketplace.visualstudio.com/items?itemName=microsoft-oryx.AzureContainerAppsRC) (preview) Azure Pipelines task to your pipeline.

-The following snippet shows how to deploy an existing container image to Container Apps.

- - task: AzureContainerAppsRC@0

- acrName: 'myregistry'

-### Install the Azure Container Apps task

-The Azure Container Apps Azure Pipelines task is currently in preview. Before you use the task, you must install it from the Azure DevOps Marketplace.

-1. Open the [Azure Container Apps task](https://marketplace.visualstudio.com/items?itemName=microsoft-oryx.AzureContainerAppsRC) in the Azure DevOps Marketplace.

-1. Select **Get it free**.

-1. Select your Azure DevOps organization and select **Install**.

- - task: AzureContainerAppsRC@0

-# [Bash](#tab/bash)

-```powershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

- # [Bash](#tab/bash)

- ```console

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

- # [Bash](#tab/bash)

- ```azurecli

- # [Bash](#tab/bash)

- ```azurecli

- # [Bash](#tab/bash)

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-Learn more about how [Dapr integrates with Azure Container Apps](./dapr-overview.md).

- ```bash

-# [Bash](#tab/bash)

-```azurecli

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# Deploy to Azure Container Apps with GitHub Actions (preview)

- uses: azure/container-apps-deploy-action@v0

- uses: azure/container-apps-deploy-action@v0

- ```azurecli

- ```azurecli

- ```bash

- ```azurecli

- uses: azure/container-apps-deploy-action@v0

-```bash

-```azurepowershell

-```bash

-```bash

-```azurecli

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurecli

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-## Verify the result

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```bash

-```bash

-```azurecli

-```azurecli

-```bash

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

-```azurecli

-# [Bash](#tab/bash)

-```bash

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```bash

-```bash

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurecli

-```azurecli

-# [Bash](#tab/bash)

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```azurepowershell

-# [Bash](#tab/bash)

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```bash

-```bash

-```bash

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-```azurecli

-```azurecli

-```azurecli

-```azurepowershell

-```azurepowershell

-```azurepowershell

-# [Bash](#tab/bash)

-# [Bash](#tab/bash)

-```azurecli

-```azurepowershell

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

-```azurecli

-```azurecli

-```console

-```azurecli

-```console

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

- ```azurecli

-```azurecli

-```azurecli

- ```azurecli

-```azurecli

-```console

-```azurecli

-```azurecli

-```console

-```azurecli

-```console

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```Console

-```azurecli

-```Console

-```azurecli

-```azurecli

-```console

-```console

-```azurecli

-```azurecli

-```console

-```azurecli

-$ wget 192.0.2.1

-$ wget 192.0.2.1

-```bash

-```bash

-Output:

-```console

-Output:

-```console

-```bash

-```console

-$ docker images

- ```azurecli

- ```azurecli

-```powershell

-```powershell

-```powershell

-```powershell

-```

-```azurecli

-```console

- ```bash

- ```bash

-```azurecli

-```azurecli

-```console

-$ docker images

-```console

-$ docker images

-```console

-$ docker push mycontainerregistry082.azurecr.io/aci-tutorial-app:v1

-```azurecli

-```azurecli

-```azurecli

-```console

-Result

-```bash

-```console

-$ docker build ./aci-helloworld -t aci-tutorial-app

-```console

-$ docker images

-```console

-$ docker run -d -p 8080:80 aci-tutorial-app

-```azurecli

-```azurecli

-```console

-```azurecli

-```azurecli

-```console

-```azurecli

-```console

-```azurecli

-```azurecli

-In addition to the JSON view, provisioning state can be also be found in the [response body of the HTTP call](/rest/api/container-instances/containergroups/createorupdate#response).

-See the [Autoscale](provision-throughput-autoscale.md#autoscale-limits) article and [FAQ](autoscale-faq.yml#lowering-the-max-ru-s) for more detailed explanation of the throughput and storage limits with autoscale.

-| Minimum autoscale max RU/s for a database | `MAX(1000, highest max RU/s ever provisioned / 10, current storage in GB * 10, 1000 + (MAX(Container count - 25, 0) * 1000))`, rounded to nearest 1000 RU/s. <br></br>Note if your database has more than 25 containers, the system increments the minimum autoscale max RU/s by 1000 RU/s per extra container. For example, if you have 30 containers, the lowest autoscale maximum RU/s you can set is 6000 RU/s (scales between 600 - 6000 RU/s).

-| `Hashed Index` | :::image type="icon" source="media/compatibility/no-icon.svg"::: No |

-When you use database level throughput with autoscale, you can have the first 25 containers share an autoscale maximum RU/s of 1000 (scales between 100 - 1000 RU/s), as long as you don't exceed 100 GB of storage. See this [documentation](autoscale-faq.yml#can-i-change-the-max-ru-s-on-the-database-or-container--) for more information.

-When we scaled up to 200,000 RU/s, the lowest manual RU/s we can now set in the future is 2000 RU/s. The [lowest autoscale max RU/s](autoscale-faq.yml#lowering-the-max-ru-s) we can set is 20,000 RU/s (scales between 2000 - 20,000 RU/s). Since our target RU/s is 150,000 RU/s, we are not affected by the minimum RU/s.

-When you exchange a reservation, you can change your term from one-year to three-year.

- If you're not an Enterprise admin, your organization must assign you that role with full access. For more information about how to become a member of the role, see [Add another enterprise administrator](../manage/ea-portal-administration.md#create-another-enterprise-administrator).

-description: Learn how to transform data from an SAP ODP source to supported sink data stores by using mapping data flows in Azure Data Factory or Azure Synapse Analytics.

-This article outlines how to use mapping data flow to transform data from an SAP ODP source using the SAP CDC connector. To learn more, read the introductory article for [Azure Data Factory](introduction.md) or [Azure Synapse Analytics](../synapse-analytics/overview-what-is.md). For an introduction to transforming data with Azure Data Factory and Azure Synapse analytics, read [mapping data flow](concepts-data-flow-overview.md).

-This SAP CDC connector leverages the SAP ODP framework to extract data from SAP source systems. For an introduction to the architecture of the solution, read [Introduction and architecture to SAP change data capture (CDC)](sap-change-data-capture-introduction-architecture.md) in our [SAP knowledge center](industry-sap-overview.md).

-The SAP ODP framework is contained in most SAP NetWeaver based systems, including SAP ECC, SAP S/4HANA, SAP BW, SAP BW/4HANA, SAP LT Replication Server (SLT), except very old ones. For prerequisites and minimum required releases, see [Prerequisites and configuration](sap-change-data-capture-prerequisites-configuration.md#sap-system-requirements).

-SAP CDC datasets can be used as source in mapping data flow. Since the raw SAP ODP change feed is difficult to interpret and to correctly update to a sink, mapping data flow takes care of this by evaluating technical attributes provided by the ODP framework (e.g., ODQ_CHANGEMODE) automatically. This allows users to concentrate on the required transformation logic without having to bother with the internals of the SAP ODP change feed, the right order of changes, etc.

-Next, specify a staging folder in Azure Data Lake Gen2, which will serve as an intermediate storage for data extracted from SAP.

-1. On the tab **Source settings** select a prepared SAP CDC dataset or select the **New** button to create a new one. Alternatively, you can also select **Inline** in the **Source type** property and continue without defining an explicit dataset.

-1. On the tab **Source options** select the option **Full on every run** if you want to load full snapshots on every execution of your mapping data flow, or **Full on the first run, then incremental** if you want to subscribe to a change feed from the SAP source system. In this case, the first run of your pipeline will do a delta initialization, which means it will return a current full data snapshot and create an ODP delta subscription in the source system so that with subsequent runs, the SAP source system will return incremental changes since the previous run only. You can also do **incremental changes only** if you want to create an ODP delta subscription in the SAP source system in the first run of your pipeline without returning any data, and with subsequent runs, the SAP source system will return incremental changes since the previous run only. In case of incremental loads it is required to specify the keys of the ODP source object in the **Key columns** property.

-1. For the tabs **Projection**, **Optimize** and **Inspect**, please follow [mapping data flow](concepts-data-flow-overview.md).

-1. If **Run mode** is set to **Full on every run** or **Full on the first run, then incremental**, the tab **Optimize** offers additional selection and partitioning options. Each partition condition (the screenshot below shows an example with two conditions) will trigger a separate extraction process in the connected SAP system. Up to three of these extraction process are executed in parallel.

- :::image type="content" source="media/sap-change-data-capture-solution/sap-change-data-capture-mapping-data-flow-optimize-partition.png" alt-text="Screenshot of the partitioning options in optimize of mapping data flow source.":::

-| SAP Data Store | Scenario | Description |

- ```tsql

- ```tsql

- ```tsql

- ```tsql

-If you want to collect security events when you auto-provision the Azure Monitor Agent, you can create a [Data Collection Rule](../azure-monitor/essentials/data-collection-rule-overview.md) to collect the required events.

-# Deploy a bring your own license (BYOL) vulnerability assessment solution

-Supported solutions report vulnerability data to the partner's management platform. In turn, that platform provides vulnerability and health monitoring data back to Defender for Cloud. You can identify vulnerable VMs on the workload protection dashboard and switch to the partner management console directly from Defender for Cloud for reports and more information.

- Your VMs will appear in one or more of the following groups:

- >[!IMPORTANT]

- > Depending on your configuration, you might only see a subset of this list.

- >

- > - If you haven't got a third-party vulnerability scanner configured, you won't be offered the opportunity to deploy it.

- > - If your selected VMs aren't protected by Microsoft Defender for Servers, the Defender for Cloud integrated vulnerability scanner option will be unavailable.

- :::image type="content" source="./media/deploy-vulnerability-assessment-vm/recommendation-remediation-options.png" alt-text="The options for which type of remediation flow you want to choose when responding to the recommendation **A vulnerability assessment solution should be enabled on your virtual machines** recommendation page":::

-1. If you've already set up your BYOL solution, select **Deploy your configured third-party vulnerability scanner**, select the relevant extension, and select **Proceed**.

-|**ResourceGroupName**|Γ£ö|Name of the resource group. Use any existing resource group including the default ("DefaultResourceGroup-xxx").<br>Since the solution isn't an Azure resource, it won't be listed under the resource group, but it's still attached to it. If you later delete the resource group, the BYOL solution will be unavailable.|

-There are multiple Qualys platforms across various geographic locations. The SOC CIDR and URLs will differ depending on the host platform of your Qualys subscription. To identify your Qualys host platform, use this page https://www.qualys.com/platform-identification/.

-When you set up your solution, you must choose a resource group to attach it to. The solution isn't an Azure resource, so it won't be included in the list of the resource groupΓÇÖs resources. Nevertheless, it's attached to that resource group. If you later delete the resource group, the BYOL solution will be unavailable.

- | Red Hat | Enterprise Linux | 5.4+, 6, 7-7.9, 8-8.5, 9 beta |

- 1. In the Monitoring coverage column of the Defender for Servers plan, select **Settings**.

-If you're using a custom workspace and enable the plan on the subscription level only, the `Microsoft Defender for servers should be enabled on workspaces` recommendation will appear on the Recommendations page. This recommendation will give you the option to enable the servers plan on the workspace level with the Fix button. You're charged for all VMs in the subscription even if the Servers plan isn't enabled for the workspace. The VMs won't benefit from features that depend on the Log Analytics workspace, such as Microsoft Defender for Endpoint, VA solution (TVM/Qualys), and Just-in-Time VM access.

- ```bash

- - VA solution (TVM/ Qualys)

-On this page, you'll learn about changes that are planned for Defender for Cloud. It describes planned modifications to the product that might affect things like your secure score or workflows.

-If you're looking for the latest release notes, you'll find them in the [What's new in Microsoft Defender for Cloud](release-notes.md).

-export password=''

-export clusterName=''

-curl -u admin:$password -sS -G "https://$clusterName.azurehdinsight.net/api/v1/clusters/$clusterName/hosts" \

- export componentVersion=Hadoop=3.1.0

-[Subscribe to our release notes](./subscribe-to-hdi-release-notes-repo.md) and watch releases on [this GitHub repository](https://github.com/hdinsight/release-notes/releases).

-* You should have a valid GitHub account to subscribe to this Release Notes notification. For more information on GitHub, [see here](https://github.com).

-1. Go to [GitHub repository](https://github.com/hdinsight/release-notes/releases).

- * **Device Mapping** - Don't change the default values for this quickstart.

- * **Destination Mapping** - Don't change the default values for this quickstart.

- :::image type="content" source="media\deploy-arm-template\iot-deploy-quickstart-options.png" alt-text="Screenshot of Azure portal page displaying deployment options for the Azure Health Data Service MedTech service." lightbox="media\deploy-arm-template\iot-deploy-quickstart-options.png":::

-* Health Data Services MedTech service with the required [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles:

- * For the event hub, the **Azure Event Hubs Data Receiver** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.

- * For the FHIR service, the **FHIR Data Writer** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the FHIR service.

-> [Choose a deployment method for the MedTech service](deploy-new-choose.md)

- - **Device mapping**: Don't change the default values for this tutorial. The mappings are set in the template to send a device message to your IoT hub later in the tutorial.

- - **Destination mapping**: Don't change the default values for this tutorial. The mappings are set in the template to send a device message to your IoT hub later in the tutorial.

-* Health Data Services MedTech service with the required [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/overview.md) roles:

- * For the event hub, the **Azure Event Hubs Data Receiver** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the event hub.

- * For the FHIR service, the **FHIR Data Writer** role is assigned in the [Access control section (IAM)](../../role-based-access-control/overview.md) of the FHIR service.

-* Persist the FHIR Observations to your FHIR service.

-> [Choose a deployment method for the MedTech service](deploy-new-choose.md)

-If you configured the lab to use [advanced networking](how-to-connect-vnet-injection.md), then each lab uses the subnet that was connected to the lab plan and delegated to Azure Lab Services. In this case, you're responsible for creating a [network security group with an inbound security rule to allow RDP and SSH traffic](how-to-connect-vnet-injection.md#associate-delegated-subnet-with-nsg) to the lab virtual machines.

-description: Learn how to connect a lab to one of your networks.

-# Use advanced networking (virtual network injection) to connect to your virtual network in Azure Lab Services

-This article provides information about connecting a lab plan to your virtual network.

-Some organizations have advanced network requirements and configurations that they want to apply to labs. For example, network requirements can include a network traffic control, ports management, access to resources in an internal network, etc. Certain on-premises networks are connected to Azure Virtual Network either through [ExpressRoute](../expressroute/expressroute-introduction.md) or [Virtual Network Gateway](../vpn-gateway/vpn-gateway-about-vpngateways.md). These services must be set up outside of Azure Lab Services. To learn more about connecting an on-premises network to Azure using ExpressRoute, see [ExpressRoute overview](../expressroute/expressroute-introduction.md). For on-premises connectivity using a Virtual Network Gateway, the gateway, specified virtual network, network security group, and the lab plan all must be in the same region.

-In the Azure Lab Services [August 2022 Update](lab-services-whats-new.md), customers may take control of the network for the labs using virtual network (VNet) injection. You can now tell Lab Services which virtual network to use, and we'll inject the necessary resources into your network. With VNet injection, you can connect to on premise resources such as licensing servers and use user defined routes (UDRs). VNet injection replaces the [peering to your virtual network](how-to-connect-peer-virtual-network.md), as was done in previous versions.

-> Advanced networking (VNet injection) must be configured when creating a lab plan. It can't be added later.

-> If your school needs to perform content filtering, such as for compliance with the [Children's Internet Protection Act (CIPA)](https://www.fcc.gov/consumers/guides/childrens-internet-protection-act), you will need to use 3rd party software. For more information, read guidance on [content filtering with Lab Services](./administrator-guide.md#content-filtering).

-Before you configure advanced networking for your lab plan, complete the following tasks:

-1. [Create a virtual network](../virtual-network/quick-create-portal.md). The virtual network must be in the same region as the lab plan.

-1. [Create a subnet](../virtual-network/virtual-network-manage-subnet.md) for the virtual network.

-1. [Delegate the subnet](#delegate-the-virtual-network-subnet-for-use-with-a-lab-plan) to **Microsoft.LabServices/labplans**.

-1. [Create a network security group (NSG)](../virtual-network/manage-network-security-group.md).

-1. [Create an inbound rule to allow traffic from SSH and RDP ports](../virtual-network/manage-network-security-group.md).

-1. [Associate the NSG to the delegated subnet](#associate-delegated-subnet-with-nsg).

-Now that the prerequisites have been completed, you can [use advanced networking to connect your virtual network during lab plan creation](#connect-the-virtual-network-during-lab-plan-creation).

-## Delegate the virtual network subnet for use with a lab plan

-After you create a subnet for your virtual network, you must [delegate the subnet](../virtual-network/subnet-delegation-overview.md) for use with Azure Lab Services.

-Only one lab plan at a time can be delegated for use with one subnet.

-1. Create a [virtual network](../virtual-network/manage-virtual-network.md) and [subnet](../virtual-network/virtual-network-manage-subnet.md).

-2. Open the **Subnets** page for your virtual network.

-3. Select the subnet you wish to delegate to Lab Services and open the property window for that subnet.

-4. For the **Delegate subnet to a service** property, select **Microsoft.LabServices/labplans**. Select **Save**.

- :::image type="content" source="./media/how-to-connect-vnet-injection/delegate-subnet-for-azure-lab-services.png" alt-text="Screenshot of properties windows for subnet. The Delegate subnet to a service property is highlighted and set to Microsoft dot Lab Services forward slash lab plans.":::

-5. Verify the lab plan service appears in the **Delegated to** column.

- :::image type="content" source="./media/how-to-connect-vnet-injection/delegated-subnet.png" alt-text="Screenshot of list of subnets for a virtual network. The Delegated to and Security group columns are highlighted." lightbox="./media/how-to-connect-vnet-injection/delegated-subnet.png":::

-## Associate delegated subnet with NSG

-> [!WARNING]

-> An NSG with inbound rules for RDP and/or SSH is required to allow access to the template and lab VMs.

-For connectivity to lab VMs, it's required to associate an NSG with the subnet delegated to Lab Services. We'll create an NSG, add an inbound rule to allow both SSH and RDP traffic, and then associate the NSG with the delegated subnet.

-1. [Create a network security group (NSG)](../virtual-network/manage-network-security-group.md), if not done already.

-2. Create an inbound security rule allowing RDP and SSH traffic.

- 1. Select **Inbound security rules** on the left menu.

- 2. Select **+ Add** from the top menu bar. Fill in the details for adding the inbound security rule as follows:

- 1. For **Source**, select **Any**.

- 2. For **Source port ranges**, select **\***.

- 3. For **Destination**, select **IP Addresses**.

- 4. For **Destination IP addresses/CIDR ranges**, select subnet range previously created subnet.

- 5. For **Service**, select **Custom**.

- 6. For **Destination port ranges**, enter **22, 3389**. Port 22 is for Secure Shell protocol (SSH). Port 3389 is for Remote Desktop Protocol (RDP).

- 7. For **Protocol**, select **Any**.

- 8. For **Action**, select **Allow**.

- 9. For **Priority**, select **1000**. Priority must be higher than other **Deny** rules for RDP and/or SSH.

- 10. For **Name**, enter **AllowRdpSshForLabs**.

- 11. Select **Add**.

- :::image type="content" source="media/how-to-connect-vnet-injection/nsg-add-inbound-rule.png" lightbox="media/how-to-connect-vnet-injection/nsg-add-inbound-rule.png" alt-text="Screenshot of Add inbound rule window for Network security group.":::

- 3. Wait for the rule to be created.

- 4. Select **Refresh** on the menu bar. Our new rule will now show in the list of rules.

-3. Associate the NSG with the delegated subnet.

- 1. Select **Subnets** on the left menu.

- 1. Select **+ Associate** from the top menu bar.

- 1. On the **Associate subnet** page, do the following actions:

- 1. For **Virtual network**, select previously created virtual network.

- 2. For **Subnet**, select previously created subnet.

- 3. Select **OK**.

- :::image type="content" source="media/how-to-connect-vnet-injection/associate-nsg-with-subnet.png" lightbox="media/how-to-connect-vnet-injection/associate-nsg-with-subnet.png" alt-text="Screenshot of Associate subnet page in the Azure portal.":::

-1. Enter required information on the **Basics** tab of the **Create a lab plan** page. For more information, see [Create a lab plan with Azure Lab Services](quick-create-resources.md).

-1. From the **Basics** tab of the **Create a lab plan** page, select **Next: Networking** at the bottom of the page.

-1. Select **Enable advanced networking**.

- 1. For **Virtual network**, select an existing virtual network for the lab network. For a virtual network to appear in this list, it must be in the same region as the lab plan.

- 2. Specify an existing **subnet** for VMs in the lab. For subnet requirements, see [Delegate the virtual network subnet for use with a lab plan](#delegate-the-virtual-network-subnet-for-use-with-a-lab-plan).

- :::image type="content" source="./media/how-to-connect-vnet-injection/create-lab-plan-advanced-networking.png" alt-text="Screenshot of the Networking tab of the Create a lab plan wizard.":::

-Once you have a lab plan configured with advanced networking, all labs created with this lab plan use the specified subnet.

-See the following articles:

-* **Chain** - A Gateway Load Balancer can be referenced by a Standard Public Load Balancer frontend or a Standard Public IP configuration on a virtual machine. The addition of advanced networking capabilities in a specific sequence is known as service chaining. As a result, this reference is called a chain. In order to chain a Load Balancer frontend or Public IP configuration to a Gateway Load Balancer that is cross-subscription, users will need permission for the resource provider operation "Microsoft.Network/loadBalancers/frontendIPConfigurations/join/action". For cross-tenant chaining, the user will also need Guest access.

-IMDS (Azure Instance Metadata Service) provides information about currently running virtual machine instances. The service is a REST API that's available at a well-known, non-routable IP address (169.254.169.254).

-|DifferentSkuLoadBalancerAndPublicIPAddressNotAllowedInVMSS | Virtual machine scale sets default to Basic Load Balancers when SKU is unspecified or deployed without Standard Public IPs. Re-deploy virtual machine scale set with Standard Public IPs on the individual instances to ensure Standard Load Balancer is selected or simply select a Standard LB when deploying virtual machine scale set from the Azure portal. |

-|MaxAvailabilitySetsInLoadBalancerReached | The backend pool of a Load Balancer can contain a maximum of 150 availability sets. If you don't have availability sets explicitly defined for your VMs in the backend pool, each single VM goes into its own Availability Set. So deploying 150 standalone VMs would imply that it would have 150 Availability sets, thus hitting the limit. You can deploy an availability set and add additional VMs to it as a workaround. |

-|RulesOfSameLoadBalancerTypeUseSameBackendPortProtocolAndIPConfig| You cannot have more than one rule on a given load balancer type (internal, public) with same backend port and protocol referenced by same virtual machine scale set. Update your rule to change this duplicate rule creation. |

-|RulesOfSameLoadBalancerTypeUseSameBackendPortProtocolAndVmssIPConfig| You cannot have more than one rule on a given load balancer type (internal, public) with same backend port and protocol referenced by same virtual machine scale set. Update your rule parameters to change this duplicate rule creation. |

-|AnotherInternalLoadBalancerExists| You can have only one Load Balancer of type internal reference the same set of VMs/network interfaces in the backend of the Load Balancer. Update your deployment to ensure you are creating only one Load Balancer of the same type. |

-|CannotUseInactiveHealthProbe| You cannot have a probe that's not used by any rule configured for virtual machine scale set health. Ensure that the probe that is set up is being actively used. |

-|VMScaleSetCannotUseMultipleLoadBalancersOfSameType| You cannot have multiple Load Balancers of the same type (internal, public). You can have a maximum of one internal and one public Load Balancer. |

-|VMScaleSetCannotReferenceLoadbalancerWhenLargeScaleOrCrossAZ | Basic Load Balancer is not supported for multiple-placement group virtual machine scale sets or cross-availability zone virtual machine scale set. Use Standard Load Balancer instead. |

-|LoadBalancerWithoutFrontendIPCantHaveChildResources | A Load Balancer resource that has no frontend IP configurations, cannot have associated child resources or components associated to it. In order to mitigate this error, add a frontend IP configuration and then add the resources you are trying to add. |

-| LoadBalancerRuleCountLimitReachedForNic | A backend pool member's network interface (virtual machine, virtual machine scale set) cannot be associated to more than 300 rules. Reduce the number of rules or leverage another Load Balancer. This limit is documented on the [Load Balancer limits page](../azure-resource-manager/management/azure-subscription-service-limits.md#load-balancer).

-| LoadBalancerInUseByVirtualMachineScaleSet | The Load Balancer resource is in use by a virtual machine scale set and cannot be deleted. Use the ARM ID provided in the error message to search for the virtual machine scale set in order to delete it. |

-Azure Load Balancer rules require a health probe to detect the endpoint status. The configuration of the health probe and probe responses determines which backend pool instances will receive new connections. Use health probes to detect the failure of an application. Generate a custom response to a health probe. Use the health probe for flow control to manage load or planned downtime. When a health probe fails, the load balancer will stop sending new connections to the respective unhealthy instance. Outbound connectivity isn't affected, only inbound.

-The interval value determines how frequently the health probe will probe for a response from your backend pool instances. If the health probe fails, it will immediately mark your backend pool instances as unhealthy. On the next healthy probe up, the health probe will immediately mark your backend pool instances as healthy.

-For this example, once detection has occurred, the platform will take a small amount of time to react to the change.

-Assume the reaction to a time-out response will take a minimum of 5 seconds and a maximum of 10 seconds to react to the change.

-New TCP connections will succeed to remaining healthy backend endpoint.

-If a backend endpoint's health probe fails, established TCP connections to this backend endpoint continue. However, if a backend pool only contains a single endpoint, then existing flows will terminate.

-If all probes for all instances in a backend pool fail, no new flows will be sent to the backend pool. Standard Load Balancer will permit established TCP flows to continue given that a backend pool has more than one backend endpoint. Basic Load Balancer will terminate all existing TCP flows to the backend pool.

-Load Balancer is a pass through service. Load Balancer doesn't terminate TCP connections. The flow is always between the client and the VM's guest OS and application. A pool with all probes down results in a frontend that won't respond to TCP connection open attempts. There isn't a healthy backend endpoint to receive the flow and respond with an acknowledgment.

-UDP datagrams will be delivered to healthy backend endpoints.

-UDP is connection-less and there's no flow state tracked for UDP. If any backend endpoint's health probe fails, existing UDP flows will move to another healthy instance in the backend pool.

-If all probes for all instances in a backend pool fail, existing UDP flows will terminate for basic and standard load balancers.

-Load Balancer uses a distributed probing service for its internal health model. The probing service resides on each host where VMs and can be programmed on-demand to generate health probes per the customer's configuration. The health probe traffic is directly between the probing service that generates the health probe and the customer VM. All IPv4 Load Balancer health probes originate from the IP address 168.63.129.16 as their source. (Note that IPv6 probes use a [link-local address](https://www.wikipedia.org/wiki/Link-local_address) as their source.)

-* It can be useful for your application to generate a health probe response, and signal the load balancer whether your instance should receive new connections. You can manipulate the probe response to throttle delivery of new connections to an instance by failing the health probe. You can prepare for maintenance of your application and initiate draining of connections to your application. A [probe down](#probe-down-behavior) signal will always allow TCP flows to continue until idle timeout or connection closure in a Standard Load Balancer.

-* Don't translate or proxy a health probe through the instance that receives the health probe to another instance in your virtual network. This configuration can lead to cascading failures in your scenario. For example: A set of third-party appliances is deployed in the backend pool of a load balancer to provide scale and redundancy for the appliances. The health probe is configured to probe a port that the third-party appliance proxies or translates to other virtual machines behind the appliance. If you probe the same port used to translate or proxy requests to the other virtual machines behind the appliance, any probe response from a single virtual machine will mark down the appliance. This configuration can lead to a cascading failure of the application. The trigger can be an intermittent probe failure that will cause the load balancer to mark down the appliance instance. This action can disable your application. Probe the health of the appliance itself. The selection of the probe to determine the health signal is an important consideration for network virtual appliances (NVA) scenarios. Consult your application vendor for the appropriate health signal is for such scenarios.

-* If you don't allow the [source IP](#probe-source-ip-address) of the probe in your firewall policies, the health probe will fail as it is unable to reach your instance. In turn, Load Balancer will mark down your instance due to the health probe failure. This misconfiguration can cause your load balanced application scenario to fail.

-* Don't configure your virtual network with the Microsoft owned IP address range that contains 168.63.129.16. The configuration will collide with the IP address of the health probe and can cause your scenario to fail.

-* Don't enable [TCP timestamps](https://tools.ietf.org/html/rfc1323). TCP timestamps can cause health probes to fail due to TCP packets being dropped by the VM's guest OS TCP stack. The dropped packets can cause the load balancer to mark the endpoint as down. TCP timestamps are routinely enabled by default on security hardened VM images and must be disabled.

-Public and internal [Standard Load Balancer](./load-balancer-overview.md) expose per endpoint and backend endpoint health probe status through [Azure Monitor](./monitor-load-balancer.md). These metrics can be consumed by other Azure services or partner applications.

-Azure Monitor logs aren't available for both public and internal Basic Load Balancers.

-* You should assume health probes will fail when TCP timestamps are enabled.

-## Region availability

-The HA ports feature is available in all the global Azure regions.

-### A single, non-floating IP (non-Direct Server Return) HA-ports configuration on an internal standard load balancer

-With this configuration, you can add more floating IP load-balancing rules and/or a public load balancer. However, you can't use a non-floating IP, HA-ports load-balancing configuration on top of this configuration.

-A Load Balancer can either be **zone redundant, zonal,** or **non-zonal**. To configure the zone-related properties (mentioned above) for your load balancer, select the appropriate type of frontend needed.

-In a region with Availability Zones, a Standard Load Balancer can be zone-redundant. This traffic is served by a single IP address.

-A single frontend IP address will survive zone failure. The frontend IP may be used to reach all (non-impacted) backend pool members no matter the zone. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy.

-You can choose to have a frontend guaranteed to a single zone, which is known as a *zonal*. This scenario means any inbound or outbound flow is served by a single zone in a region. Your frontend shares fate with the health of the zone. The data path is unaffected by failures in zones other than where it was guaranteed. You can use zonal frontends to expose an IP address per Availability Zone.

-In the case where a region is augmented to have [availability zones](../availability-zones/az-overview.md), any existing IPs would remain non-zonal like IPs used for load balancer frontends. To ensure your architecture can take advantage of the new zones, creation of new frontend IPs is recommended. Once created, you can replace the existing non-zonal frontend with a new zone-redundant frontend using the method described [here](../virtual-network/ip-services/configure-public-ip-load-balancer.md#change-or-remove-public-ip-address). All existing load balancing and NAT rules will transition to the new frontend.

-2. In the **Metric** drop-down list, select **Data Path Availability**.

-3. In the **Aggregation** drop-down list, select **Avg**.

-4. Additionally, add a filter on the frontend IP address or frontend port as the dimension with the required front-end IP address or front-end port, and then group them by the selected dimension.

-The used SNAT ports metric tracks how many SNAT ports are being consumed to maintain outbound flows. This indicates how many unique flows are established between an internet source and a backend VM or virtual machine scale set that is behind a load balancer and doesnΓÇÖt have a public IP address. By comparing the number of SNAT ports youΓÇÖre using with the Allocated SNAT Ports metric, you can determine if your service is experiencing or at risk of SNAT exhaustion and resulting outbound flow failure.

- * By default these metrics are the average number of SNAT ports allocated to or used by each backend VM or virtual machine scale set, corresponding to all frontend public IPs mapped to the load balancer, aggregated over TCP and UDP.

-1. Go to the alert sub-blade for the load balancer

- 1. Configure alert condition (Note: to avoid noisy alerts, we recommend configuring alerts with the Aggregation type set to Average, looking back on a 5 minute window of data, and with a threshold of 95%)

-To alert for inbound availability, you can create two separate alerts using the data path availability and health probe status metrics. Customers may have different scenarios that require specific alerting logic, but the below examples will be helpful for most configurations.

-With health probe status you can alert when a given backend instance fails to respond to the health probe for a significant amount of time. Set up your alert condition to use the health probe status metric and split by backend IP address and backend port. This will ensure that you can alert separately for each individual backend instanceΓÇÖs ability to serve traffic on a specific port. Use the **Average** aggregation type and set the threshold value according to how frequently your backend instance is probed and what you consider to be your healthy threshold.

-You can also alert on a backend pool level by not splitting by any dimensions and using the **Average** aggregation type. This will allow you to set up alert rules such as alert when 50% of my backend pool members are unhealthy.

-To configure for outbound availability, you can configure two separate alerts using the SNAT connection count and used SNAT port metrics.

-To detect outbound connection failures, configure an alert using SNAT connection count and filtering to **Connection State = Failed**. Use the **Total** aggregation. You can then also split this by backend IP address set to all current and future values to alert separately for each backend instance experiencing failed connections. Set the threshold to be greater than zero or a higher number if you expect to see some outbound connection failures.

-With used SNAT ports you can alert on a higher risk of SNAT exhaustion and outbound connection failure. Ensure youΓÇÖre splitting by backend IP address and protocol when using this alert. Use the **Average** aggregation. Set the threshold to be greater than a percentage of the number of ports youΓÇÖve allocated per instance that you determine is unsafe. For example, configure a low severity alert when a backend instance uses 75% of its allocated ports. Configure a high severity alert when it uses 90% or 100% of its allocated ports.

-| Degraded | Your standard load balancer has platform or user initiated events impacting performance. The metric for data path availability has reported less than 90% but greater than 25% health for at least two minutes. YouΓÇÖll experience moderate to severe performance effect. [Follow the troubleshooting RHC guide](./troubleshoot-rhc.md) to determine whether there are user initiated events causing impacting your availability.

-| Unavailable | Your standard load balancer resource isnΓÇÖt healthy. The metric for data path availability has reported less the 25% health for at least two minutes. YouΓÇÖll experience significant performance effect or lack of availability for inbound connectivity. There may be user or platform events causing unavailability. [Follow the troubleshooting RHC guide](./troubleshoot-rhc.md) to determine whether there are user initiated events impacting your availability. |

-When Virtual Machine Scale Sets with [public IPs per instance](../virtual-machine-scale-sets/virtual-machine-scale-sets-networking.md) are created with a load balancer in front, the SKU of the instance IPs is determined by the SKU of the Load Balancer (i.e. Basic or Standard).

-description: This article explains how to configure outbound rules to control egress of internet traffic with Azure Load Balancer.

-The operation to configure an outbound rule will fail if you attempt to redefine an IP address that is used for inbound. Disable the outbound NAT of the load-balancing rule first.

-Load balancer gives [SNAT](load-balancer-outbound-connections.md) ports in multiples of 8. If you provide a value not divisible by 8, the configuration operation is rejected. Each load balancing rule and inbound NAT rule will consume a range of eight ports. If a load balancing or inbound NAT rule shares the same range of 8 as another, no extra ports will be consumed.

-| **Global VNet Peering Support** | Standard ILB is supported via Global VNet Peering | Not supported |

-| **[NAT Gateway Support](../virtual-network/nat-gateway/nat-overview.md)** | Both Standard ILB and Standard Public LB are supported via Nat Gateway | Not supported |

-| **[Private Link Support](../private-link/private-link-overview.md)** | Standard ILB is supported via Private Link | Not supported |

-| **[Global tier (Preview)](./cross-region-overview.md)** | Standard LB supports the Global tier for Public LBs enabling cross-region load balancing | Not supported |

-* Storage Accounts: Azure Blog Storage/Azure Files/Azure Table Storage/Queue Storage

-```python

-endpoint = ml_client.online_endpoints.get(endpoint_name)

-# define the path containing the delta table (where the _delta_log file is stored)

-Batch endpoints inherent the networking configuration from the workspace where they are deployed. All the batch endpoints created inside of secure workspace are deployed as private batch endpoints by default. In order to have fully operational batch endpoints working with private networking, follow the following steps:

-4. Create the batch endpoint as regularly done.

-2. Ensure all related services have private endpoints configured in the network. Private endpoints are used for not only Azure Machine Learning workspace, but also its associated resources such as Azure Storage, Azure Key Vault, or Azure Container Registry. Azure Container Registry is a required service. While securing the Azure Machine Learning workspace with virtual networks, please note that there are [some prerequisites about Azure Container Registry](how-to-secure-workspace-vnet.md#prerequisites).

-4. If your compute instance uses a public IP address, you must [Allow inbound communication](how-to-secure-training-vnet.md#compute-instancecluster-with-public-ip) so that management services can submit jobs to your compute resources.

-## Using two-networks architecture

-There are cases where the input data is not in the same network as in the Azure Machine Learning resources. In those cases, your Azure Machine Learning workspace may need to interact with more than one VNet. You can achieve this configuration by adding an extra set of private endpoints to the VNet where the rest of the resources are located.

-The following diagram shows the high level design:

-### Considerations

-Have the following considerations when using such architecture:

-* Put the second set of private endpoints in a different resource group and hence in different private DNS zones. It prevents a name resolution conflict between the set of IPs used for the workspace and the ones used by the client VNets. Azure Private DNS provides a reliable, secure DNS service to manage and resolve domain names in a virtual network without the need to add a custom DNS solution. By using private DNS zones, you can use your own custom domain names rather than the Azure-provided names available today. Note that the DNS resolution against a private DNS zone works only from virtual networks that are linked to it. For more details, see [recommended zone names for Azure services](../private-link/private-endpoint-dns.md#azure-services-dns-zone-configuration).

-* For your storage accounts, add 4 private endpoints in each VNet for blob, file, queue, and table as explained at [Secure Azure storage accounts](how-to-secure-workspace-vnet.md#secure-azure-storage-accounts).

- :::image type="content" source="media/interactive-data-wrangling-with-apache-spark-azure-ml/how_to_enable_managed_spark_preview.png" alt-text="Screenshot showing option for enabling Managed Spark preview.":::

-Data-in replication allows you to synchronize data from an external MySQL server into an Azure Database for MySQL flexilbe server. The external server can be on-premises, in virtual machines, Azure Database for MySQL single server, or a database service hosted by other cloud providers. Data-in replication is based on the binary log (binlog) file position-based. To learn more about binlog replication, see the [MySQL binlog replication overview](https://dev.mysql.com/doc/refman/5.7/en/binlog-replication-configuration-overview.html).

-> GTID-based replication is currently not supported for Azure Database for MySQL - Flexible Servers.<br>

-> Configuring Data-in replication for zone-redundant high-availability servers is not supported.

-### Data-in replication not supported on High Availability (HA) enabled servers

-It isn't supported to configure Data-in replication for servers that have high availability (HA) option enabled. On HA-enabled servers, the stored procedures for replication `mysql.az_replication_*` won't be available.

-> [!TIP]

-> If you are using the HA server as a source server, MySQL native binary log (binlog) file position-based replication will fail when failover happens on the server. If replica server supports GTID based replication, we should configure GTID based replication.

-Parameter `replicate_wild_ignore_table` is used to create replication filter for tables on the replica server. To modify this parameter from Azure portal, navigate to Azure Database for MySQL flexible server used as replica and select "Server Parameters" to view/edit the `replicate_wild_ignore_table` parameter.

-The first thing we'll create is a managed MySQL server. In [Azure Cloud Shell](https://shell.azure.com/), run the following script and make a note of the **server name**, **username** and **password** generated from this command.

-```azurecli

-You can provide additional arguments for this command to customize it. See all arguments for [az mysql flexible-server create](/cli/azure/mysql/flexible-server#az-mysql-flexible-server-create).

-Run the following command to create a database, **newdatabase** if you have not already created one.

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-You will see the **MySQL** shell experience as shown below:

-```bash

-```azurecli

-```azurecli

-You will see an output as shown below:

-```azurecli

-```azurecli

-You will see an output as shown below:

-```

-```azurecli

-```bash

-```bash

-```azurecli

-```bash

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-cat /etc/resolv.conf

-```azurecli

-```azurecli

-```azurecli

-This script sample creates a virtual network with front-end and back-end subnets. Inbound network traffic to the front-end subnet is limited to HTTP, and HTTPS, while outbound traffic to the Internet from the back-end subnet is not permitted. After running the script, you will have one virtual machine with two NICs. Each NIC is connected to a different subnet.

-Additional networking PowerShell script samples can be found in the [Azure Networking Overview documentation](../powershell-samples.md?toc=%2fazure%2fnetworking%2ftoc.json).

-description: Instructional for the inputs and methods for creating, updating, retrieving, and deleting cluster metrics configurations.

-When the user deploys a Cluster, a standard set of metrics are enabled for collection. For the list of metrics, see

-* The `collectionInterval` field is required, `enabledMetrics` is optional and may be omitted.

-### Metrics configuration elements

-| METRIC_TO_ENABLE_1 | Optional metric1 that is enabled in addition to the default metrics |

-| METRIC_TO_ENABLE_2 | Optional metric2 that is enabled in addition to the default metrics |

-## Retrieving a metrics configuration

-After a metrics configuration is created, it can be retrieved using a `az rest` command:

-## Updating a metrics configuration

-Much like the creation of a metrics configuration, an update can be performed to change the configuration or update the tags assigned to the metrics configuration.

-The `collection-interval` can be updated independently of `enabled-metrics` list. Omit fields that aren't being changed.

-## Deleting a metrics configuration

-Deletion of the metrics configuration returns the cluster to an unaltered configuration. To delete a metrics configuration, use the below command:

-| Australia Central| 20.36.105.0 | 20.36.105.32/29 |

-| Australia Central2 | 20.36.113.0 | 20.36.113.32/29 |

-| Australia East | 13.75.149.87, 40.79.161.1 | 13.70.112.32/29, 40.79.160.32/29, 40.79.168.32/29 |

-| Australia South East |13.77.48.10, 13.77.49.32, 13.73.109.251 |13.77.49.32/29 |

-| Canada East | 40.86.226.166, 52.242.30.154 | 40.69.105.32/29 |

-| India Central | 104.211.96.159 | 104.211.86.32/29, 20.192.96.32/29|

-| India South | 104.211.224.146 | 40.78.192.32/29, 40.78.193.32/29|

-| Japan West | 104.214.148.156, 40.74.96.6, 40.74.96.7 | 40.74.96.32/29 |

-| UK West | 51.141.8.11 | 51.140.208.96/29, 51.140.209.32/29 |

-| West Central US | 13.78.145.25, 52.161.100.158 | 13.71.193.32/29 |

-Run the following commands at the PowerShell prompt, specifying the object ID you identified in [Complete the prerequisite tasks for deploying a private mobile network](complete-private-mobile-network-prerequisites.md).

-You should see the new **Custom Location** visible as a resource in the Azure portal within the specified resource group. Using the `kubectl get pods -A` command (with access to your *kubeconfig* file) should also show new pods corresponding to the extensions that have been installed. There should be one pod in the *azurehybridnetwork* namespace, and one in the *packet-core-monitor* namespace.

-# Modify the packet core instance in a site

-description: The Classic deployment model, now superseded by the Resource Manager model, enforces a global vCPU quota limit for VMs and virtual machine scale sets.

-# Increase a VM-family vCPU quota for the Classic deployment model

-The Classic deployment model is the older generation Azure deployment model. It enforces a global vCPU quota limit for virtual machines and virtual machine scale sets. The Classic deployment model is no longer recommended, and is now superseded by the Resource Manager model.

-To learn more about these two deployment models and the advantages of using Resource Manager, see [Resource Manager and classic deployment](../azure-resource-manager/management/deployment-models.md).

-When a new subscription is created, a default quota of vCPUs is assigned to it. Any time a new virtual machine is deployed using the Classic deployment model, the sum of new and existing vCPU usage across all regions must not exceed the vCPU quota approved for the Classic deployment model.

-You can request vCPU quota increases for the Classic deployment model in the Azure portal by using **Help + support** or **Usage + quotas**.

-## Request quota increase for the Classic deployment model using Help + support

-Follow the instructions below to create a vCPU quota increase request for the Classic deployment model by using **Help + support** in the Azure portal.

-1. Sign in to the [Azure portal](https://portal.azure.com), and [open a new support request](../azure-portal/supportability/how-to-create-azure-support-request.md).

-1. For **Issue type**, choose **Service and subscription limits (quotas)**.

-1. Select the subscription that needs an increased quota.

-1. For **Quota type**, select **Compute-VM (cores-vCPUs) subscription limit increases**. Then select **Next**.

- :::image type="content" source="media/resource-manager-core-quotas-request/new-per-vm-quota-request.png" alt-text="Screenshot showing a support request to increase a VM-family vCPU quota in the Azure portal.":::

-1. In the **Problem details** section, select **Enter details**. For deployment model, select **Classic**, then select a location.

-1. For **SKU family**, select one or more SKU families to increase.

-1. Enter the new limits you would like on the subscription. When you're finished, select **Save and continue** to continue creating your support request.

-1. Complete the rest of the **Additional information** screen, and then select **Next**.

-1. On the **Review + create** screen, review the details that you'll send to support, and then select **Create**.

-## Request quota increase for the Classic deployment model from Usage + quotas

-Follow the instructions below to create a vCPU quota increase request for the Classic deployment model from **Usage + quotas** in the Azure portal.

-1. From https://portal.azure.com, search for and select **Subscriptions**.

-1. Select the subscription that needs an increased quota.

-1. Select **Usage + quotas**.

-1. In the upper right corner, select **Request increase**.

-1. Follow the steps above (starting at step 4) to complete your request.

-## Next steps

-The table below lists API endpoints in Azure vs. Azure in China for accessing and managing some of the more common services.

-| Sign in with PowerShell: <br>- Azure classic portal <br>- Azure Resource Manager <br>- Azure AD| - Add-AzureAccount<br>- Connect-AzureRmAccount <br> - Connect-msolservice |  - Add-AzureAccount -Environment AzureChinaCloud <br> - Connect-AzureRmAccount -Environment AzureChinaCloud <br>- Connect-msolservice -AzureEnvironment AzureChinaCloud |

-> | `azure_files_storage_account_id` | If provided the Azure resource ID of the storage account for Azure Files | Optional |

-High availability configurations use Pacemaker with Azure fencing agents. The fencing agents should be configured to use a unique service principal with permissions to stop and start virtual machines. For more information, see [Create Fencing Agent](../../virtual-machines/workloads/sap/high-availability-guide-suse-pacemaker.md#create-an-azure-fence-agent-device)

-As a part of the SAP automation framework control plane, you can optionally create an interactive web application that will assist you in creating the required configuration files and deploying SAP workload zones and systems using Azure Pipelines.

-### Deploying a workload zone or system object (Azure DevOps Pipelines deployment)

-This step is optional. If you would like a browser-based UX to assist in the configuration of SAP workload zones and systems, run the following commands before deploying the control plane.

- --enable-id-token-issuance true `

- --sign-in-audience AzureADMyOrg `

-It is currently not possible to perform this action from Azure DevOps.

-The sample Deployer configuration file `MGMT-WEEU-DEP00-INFRASTRUCTURE.tfvars` is located in the `~/Azure_SAP_Automated_Deployment/WORKSPACES/DEPLOYER/MGMT-WEEU-DEP00-INFRASTRUCTURE` folder.

-The sample SAP Library configuration file `MGMT-WEEU-SAP_LIBRARY.tfvars` is located in the `~/Azure_SAP_Automated_Deployment/WORKSPACES/LIBRARY/MGMT-WEEU-SAP_LIBRARY` folder.

-Running the command below will create the Deployer, the SAP Library and add the Service Principal details to the deployment key vault. If you followed the web app setup in the step above, this command will also create the infrastructure to host the application.

-```bash

-cd ~/Azure_SAP_Automated_Deployment

-cp -Rp sap-automation/samples/WORKSPACES WORKSPACES

-```

-cd ~/Azure_SAP_Automated_Deployment/WORKSPACES

- export region_code="<region_code>"

- ${DEPLOYMENT_REPO_PATH}/deploy/scripts/prepare_region.sh \

- --deployer_parameter_file DEPLOYER/${env_code}-${region_code}-DEP00-INFRASTRUCTURE/${env_code}-${region_code}-DEP00-INFRASTRUCTURE.tfvars \

- --library_parameter_file LIBRARY/${env_code}-${region_code}-SAP_LIBRARY/${env_code}-${region_code}-SAP_LIBRARY.tfvars \

- --subscription "${subscriptionId}" \

- --spn_id "${spn_id}" \

- --spn_secret "${spn_secret}" \

- --tenant_id "${tenant_id}" \

-You can copy the sample configuration files to start testing the deployment automation framework.

-```powershell

-cd C:\Azure_SAP_Automated_Deployment

-xcopy /E sap-automation\samples\WORKSPACES WORKSPACES

-```

-```powershell

-$subscription="<subscriptionID>"

-$appId="<appID>"

-$spn_secret="<password>"

-$tenant_id="<tenant>"

-cd C:\Azure_SAP_Automated_Deployment\WORKSPACES

-New-SAPAutomationRegion -DeployerParameterfile .\DEPLOYER\MGMT-WEEU-DEP00-INFRASTRUCTURE\MGMT-WEEU-DEP00-INFRASTRUCTURE.tfvars -LibraryParameterfile .\LIBRARY\MGMT-WEEU-SAP_LIBRARY\MGMT-WEEU-SAP_LIBRARY.tfvars -Subscription $subscription -SPN_id $appId -SPN_password $spn_secret -Tenant_id $tenant_id

-```

-> [!NOTE]

-> Be sure to replace the sample value `<subscriptionID>` with your subscription ID.

-> Replace the `<appID>`, `<password>`, `<tenant>` values with the output values of the SPN creation

-The deployment will use the configuration defined in the Terraform variable files located in the 'samples/WORKSPACES/DEPLOYER/MGMT-WEEU-DEP00-INFRASTRUCTURE' and 'samples/WORKSPACES/LIBRARY/MGMT-WEEU-SAP_LIBRARY' folders.

-mkdir -p ~/Azure_SAP_Automated_Deployment

-cd ~/Azure_SAP_Automated_Deployment

-git clone https://github.com/Azure/sap-automation.git

-The script will install Terraform and Ansible and configure the deployer.

-1. Connect to the deployer VM through any SSH client such as VSCode. Use the private IP address of the deployer, and the SSH key you downloaded. For instructions on how to connect to the Deployer using VSCode see [Connecting to Deployer using VSCode](tools-configuration.md#configuring-visual-studio-code). If you're using PuTTY, convert the SSH key file first using PuTTYGen.

-mkdir -p ~/Azure_SAP_Automated_Deployment

-cd ~/Azure_SAP_Automated_Deployment

-git clone https://github.com/Azure/sap-automation.git

-The script will install Terraform and Ansible and configure the deployer.

-## Deploy the Control Plane Web Application

-> [!IMPORTANT]

-> Control Plane Web Application is currently in PREVIEW and not yet available in the main branch.

-

-If you would like to use the web app, follow the steps below. If not, ignore this section.

-The web app resource can be found in the deployer resource group. In the Azure portal, select resource groups in your subscription. The deployer resource group will be named something like MGMT-[region]-DEP00-INFRASTRUCTURE. Inside the deployer resource group, locate the app service, named something like mgmt-[region]-dep00-sapdeployment123. Open the app service and copy the URL listed. It should be in the format of https://mgmt-[region]-dep00-sapdeployment123.azurewebsites.net. This will be the value for webapp_url below.

-The following commands will configure the application urls, generate a zip file of the web app code, deploy the software to the app service, and configure the application settings.

-# [Linux](#tab/linux)

-```bash

-webapp_url=<webapp_url>

-az ad app update \

- --id $TF_VAR_app_registration_app_id \

- --web-home-page-url ${webapp_url} \

- --web-redirect-uris ${webapp_url}/ ${webapp_url}/.auth/login/aad/callback

-```

-# [Windows](#tab/windows)

-```powershell

-$webapp_url="<webapp_url>"

-az ad app update `

- --id $TF_VAR_app_registration_app_id `

- --web-home-page-url $webapp_url `

- --web-redirect-uris $webapp_url/ $webapp_url/.auth/login/aad/callback

-```

-# [Azure DevOps](#tab/devops)

-It is currently not possible to perform this action from Azure DevOps.

-> [!TIP]

-> Perform the following task from the deployer.

-```bash

-cd ~/Azure_SAP_Automated_Deployment/sap-automation/Webapp/AutomationForm

-dotnet build

-dotnet publish --configuration Release

-cd bin/Release/netcoreapp3.1/publish/

-sudo apt install zip

-zip -r deploymentfile.zip .

-az webapp deploy --resource-group <group-name> --name <app-name> --src-path deploymentfile.zip

-```

-```bash

-az webapp config appsettings set -g <group-name> -n <app-name> --settings \

-IS_PIPELINE_DEPLOYMENT=false

-```

-## Accessing the web app

-By default there will be no inbound public internet access to the web app apart from the deployer virtual network. To allow additional access to the web app, navigate to the Azure portal. In the deployer resource group, find the web app. Then under settings on the left hand side, click on networking. From here, click Access restriction. Add any allow or deny rules you would like. For more information on configuring access restrictions, see [Set up Azure App Service access restrictions](../../app-service/app-service-ip-restrictions.md).

-You will also need to grant reader permissions to the app service system-assigned managed identity. Navigate to the app service resource. On the left hand side, click "Identity". In the "system assigned" tab, click on "Azure role assignments" > "Add role assignment". Select "subscription" as the scope, and "reader" as the role. Then click save. Without this step, the web app dropdown functionality will not work.

-You can log in and visit the web app by following the URL from earlier or clicking browse inside the app service resource. With the web app, you are able to configure SAP workload zones and system infrastructure. Click download to obtain a parameter file of the workload zone or system you specified, for use in the later deployment steps.

-mkdir ~/Azure_SAP_Automated_Deployment/config; cd $_

-git clone https://github.com/Azure/sap-automation-bootstrap.git

-mkdir ~/Azure_SAP_Automated_Deployment/sap-automation; cd $_

-git clone https://github.com/Azure/sap-automation.git

-mkdir ~/Azure_SAP_Automated_Deployment/samples; cd $_

-git clone https://github.com/Azure/sap-automation-samples.git

-This guide helps you to point to the right resources to deploy HANA in Azure virtual machines successfully. This guide is going to point you to documentation resources that you need to check before installing SAP HANA in an Azure VM. So, that you are able to perform the right steps to end with a supported configuration of SAP HANA in Azure VMs.

-> This guide describes deployments of SAP HANA into Azure VMs. For information on how to deploy SAP HANA into HANA large instances, see [How to install and configure SAP HANA (Large Instances) on Azure](../../virtual-machines/workloads/sap/hana-installation.md).

-In this section, the different steps are listed that you need to perform before starting with the installation of SAP HANA in an Azure virtual machine. The order is enumerated and as such should be followed through as enumerated:

-1. Not all possible deployment scenarios are supported on Azure. Therefore, you should check the document [SAP workload on Azure virtual machine supported scenarios](./planning-supported-configurations.md) for the scenario you have in mind with your SAP HANA deployment. If the scenario is not listed, you need to assume that it has not been tested and, as a result, is not supported

-2. Assuming that you have a rough idea on your memory requirement for your SAP HANA deployment, you need to find a fitting Azure VM. Not all the VMs that are certified for SAP NetWeaver, as documented in [SAP support note #1928533](https://launchpad.support.sap.com/#/notes/1928533), are SAP HANA certified. The source of truth for SAP HANA certified Azure VMs is the website [SAP HANA hardware directory](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=v:deCertified;ve:24;iaas;v:125;v:105;v:99;v:120). The units starting with **S** are [HANA Large Instances](../../virtual-machines/workloads/sap/hana-overview-architecture.md) units and not Azure VMs.

-3. Different Azure VM types have different minimum operating system releases for SUSE Linux or Red Hat Linux. On the website [SAP HANA hardware directory](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=v:deCertified;ve:24;iaas;v:125;v:105;v:99;v:120), you need to click on an entry in the list of SAP HANA certified units to get detailed data of this unit. Besides the supported HANA workload, the OS releases that are supported with those units for SAP HANA are listed

-5. As you might have found a valid combination of Azure VM type, operating system release and SAP HANA release, you need to check in the SAP Product Availability Matrix. In the SAP Availability Matrix, you can find out whether the SAP product you want to run against your SAP HANA database is supported.

-1. Chose the base image out of the Azure gallery. If you want to build your own operating system image for SAP HANA, you need to know all the different packages that are necessary for a successful SAP HANA installation. Otherwise it is recommended using the SUSE and Red Hat images for SAP or SAP HANA out of the gallery. These images include the packages necessary for a successful HANA installation. Based on your support contract with the operating system provider, you need to choose an image where you bring your own license. Or you choose an OS image that includes support

-2. If you chose a guest OS image that requires you bringing your own license, you need to register the OS image with your subscription, so, that you can download and apply the latest patches. This step is going to require public internet access. Unless you set up your private instance of, for example, an SMT server in Azure.

-3. Decide the network configuration of the VM. You can read more information in the document [SAP HANA infrastructure configurations and operations on Azure](./hana-vm-operations.md). Keep in mind that there are no network throughput quotas you can assign to virtual network cards in Azure. As a result, the only purpose of directing traffic through different vNICs is based on security considerations. We trust you to find a supportable compromise between complexity of traffic routing through multiple vNICs and the requirements enforced by security aspects.

-4. Apply the tunes necessary for SAP HANA. These tunes are listed in these SAP support notes:

-1. Select the Azure storage type for SAP HANA. In this step, you need to decide on storage layout for SAP HANA installation. You are going to use either attached Azure disks or native Azure NFS shares. The Azure storage types that or supported and combinations of different Azure storage types that can be used, are documented in [SAP HANA Azure virtual machine storage configurations](./hana-vm-operations-storage.md). Take the configurations documented as starting point. For non-production systems, you might be able to configure lower throughput or IOPS. For production purposes, you might need to configure a bit more throughput and IOPS.

-2. Make sure that you configured [Azure Write Accelerator](../../virtual-machines/how-to-enable-write-accelerator.md) for your volumes that contain the DBMS transaction logs or redo logs when you are using M-Series or Mv2-Series VMs. Be aware of the limitations for Write Accelerator as documented.

-2. Check whether [Azure Accelerated Networking](https://azure.microsoft.com/blog/maximize-your-vm-s-performance-with-accelerated-networking-now-generally-available-for-both-windows-and-linux/) is enabled on the VM(s) deployed.

-One of the Azure specifics is the installation of an Azure VM extension that delivers monitoring data for the SAP Host Agent. The details about the installation of this monitoring extension are documented in:

-With the Azure virtual machines deployed and the operating systems registered and configured, you can install SAP HANA according to the SAP install. As a good start to get to this documentation, start with this SAP website [HANA resources](https://www.sap.com/products/s4hana-erp.html?btp=9d3e6f82-d8ab-4122-8d2d-bf4971217afd)

- ```tsql

- ```tsql

- ```tsql

- ```tsql

- "granular_markings": [],

-description: Learn about the SAP audit log workbook, used to monitor and track data across your SAP systems.

-# Microsoft Sentinel solution for SAP® applications - SAP audit log workbook

-This article describes the SAP Audit workbook, used for monitoring and tracking user audit activity across your SAP systems. You can use the workbook to get a bird's eye view of user audit activity, to better secure your SAP systems and gain quick visibility into suspicious actions. You can drill down into suspicious events as needed.

-1. In the **Workbooks** gallery, enter *SAP audit* in the search bar, and select **SAP Audit** from among the results.

- :::image type="content" source="media/sap-audit-log-workbook/workbook-overview.png" alt-text="Screenshot of the top of the SAP Audit workbook." lightbox="media/sap-audit-log-workbook/workbook-overview.png":::

- > The SAP Audit workbook is hosted by the workspace where the Microsoft Sentinel solution for SAP® applications were installed. By default, both the SAP and the SOC data is assumed to be on the workspace that hosts the workbook.

- * Supported only when using the AMQP protocol. Not supported when using the SBMP protocol.

-If the application code uses SDK, the [retry policy](/azure/architecture/best-practices/retry-service-specific#service-bus) is already built in and active. The application will reconnect without significant impact to the application/workflow.

-You'll receive the following error message:

-This article provides best practice guidelines that help you use access tiers to optimize performance and reduce costs. To learn more about access tiers, see [Hot, cool, and archive access tiers for blob data](access-tiers-overview.md?tabs=azure-portal).

-This article describes how to manage a blob in an online access tier (Hot or Cool). For more information about how to move a blob to the Archive tier, see [Archive a blob](archive-blob.md). For more information about how to rehydrate a blob from the Archive tier, see [Rehydrate an archived blob to an online tier](archive-rehydrate-to-online-tier.md).

-For more information about access tiers for blobs, see [Hot, Cool, and Archive access tiers for blob data](access-tiers-overview.md).

-1. Fill out the **Basics** tab.

-1. On the **Advanced** tab, under **Blob storage**, set the **Access tier** to either *Hot* or *Cool*. The default setting is *Hot*.

-1. Select **Review + Create** to validate your settings and create your storage account.

-1. Under **Settings**, select **Configuration**.

-1. Locate the **Blob access tier (default)** setting, and select either *Hot* or *Cool*. The default setting is *Hot*, if you have not previously set this property.

-1. Save your changes.

-# Change the storage account tier to Cool

-# Change the storage account tier to Cool

-The following sections describe how to specify that a blob is uploaded to either the Hot or Cool tier. For more information about archiving a blob on upload, see [Archive blobs on upload](archive-blob.md#archive-blobs-on-upload).

-To create a blob in the Hot or Cool tier, specify that tier when you create the blob. The access tier specified on upload overrides the default access tier for the storage account.

-1. Select the **Upload** button.

-1. Select the file or files to upload.

-1. Expand the **Advanced** section, and set the **Access tier** to *Hot* or *Cool*.

-1. Select the **Upload** button.

-# Upload a single file named blob1.txt to the Cool tier.

-# Upload the contents of a sample-blobs directory to the Cool tier, recursively.

- -StandardBlobTier Cool

-To upload a blob to a specific tier with Azure CLI, call the [az storage blob upload](/cli/azure/storage/blob#az-storage-blob-upload) command, as shown in the following example. Remember to replace the placeholder values in brackets with your own values:

- --tier Cool \

-To upload a set of blobs to a specific tier with Azure CLI, call the [az storage blob upload-batch](/cli/azure/storage/blob#az-storage-blob-upload-batch) command, as shown in the following example. Remember to replace the placeholder values in brackets with your own values:

- --tier Cool \

-To change a blob's tier from Hot to Cool in the Azure portal, follow these steps:

-To change a blob's tier from Hot to Cool with PowerShell, use the blob's **BlobClient** property to return a .NET reference to the blob, then call the **SetAccessTier** method on that reference. Remember to replace placeholders in angle brackets with your own values:

-# Change the blob's access tier to Cool.

-$blob.BlobClient.SetAccessTier("Cool", $null, "Standard")

-To change a blob's tier from Hot to Cool with Azure CLI, call the [az storage blob set-tier](/cli/azure/storage/blob#az-storage-blob-set-tier) command. Remember to replace placeholders in angle brackets with your own values:

- --tier Cool \

-To change a blob's tier from Hot to Cool, use the [azcopy set-properties](..\common\storage-ref-azcopy-set-properties.md) command and set the `-block-blob-tier` parameter to `cool`.

-> This example encloses path arguments with single quotes (''). Use single quotes in all command shells except for the Windows Command Shell (cmd.exe). If you're using a Windows Command Shell (cmd.exe), enclose path arguments with double quotes ("") instead of single quotes (''). <br>This example excludes the SAS tokenn because it assumes that you've provided authorization credentials by using Azure Active Directory (Azure AD). See the [Get started with AzCopy](../common/storage-use-azcopy-v10.md) article to learn about the ways that you can provide authorization credentials to the storage service.

-azcopy set-properties 'https://<storage-account-name>.blob.core.windows.net/<container-name>/<blob-name>' --block-blob-tier=cool

-azcopy set-properties 'https://<storage-account-name>.blob.core.windows.net/<container-name>/myvirtualdirectory' --block-blob-tier=cool --recursive=true

-Call [Copy Blob](/rest/api/storageservices/copy-blob) operation to copy a blob from one tier to another. When you copy a blob to a different tier, you move that blob and all of its data to the target tier. The source blob remains in the original tier, and a new blob is created in the target tier. Calling [Copy Blob](/rest/api/storageservices/copy-blob) is recommended for most scenarios where you're moving a blob from Cool to Hot, or rehydrating a blob from the Archive tier.

-To copy a blob to from Cool to Hot with PowerShell, call the [Start-AzStorageBlobCopy](/powershell/module/az.storage/start-azstorageblobcopy) command and specify the target tier. Remember to replace placeholders in angle brackets with your own values:

-# Copy the source blob to a new destination blob in Hot tier.

-To copy a blob from Cool to Hot with Azure CLI, call the [az storage blob copy start](/cli/azure/storage/blob/copy#az-storage-blob-copy-start) command and specify the target tier. Remember to replace placeholders in angle brackets with your own values:

-To copy a blob from Cool to Hot with AzCopy, use [azcopy copy](..\common\storage-ref-azcopy-copy.md) command and set the `--block-blob-tier` parameter to `hot`.

-The copy operation is synchronous so when the command returns, that indicates that all files have been copied.

-description: Azure storage offers different access tiers so that you can store your blob data in the most cost-effective manner based on how it's being used. Learn about the hot, cool, and archive access tiers for Blob Storage.

-# Hot, cool, and archive access tiers for blob data

-When your data is stored in an online access tier (either hot or cool), users can access it immediately. The hot tier is the best choice for data that is in active use. The cool tier is ideal for data that is accessed less frequently, but that still must be available for reading and writing.

-Usage scenarios for the cool access tier include:

-To learn how to move a blob to the hot or cool tier, see [Set a blob's access tier](access-tiers-online-manage.md).

-Data in the cool tier has slightly lower availability, but offers the same high durability, retrieval latency, and throughput characteristics as the hot tier. For data in the cool tier, slightly lower availability and higher access costs may be acceptable trade-offs for lower overall storage costs, as compared to the hot tier. For more information, see [SLA for storage](https://azure.microsoft.com/support/legal/sla/storage/v1_5/).

-A blob in the cool tier in a general-purpose v2 account is subject to an early deletion penalty if it's deleted or moved to a different tier before 30 days has elapsed. This charge is prorated. For example, if a blob is moved to the cool tier and then deleted after 21 days, you'll be charged an early deletion fee equivalent to 9 (30 minus 21) days of storing that blob in the cool tier.

-The hot and cool tiers support all redundancy configurations. For more information about data redundancy options in Azure Storage, see [Azure Storage redundancy](../common/storage-redundancy.md).

-The archive tier is an offline tier for storing data that is rarely accessed. The archive access tier has the lowest storage cost. However, this tier has higher data retrieval costs with a higher latency as compared to the hot and cool tiers. Example usage scenarios for the archive access tier include:

-While a blob is in the archive tier, it can't be read or modified. To read or download a blob in the archive tier, you must first rehydrate it to an online tier, either hot or cool. Data in the archive tier can take up to 15 hours to rehydrate, depending on the priority you specify for the rehydration operation. For more information about blob rehydration, see [Overview of blob rehydration from the archive tier](archive-rehydrate-overview.md).

-To change the redundancy configuration for a storage account that contains blobs in the archive tier, you must first rehydrate all archived blobs to the hot or cool tier. Because rehydration operations can be costly and time-consuming, Microsoft recommends that you avoid changing the redundancy configuration of a storage account that contains archived blobs.

-Changing the default access tier setting for a storage account applies to all blobs in the account for which an access tier hasn't been explicitly set. If you toggle the default access tier setting from hot to cool in a general-purpose v2 account, then you're charged for write operations (per 10,000) for all blobs for which the access tier is inferred. You're charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle from cool to hot in a general-purpose v2 account.

-When you create a legacy Blob Storage account, you must specify the default access tier setting as hot or cool at create time. There's no charge for changing the default account access tier setting from hot to cool in a legacy Blob Storage account. You're charged for both read operations (per 10,000) and data retrieval (per GB) if you toggle from cool to hot in a Blob Storage account. Microsoft recommends using general-purpose v2 storage accounts rather than Blob Storage accounts when possible.

-> The archive tier is not supported as the default access tier for a storage account.

-Changing a blob's tier from hot to cool or archive is instantaneous, as is changing from cool to hot. Rehydrating a blob from the archive tier to either the hot or cool tier can take up to 15 hours.

-The following table summarizes the approaches you can take to move blobs between various tiers.

-| Origin/Destination | Hot tier | Cool tier | Archive tier |

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

-| **Hot tier** | N/A | Change a blob's tier from hot to cool with **Set Blob Tier** or **Copy Blob**. [Learn more...](manage-access-tier.md)<br /><br />Move blobs to the cool tier with a lifecycle management policy. [Learn more...](lifecycle-management-overview.md) | Change a blob's tier from hot to archive with **Set Blob Tier** or **Copy Blob**. [Learn more...](archive-blob.md) <br /><br />Archive blobs with a lifecycle management policy. [Learn more...](lifecycle-management-overview.md) |

-| **Cool tier** | Change a blob's tier from cool to hot with **Set Blob Tier** or **Copy Blob**. [Learn more...](manage-access-tier.md) <br /><br />Move blobs to the hot tier with a lifecycle management policy. [Learn more...](lifecycle-management-overview.md) | N/A | Change a blob's tier from cool to archive with **Set Blob Tier** or **Copy Blob**. [Learn more...](archive-blob.md) <br /><br />Archive blobs with a lifecycle management policy. [Learn more...](lifecycle-management-overview.md) |

-| **Archive tier** | Rehydrate to the hot tier with **Set Blob Tier** or **Copy Blob**. [Learn more...](archive-rehydrate-to-online-tier.md) | Rehydrate to cool tier with **Set Blob Tier** or **Copy Blob**. [Learn more...](archive-rehydrate-to-online-tier.md) | N/A |

-> Data stored in a premium block blob storage account cannot be tiered to hot, cool, or archive using [Set Blob Tier](/rest/api/storageservices/set-blob-tier) or using Azure Blob Storage lifecycle management. To move data, you must synchronously copy blobs from the block blob storage account to the hot tier in a different account using the [Put Block From URL API](/rest/api/storageservices/put-block-from-url) or a version of AzCopy that supports this API. The **Put Block From URL** API synchronously copies data on the server, meaning the call completes only once all the data is moved from the original server location to the destination location.

-The following table summarizes the features of the hot, cool, and archive access tiers.

-| | **Hot tier** | **Cool tier** | **Archive tier** |

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

-| **Availability** | 99.9% | 99% | Offline |

-| **Availability** <br> **(RA-GRS reads)** | 99.99% | 99.9% | Offline |

-| **Usage charges** | Higher storage costs, but lower access and transaction costs | Lower storage costs, but higher access and transaction costs | Lowest storage costs, but highest access, and transaction costs |

-| **Minimum recommended data retention period** | N/A | 30 days<sup>1</sup> | 180 days |

-| **Latency** <br> **(Time to first byte)** | Milliseconds | Milliseconds | Hours<sup>2</sup> |

-| **Supported redundancy configurations** | All | All | LRS, GRS, and RA-GRS<sup>3</sup> only |

-<sup>1</sup> Objects in the cool tier on general-purpose v2 accounts have a minimum retention duration of 30 days. For Blob Storage accounts, there's no minimum retention duration for the cool tier.

-Data access charges increase as the tier gets cooler. For data in the cool and archive access tier, you're charged a per-gigabyte data access charge for reads.

-| | **Write charges (operation + access)** | **Read charges (operation + access)** |

-| - | -- | -- |

-| **Set Blob Tier** operation | Hot to cool<br> Hot to archive<br> Cool to archive | Archive to cool<br> Archive to hot<br> cool to hot

-Changing the access tier for a blob when versioning is enabled, or if the blob has snapshots, may result in more charges. For information about blobs with versioning enabled, see [Pricing and billing](versioning-overview.md#pricing-and-billing) in the blob versioning documentation. For information about blobs with snapshots, see [Pricing and billing](snapshots-overview.md#pricing-and-billing) in the blob snapshots documentation.

-description: Use Azure Storage lifecycle management policies to create automated rules for moving data between hot, cool, and archive tiers.

-The updated policy takes up to 24 hours to go into effect. Once the policy is in effect, it could take up to 24 hours for the actions to run. Therefore, the policy actions may take up to 48 hours to complete. If the update is to disable or delete a rule, and enableAutoTierToHotFromCool was used, auto-tiering to Hot tier will still happen. For example, set a rule including enableAutoTierToHotFromCool based on last access. If the rule is disabled/deleted, and a blob is currently in cool and then accessed, it will move back to Hot as that is applied on access outside of lifecycle management. The blob won't then move from Hot to Cool given the lifecycle management rule is disabled/deleted. The only way to prevent autoTierToHotFromCool is to turn off last access time tracking.

-description: Configure a lifecycle management policy to automatically move data between hot, cool, and archive tiers during the data lifecycle.

-A lifecycle management policy is comprised of one or more rules that define a set of actions to take based on a condition being met. For a base blob, you can choose to check one of the following conditions:

-Before you configure a lifecycle management policy, you can choose to enable blob access time tracking. When access time tracking is enabled, a lifecycle management policy can include an action based on the time that the blob was last accessed with a read or write operation.To minimize the effect on read access latency, only the first read of the last 24 hours updates the last access time. Subsequent reads in the same 24-hour period don't update the last access time. If a blob is modified between reads, the last access time is the more recent of the two values.

-| **Tier** | Azure storage offers different access tiers, which allow you to store blob object data in the most cost-effective manner. See more in [Azure Storage blob tier](../blobs/access-tiers-overview.md). The supported values include: <br/> <li>**Hot**: Hot tier</li> <li>**Cool**: Cool tier</li> <li>**Archive**: Archive tier</li> <li>**Premium**: Premium tier for block blob</li> <li>**P4/P6/P10/P15/P20/P30/P40/P50/P60**: Tier types for premium page blob</li> <li>**Standard**: Tier type for standard page Blob</li> <li>**Untiered**: Tier type for general purpose v1 storage account</li> |

-If you choose to authenticate with private-public key pair, you can either generate one, use one already stored in Azure, or provide Azure the public key of an existing public-private key pair. You can have a maxiumum of 10 public keys per local user.

-Enabling the SFTP endpoint has an hourly cost. We will start applying this hourly cost on or after January 1, 2023. For the latest pricing information, see [Azure Blob Storage pricing](https://azure.microsoft.com/pricing/details/storage/blobs/).

-| [Access tier - archive](access-tiers-overview.md) | &#x2705; | &#x2705;<sup>3</sup> | &#x2705;<sup>3</sup> | &#x2705;<sup>3</sup> |

-| [Access tier - cool](access-tiers-overview.md) | &#x2705; | &#x2705;<sup>3</sup> | &#x2705;<sup>3</sup>| &#x2705;<sup>3</sup> |

-| [Access tier - hot](access-tiers-overview.md) | &#x2705; | &#x2705;<sup>3</sup> | &#x2705;<sup>3</sup> | &#x2705;<sup>3</sup> |

-| [Access tier - archive](access-tiers-overview.md) | &nbsp;&#x2B24; | &nbsp;&#x2B24; | &nbsp;&#x2B24; | &nbsp;&#x2B24; |

-| [Access tier - cool](access-tiers-overview.md) | &nbsp;&#x2B24; | &nbsp;&#x2B24; | &nbsp;&#x2B24; | &nbsp;&#x2B24; |

-| [Access tier - hot](access-tiers-overview.md) | &nbsp;&#x2B24; | &nbsp;&#x2B24; | &nbsp;&#x2B24; | &nbsp;&#x2B24; |

-| Monitoring | Enabling Storage Analytics logs (classic logs)| Storage analytics logs can accumulate in your account over time if the retention policy is not set. Make sure to set the retention policy to avoid log build up which can lead to unexpected capacity charges.<br><br>For more information, see [Modify log data retention period](manage-storage-analytics-logs.md#modify-log-data-retention-period) |

-| **Data type** | Azure Blobs | Azure Blobs<br>Azure Files | Azure Blobs<br>Azure Files | Azure Blobs<br>Azure Files |

-| **Data type** | Azure Blobs | Azure Blobs<br>Azure Files | Azure Blobs<br>Azure Files | Azure Blobs<br>Azure Files |

-This article focuses on enabling and configuring Azure AD DS for identity-based authentication with Azure file shares.

-Next, do the following things to grant access to Azure Files resources with Azure AD credentials:

-2. Assign share-level permissions to an Azure AD identity (a user, group, or service principal).

-3. Connect to your Azure file share using a storage account key and configure Windows access control lists (ACLs) for directories and files.

-4. Mount an Azure file share from a domain-joined VM.

-By default, the Windows Update client is configured to provide updates only for Windows. If you enable the **Give me updates for other Microsoft products when I update Windows** setting, you also receive updates for other products, including security patches for Microsoft SQL Server and other Microsoft software. You can configure this option if you have downloaded and copied the latest [Administrative template files](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) available for Windows 2016 and later.

-If you have machines running Windows Server 2012 R2, you can't configure this setting through Group Policy. Run the following PowerShell command on these machines:

-```powershell

-$ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")

-$ServiceManager.Services

-$ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"

-$ServiceManager.AddService2($ServiceId,7,"")

-```

-By default, the Windows Update client is configured to provide updates only for Windows. If you enable the **Give me updates for other Microsoft products when I update Windows** setting, you also receive updates for other products, including security patches for Microsoft SQL Server and other Microsoft software. You can configure this option if you have downloaded and copied the latest [Administrative template files](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra) available for Windows 2016 and later.

-If you have machines running Windows Server 2012 R2, you can't configure this setting through **Group Policy**. Run the following PowerShell command on these machines:

-```powershell

-$ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")

-$ServiceManager.Services

-$ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"

-$ServiceManager.AddService2($ServiceId,7,"")

-```

-The following table lists the supported operating systems for Azure VMs and Azure Arc-enabled servers. Before you enable update management center (preview), ensure that the target machines meet the operating system requirements.

->[!NOTE]

-> - For [Azure VMs](../virtual-machines/index.yml), we currently support a combination of Offer, Publisher, and SKU of the VM image. Ensure you match all three to confirm support.

-> - See the list of [supported OS images](../virtual-machines/automatic-vm-guest-patching.md#supported-os-images).

-> - Custom images are currently not supported.

-[Azure Arc-enabled servers](../azure-arc/servers/overview.md) are:

- | Publisher | Operating System

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

- | Microsoft Corporation | Windows Server 2008 R2 SP1 with PowerShell enabled and .NET Framework 4.0+ |

- | Canonical | Ubuntu 16.04, 18.04, and 20.04 LTS (x64) |

- | Red Hat | CentOS Linux 7 and 8 (x64) |

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

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

- | Amazon | Amazon Linux 2 (x64) |

- | Oracle | Oracle 7.x |

-As the Update management center (preview) depends on your machine's OS package manager or update service, ensure that the Linux package manager or Windows Update client are enabled and can connect with an update source or repository. If you're running a Windows Server OS on your machine, see [configure Windows Update settings](configure-wu-agent.md).

- > [!NOTE]

- > For patching, update management center (preview) relies on classification data available on the machine. Unlike other distributions, CentOS YUM package manager does not have this information available in the RTM version to classify updates and packages in different categories.

-> - An identity provider

-> - A supported operating system

-You also need to make sure you've registered the *Microsoft.DesktopVirtualization* resource provider for your subscription. To check the status of the resource provider and register if needed:

-1. Verify that the status of Microsoft.DesktopVirtualization is **Registered**.

-|<ul><li>[Windows 11 Enterprise multi-session](/lifecycle/products/windows-11-enterprise-and-education)</li><li>[Windows 11 Enterprise](/lifecycle/products/windows-11-enterprise-and-education)</li><li>[Windows 10 Enterprise multi-session](/lifecycle/products/windows-10-enterprise-and-education)</li><li>[Windows 10 Enterprise](/lifecycle/products/windows-10-enterprise-and-education)</li><ul>|License entitlement:<ul><li>Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit</li><li>Windows Enterprise E3, E5</li><li>Windows VDA E3, E5</li><li>Windows Education A3, A5</li></ul>External users can use [per-user access pricing](https://azure.microsoft.com/pricing/details/virtual-desktop/) instead of license entitlement.</li></ul>|

-1. Download the [Azure Virtual Desktop policy templates file](https://aka.ms/avdgpo) (AVDGPTemplate.cab) and extract the contents of the cab file and zip archive.

-|Needs Assistance|The session host didn't pass one or more of the following non-fatal health checks: the Geneva Monitoring Agent health check, the Azure Instance Metadata Service (IMDS) health check, or the URL health check. You can find which health checks have failed in the session hosts detailed view in the Azure portal. |Follow the directions in [Error: VMs are stuck in "Needs Assistance" state](troubleshoot-agent.md#error-vms-are-stuck-in-the-needs-assistance-state) to resolve the issue.|

-The Ebsv5 and Ebdsv5 VMs offer up to 120000 IOPS and 4000 MBps of remote disk storage throughput. Both series also include up to 512 GiB of RAM. The Ebdsv5 series has local SSD storage up to 2400 GiB. Both series provide a 3X increase in remote storage performance of data-intensive workloads compared to prior VM generations. You can use these series to consolidate existing workloads on fewer VMs or smaller VM sizes while achieving potential cost savings. The Ebdsv5 series comes with a local disk and Ebsv5 is without a local disk. Standard SSDs and Standard HDD disk storage aren't supported in the Ebv5 series.

-Ebdsv5-series sizes run on the Intel® Xeon® Platinum 8370C (Ice Lake) processors. The Ebdsv5 VM sizes feature up to 512 GiB of RAM, in addition to fast and large local SSD storage (up to 2400 GiB). These VMs are ideal for memory-intensive enterprise applications and applications that benefit from high remote storage performance, low latency, high-speed local storage. Remote Data disk storage is billed separately from VMs.

-Pricing Calculator: [Pricing Calculator](https://azure.microsoft.com/pricing/calculator/)