-1. Enter your sign-in credentials, such as email address and password. If you don't have an account, select **Sign up now** to create an account. If you have an account but have forgotten your password, select **Forgot your password?** to recover your password. After you successfully sign in or sign up, you should see the following page that shows sign-in status.

-1. Enter your sign-in credentials, such as email address and password. If you don't have an account, select **Sign up now** to create an account. If you have an account but have forgotten your password, select **Forgot your password?** to recover your password. After you successfully sign in or sign up, you should see the following page with **Call the PROTECTED API** button.

-To enable sign-in for users with a Twitter account in Azure AD B2C, you need to create a Twitter application. If you don't already have a Twitter account, you can sign up at [`https://twitter.com/signup`](https://twitter.com/signup). You also need to [Apply for a developer account](https://developer.twitter.com/en/apply/user.html). For more information, see [Apply for access](https://developer.twitter.com/en/apply-for-access).

-| DiscoverMetadataByTokenIssuer | No | Indicates whether the OIDC metadata should be discovered by using the issuer in the JWT token. |

-description: Tutorial to configure Akamai Web application firewall with Azure AD B2C

-# Tutorial: Configure Akamai with Azure Active Directory B2C

-In this sample tutorial, learn how to enable [Akamai Web Application Firewall (WAF)](https://www.akamai.com/us/en/resources/web-application-firewall.jsp) solution for Azure Active Directory (AD) B2C tenant using custom domains. Akamai WAF helps organization protect their web applications from malicious attacks that aim to exploit vulnerabilities such as SQL injection and Cross site scripting.

-This sample tutorial applies to both [Web Application Protector (WAP)](https://www.akamai.com/us/en/products/security/web-application-protector-enterprise-waf-firewall-ddos-protection.jsp) and [Kona Site Defender (KSD)](https://www.akamai.com/us/en/products/security/kona-site-defender.jsp) WAF solutions that Akamai offers.

-2. After custom domain for Azure AD B2C is successfully configured using Azure Front Door, [test the custom domain](./custom-domain.md?pivots=b2c-custom-policy#test-your-custom-domain) before proceeding further.

-2. Configure the property settings as:

- |Property hostnames | Add a property hostname. This is the name of your custom domain, for example: login.domain.com. <BR> Create or modify a certificate with the appropriate settings for the custom domain name. For more information, see [this](https://learn.akamai.com/en-us/webhelp/property-manager/https-delivery-with-property-manager/GUID-9EE0EB6A-E62B-4F5F-9340-60CBD093A429.html). |

-3. Set the origin server property configuration settings as:

-Create a CNAME record in your DNS such as login.domain.com that points to the Edge hostname in the Property hostname field.

-2. Ensure that **Rule Actions** for all items listed under the **Attack Group** are set to **Deny**.

-

-Check the following to ensure all traffic to Azure AD B2C is now going through the custom domain:

-description: Configure Azure Active Directory B2C with Transmit Security for passwordless strong customer authentication

-zone_pivot_groups: b2c-policy-type

-# Configure Transmit Security with Azure Active Directory B2C for passwordless authentication

-In this sample tutorial, learn how to integrate Azure Active Directory (AD) B2C authentication with [Transmit Security](https://www.transmitsecurity.com/bindid) passwordless authentication solution **BindID**. BindID is a passwordless authentication service that uses strong Fast Identity Online (FIDO2) biometric authentication for a reliable omni-channel authentication experience. The solution ensures a smooth login experience for all customers across every device and channel eliminating fraud, phishing, and credential reuse.

-## Scenario description

-The following architecture diagram shows the implementation.

-

-|Step | Description |

-|:--| :--|

-| 1. | User arrives at a login page. Users select sign-in/sign-up and enter username into the page.

-| 2. | Azure AD B2C redirects the user to BindID using an OpenID Connect (OIDC) request.

-| 3. | BindID authenticates the user using appless FIDO2 biometrics, such as fingerprint.

-| 4. | A decentralized authentication response is returned to BindID.

-| 5. | The OIDC response is passed on to Azure AD B2C.

-| 6.| User is either granted or denied access to the customer application based on the verification results.

-## Onboard with BindID

-To integrate BindID with your Azure AD B2C instance, you'll need to configure an application in the [BindID Admin

-Portal](https://admin.bindid-sandbox.io/console/). For more information, see [getting started guide](https://developer.bindid.io/docs/guides/admin_portal/topics/getStarted/get_started_admin_portal). You can either create a new application or use one that you already created.

-## Prerequisites

-To get started, you'll need:

-### Step 1 - Create an application registration in BindID

-From [Applications](https://admin.bindid-sandbox.io/console/#/applications) to configure your tenant application in BindID, the following information is needed

-| Property | Description |

-|:|:|

-| Name | Azure AD B2C/your desired application name|

-| Domain | name.onmicrosoft.com|

-| Redirect URIs| https://jwt.ms |

-| Redirect URLs |Specify the page to which users are redirected after BindID authentication: https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp<br>For Example: `https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp`<br>If you use a custom domain, enter https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp.<br>Replace your-domain-name with your custom domain, and your-tenant-name with the name of your tenant.|

->[!NOTE]

->BindID will provide you Client ID and Client Secret, which you'll need later to configure the Identity provider in Azure AD B2C.

-### Step 2 - Add a new Identity provider in Azure AD B2C

-1. Sign-in to the [Azure portal](https://portal.azure.com/#home) as the global administrator of your Azure AD B2C tenant.

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. Choose **All services** in the top-left corner of the Azure portal, then search for and select **Azure AD B2C**.

-5. Navigate to **Dashboard** > **Azure Active Directory B2C** > **Identity providers**.

-6. Select **New OpenID Connect Provider**.

-7. Select **Add**.

-### Step 3 - Configure an Identity provider

-1. Select **Identity provider type > OpenID Connect**

-2. Fill out the form to set up the Identity provider:

- |Property |Value |

- |:|:|

- |Name |Enter BindID ΓÇô Passwordless or a name of your choice|

- |Metadata URL| `https://signin.bindid-sandbox.io/.well-known/openid-configuration` |

- |Client ID|The application ID from the BindID admin UI captured in **Step 1**|

- |Client Secret|The application Secret from the BindID admin UI captured in **Step 1**|

- |Scope|OpenID email|

- |Response type|Code|

- |Response mode|form_post|

- |**Identity provider claims mapping**|

- |User ID|sub|

- |Email|email|

-3. Select **Save** to complete the setup for your new OIDC Identity provider.

-### Step 4 - Create a user flow policy

-You should now see BindID as a new OIDC Identity provider listed within your B2C identity providers.

-1. In your Azure AD B2C tenant, under **Policies**, select **User flows**.

-2. Select **New user flow**

-3. Select **Sign up and sign in** > **Version Recommended** > **Create**.

-4. Enter a **Name** for your policy.

-5. In the Identity providers section, select your newly created BindID Identity provider.

-6. Select **None** for Local Accounts to disable email and password-based authentication.

-7. Select **Create**

-8. Select the newly created User Flow

-9. Select **Run user flow**

-10. In the form, select the JWT Application and enter the Replying URL, such as `https://jwt.ms`.

-11. Select **Run user flow**.

-12. The browser will be redirected to the BindID login page. Enter the account name registered during User registration. The user enters the registered account email and authenticates using appless FIDO2 biometrics, such as fingerprint.

-13. Once the authentication challenge is accepted, the browser will redirect the user to the replying URL.

-### Step 2 - Create a BindID policy key

-Store the client secret that you previously recorded in your Azure AD B2C tenant.

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

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.

-5. On the Overview page, select **Identity Experience Framework**.

-6. Select **Policy Keys** and then select **Add**.

-7. For **Options**, choose `Manual`.

-8. Enter a **Name** for the policy key. For example, `BindIDClientSecret`. The prefix `B2C_1A_` is added automatically to the name of your key.

-9. In **Secret**, enter your client secret that you previously recorded.

-10. For **Key usage**, select `Signature`.

-11. Select **Create**.

->[!NOTE]

->In Azure Active Directory B2C, [**custom policies**](./user-flow-overview.md) are designed primarily to address complex scenarios. For most scenarios, we recommend that you use built-in [**user flows**](./user-flow-overview.md).

-### Step 3- Configure BindID as an Identity provider

-To enable users to sign in using BindID, you need to define BindID as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify a specific user has authenticated using digital identity available on their device, proving the userΓÇÖs identity.

-You can define BindID as a claims provider by adding it to the **ClaimsProvider** element in the extension file of your policy

-1. Open the `TrustFrameworkExtensions.xml`.

-2. Find the **ClaimsProviders** element. If it dosen't exist, add it under the root element.

-3. Add a new **ClaimsProvider** as follows:

-

-```xml

- <ClaimsProvider>

- <Domain>signin.bindid-sandbox.io</Domain>

- <DisplayName>BindID</DisplayName>

- <TechnicalProfiles>

- <TechnicalProfile Id="BindID-OpenIdConnect">

- <DisplayName>BindID</DisplayName>

- <Protocol Name="OpenIdConnect" />

- <Metadata>

- <Item Key="METADATA">https://signin.bindid-sandbox.io/.well-known/openid-configuration</Item>

- <!-- Update the Client ID below to the BindID Application ID -->

- <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>

- <Item Key="response_types">code</Item>

- <Item Key="scope">openid email</Item>

- <Item Key="response_mode">form_post</Item>

- <Item Key="HttpBinding">POST</Item>

- <Item Key="UsePolicyInRedirectUri">false</Item>

- <Item Key="AccessTokenResponseFormat">json</Item>

- </Metadata>

- <CryptographicKeys>

- <Key Id="client_secret" StorageReferenceId="B2C_1A_BindIDClientSecret" />

- </CryptographicKeys>

- <OutputClaims>

- <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />

- <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />

- <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" />

- <OutputClaim ClaimTypeReferenceId="authenticationSource"

- DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />

- </OutputClaims>

- <OutputClaimsTransformations>

- <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />

- <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />

- <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />

- </OutputClaimsTransformations>

- <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />

- </TechnicalProfile>

- </TechnicalProfiles>

- </ClaimsProvider>

-```

-4. Set **client_id** with your BindID Application ID.

-5. Save the file.

-### Step 4 - Add a user journey

-At this point, the identity provider has been set up, but it's not yet available in any of the sign-in pages. If you don't have your own custom user journey, create a duplicate of an existing template user journey, otherwise continue to the next step.

-1. Open the `TrustFrameworkBase.xml` file from the starter pack.

-2. Find and copy the entire contents of the **UserJourneys** element that includes `ID=SignUpOrSignIn`.

-3. Open the `TrustFrameworkExtensions.xml` and find the UserJourneys element. If the element doesn't exist, add one.

-4. Paste the entire content of the UserJourney element that you copied as a child of the UserJourneys element.

-5. Rename the ID of the user journey. For example, `ID=CustomSignUpSignIn`

-### Step 5 - Add the identity provider to a user journey

-Now that you have a user journey, add the new identity provider to the user journey.

-1. Find the orchestration step element that includes Type=`CombinedSignInAndSignUp`, or Type=`ClaimsProviderSelection` in the user journey. It's usually the first orchestration step. The **ClaimsProviderSelections** element contains a list of identity providers that a user can sign in with. The order of the elements controls the order of the sign-in buttons presented to the user. Add a **ClaimsProviderSelection** XML element. Set the value of **TargetClaimsExchangeId** to a friendly name, such as `BindIDExchange`.

-2. In the next orchestration step, add a **ClaimsExchange** element. Set the **Id** to the value of the target claims exchange ID to link the BindID button to `BindID-SignIn` action. Update the value of **TechnicalProfileReferenceId** to the ID of the technical profile you created earlier.

-The following XML demonstrates orchestration steps of a user journey with the identity provider:

-```xml

-<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">

- <ClaimsProviderSelections>

- ...

- <ClaimsProviderSelection TargetClaimsExchangeId="BindIDExchange" />

- </ClaimsProviderSelections>

- ...

-</OrchestrationStep>

-<OrchestrationStep Order="2" Type="ClaimsExchange">

- ...

- <ClaimsExchanges>

- <ClaimsExchange Id="BindIDExchange" TechnicalProfileReferenceId="BindID-OpenIdConnect" />

- </ClaimsExchanges>

-</OrchestrationStep>

-```

-### Step 6 - Configure the relying party policy

-The relying party policy, for example [SignUpSignIn.xml](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/SocialAccounts/SignUpOrSignin.xml), specifies the user journey which Azure AD B2C will execute. You can also control what claims are passed to your application by adjusting the **OutputClaims** element of the **PolicyProfile** TechnicalProfile element. In this sample, the application will receive the user attributes such as display name, given name, surname, email, objectId, identity provider, and tenantId.

-```xml

- <RelyingParty>

- <DefaultUserJourney ReferenceId="SignUpOrSignInWithBindID" />

- <TechnicalProfile Id="BindID-OpenIdConnect">

- <DisplayName>PolicyProfile</DisplayName>

- <Protocol Name="OpenIdConnect" />

- <OutputClaims>

- <OutputClaim ClaimTypeReferenceId="displayName" />

- <OutputClaim ClaimTypeReferenceId="givenName" />

- <OutputClaim ClaimTypeReferenceId="surname" />

- <OutputClaim ClaimTypeReferenceId="email" />

- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>

- <OutputClaim ClaimTypeReferenceId="identityProvider" />

- <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />

- </OutputClaims>

- <SubjectNamingInfo ClaimType="sub" />

- </TechnicalProfile>

- </RelyingParty>

-```

-### Step 7 - Upload the custom policy

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

-2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

-3. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

-4. In the [Azure portal](https://portal.azure.com/#home), search for and select **Azure AD B2C**.

-5. Under Policies, select **Identity Experience Framework**.

-6. Select **Upload Custom Policy**, and then upload the two policy files that you changed, in the following order: the extension policy, for example `TrustFrameworkExtensions.xml`, then the relying party policy, such as `SignUpSignIn.xml`.

-### Step 8 - Test your custom policy

-1. Open the Azure AD B2C tenant and under Policies select **Identity Experience Framework**.

-2. Click on your previously created **CustomSignUpSignIn** and select the settings:

- a. **Application**: select the registered app (sample is JWT)

- b. **Reply URL**: select the **redirect URL** that should show `https://jwt.ms`.

- c. Select **Run now**.

-If the sign-in process is successful, your browser is redirected to `https://jwt.ms`, which displays the contents of the token returned by Azure AD B2C.

-## Next steps

-For additional information, review the following articles:

-|ScriptExecution| 0:1| The supported [JavaScript](javascript-and-page-layout.md) execution modes. Possible values: `Allow` or `Disallow` (default).

-<ClaimsProvider>

- <DisplayName>Token Issuer</DisplayName>

- <TechnicalProfiles>

- <TechnicalProfile Id="Saml2AssertionIssuer">

- <DisplayName>Token Issuer</DisplayName>

- <Protocol Name="SAML2"/>

- <OutputTokenFormat>SAML2</OutputTokenFormat>

- ...

-> If you do not update the `accessTokenAcceptedVersion` to `2` you will recieve an error message requiring a verified domain.

-We recommend that you set the value of SessionExpiryInSeconds to be a short period (1200 seconds), while the value of KeepAliveInDays can be set to a relatively long period (30 days), as shown in the following example:

- <InputParameter Id="ignoreCase" DataType="string" Value="true" />

- <InputParameter Id="ignoreCase" DataType="string" Value="true" />

-## Using custom attribute with MS Graph API

-[Microsoft Graph API][ms-graph-api] supports creating and updating a user with extension attributes. Extension attributes in the Microsoft Graph API are named by using the convention `extension_ApplicationClientID_attributename`, where the `ApplicationClientID` is the **Application (client) ID** of the `b2c-extensions-app` [application](#azure-ad-b2c-extensions-app). Note that the **Application (client) ID** as it's represented in the extension attribute name includes no hyphens. For example, the Microsoft Graph API identifies an extension attribute `loyaltyId` in Azure AD B2C as `extension_831374b3bd5041bfaa54263ec9e050fc_loyaltyId`.

-Learn how to [interact with resources in your Azure AD B2C tenant](microsoft-graph-operations.md#user-management) using Microsoft Graph API.

-

-> Before you remove the extension/custom attribute, for each account in the directory, set the extension attribute value to null. In this way you explicitly remove the extension attributesΓÇÖs values. Then continue to remove the extension attribute itself. Extension/custom attribute is queryable using MS Graph API.

-To remove a custom attribute, use [MS Graph API](microsoft-graph-operations.md), and use the [Delete](/graph/api/application-delete-extensionproperty) command.

-> After Sept. 30th, 2022, all existing Azure AD tenants will be automatically enabled for combined registration. After this date tenants will be unable to utilize the separate legacy registration workflows for MFA and SSPR.

-> After Sept. 30th, 2022, all existing Azure AD tenants will be automatically enabled for combined registration. After this date tenants will be unable to disable the combined registration experience.

-> After Sept. 30th, 2022, all existing Azure AD tenants will be automatically enabled for combined registration. After this date tenants will be unable to utilize the separate legacy registration workflows for MFA and SSPR.

-> After Sept. 30th, 2022, all existing Azure AD tenants will be automatically enabled for combined registration. After this date tenants will be unable to disable the combined registration experience.

-> **This preview feature is being deprecated.** Customers should use **Filter for devices** condition in Conditional Access to satisfy scenarios, previously achieved using device state (preview) condition.

-The device state condition can be used to exclude devices that are hybrid Azure AD joined and/or devices marked as compliant with a Microsoft Intune compliance policy from an organization's Conditional Access policies.

-The What If tool is located in the **Azure portal** > **Azure Active Directory** > **Conditional Access** > **What If**.

-* [How it works: Azure AD Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md)

-Use this sample JSON for a risk-based policy using the [Microsoft Graph beta endpoint](/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0&preserve-view=true).

-> [!NOTE]

-> Report-only mode doesn't report account risk on a risky workload identity.

-```json

-{

-"displayName": "Name",

-"state": "enabled OR disabled",

-"conditions": {

-"applications": {

-"includeApplications": [

-"All"

-],

-"excludeApplications": [],

-"includeUserActions": [],

-"includeAuthenticationContextClassReferences": [],

-"applicationFilter": null

-},

-"userRiskLevels": [],

-"signInRiskLevels": [],

-"clientApplications": {

-"includeServicePrincipals": [

-"ServicePrincipalsInMyTenant"

-],

-"excludeServicePrincipals": []

-},

-"servicePrincipalRiskLevels": [

-"low",

-"medium",

-"high"

-]

-},

-"grantControls": {

-"operator": "and",

-"builtInControls": [

-"block"

-],

-"customAuthenticationFactors": [],

-"termsOfUse": []

-}

-}

-```

-Enterprise State Roaming is available to any organization with an Azure AD Premium or Enterprise Mobility + Security (EMS) license. For more information on how to get an Azure AD subscription, see the [Azure AD product page](https://azure.microsoft.com/services/active-directory).

-description: Enterprise State Roaming provides users with a unified experience across their Windows devices

-# What is enterprise state roaming?

-With Windows 10 or newer, [Azure Active Directory (Azure AD)](../fundamentals/active-directory-whatis.md) users gain the ability to securely synchronize their user settings and application settings data to the cloud. Enterprise State Roaming provides users with a unified experience across their Windows devices and reduces the time needed for configuring a new device. Enterprise State Roaming operates similar to the standard [consumer settings sync](https://go.microsoft.com/fwlink/?linkid=2015135) that was first introduced in Windows 8. Additionally, Enterprise State Roaming offers:

-| Article | Description |

-| | |

-| [Enable Enterprise State Roaming in Azure Active Directory](enterprise-state-roaming-enable.md) | Enterprise State Roaming is available to any organization with a Premium Azure Active Directory (Azure AD) subscription. |

-| [Settings and data roaming FAQ](enterprise-state-roaming-faqs.yml) | This article answers some questions IT administrators might have about settings and app data sync. |

-| [Group policy and MDM settings for settings sync](enterprise-state-roaming-group-policy-settings.md) | Windows 10 or newer provides Group Policy and mobile device management (MDM) policy settings to limit settings sync. |

-| [Windows 10 roaming settings reference](enterprise-state-roaming-windows-settings-reference.md) | A list of settings that will be roamed and/or backed-up in Windows 10 or newer. |

-| [Troubleshooting](enterprise-state-roaming-troubleshooting.md) | This article goes through some basic steps for troubleshooting, and contains a list of known issues. |

-## Next steps

-For information about enabling enterprise state roaming, see [enable enterprise state roaming](enterprise-state-roaming-enable.md).

-## Assign a role to a user-assigned managed identity

-To assign a role to a user-assigned managed identity, your account needs the [User Access Administrator](../../role-based-access-control/built-in-roles.md#user-access-administrator) role assignment.

-1. A list of the user-assigned managed identities for your subscription is returned. Select the user-assigned managed identity that you want to assign a role.

- 

-1. Select the **Add** button at the upper part of the pane, and then, in the **Name** box, enter the name of the administrative unit. Optionally, add a description of the administrative unit.

- 

-1. Select the blue **Add** button to finalize the administrative unit.

-In Azure AD, you can delete an administrative unit that you no longer need as a unit of scope for administrative roles.

-

-1. Select the administrative unit to be deleted, and then select **Delete**.

-1. To confirm that you want to delete the administrative unit, select **Yes**. The administrative unit is deleted.

-# Tutorial: Azure Active Directory single sign-on (SSO) integration with AWS Single-Account Access

-For AKS to automatically rotate non-CA certificates, the cluster must have [TLS Bootstrapping](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/).

-This article describes the Azure App Service VNet integration feature and how to set it up with apps in [App Service](./overview.md). With [Azure virtual networks](../virtual-network/virtual-networks-overview.md) (VNets), you can place many of your Azure resources in a non-internet-routable network. The App Service VNet integration feature enables your apps to access resources in or through a virtual network. Virtual network integration doesn't enable your apps to be accessed privately.

-* The feature is available from all App Service scale units in Premium v2 and Premium v3. It's also available in Standard but only from newer App Service scale units. If you're on an older scale unit, you can only use the feature from a Premium v2 App Service plan. If you want to make sure you can use the feature in a Standard App Service plan, create your app in a Premium v3 App Service plan. Those plans are only supported on our newest scale units. You can scale down if you want after the plan is created.

- If you're using the permission model **Azure role-based access control**: Select **Access control (IAM)** and [Add a role assignment](../active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md#assign-a-role-to-a-user-assigned-managed-identity) for the user-assigned managed identity to the Azure Key Vault for the role **Key Vault Secrets User**.

-## Start a runbook on a Hybrid Runbook Worker

-[Start a runbook in Azure Automation](start-runbooks.md) describes different methods for starting a runbook. Starting a runbook on a Hybrid Runbook Worker uses a **Run on** option that allows you to specify the name of a Hybrid Runbook Worker group. When a group is specified, one of the workers in that group retrieves and runs the runbook. If your runbook does not specify this option, Azure Automation runs the runbook as usual.

-When you start a runbook in the Azure portal, you're presented with the **Run on** option for which you can select **Azure** or **Hybrid Worker**. If you select **Hybrid Worker**, you can choose the Hybrid Runbook Worker group from a dropdown.

-When starting a runbook using PowerShell, use the `RunOn` parameter with the [Start-AzAutomationRunbook](/powershell/module/Az.Automation/Start-AzAutomationRunbook) cmdlet. The following example uses Windows PowerShell to start a runbook named **Test-Runbook** on a Hybrid Runbook Worker group named MyHybridGroup.

-```azurepowershell-interactive

-Start-AzAutomationRunbook -AutomationAccountName "MyAutomationAccount" -Name "Test-Runbook" -RunOn "MyHybridGroup"

-```

-description: Explains how to restore a database to a specific point in time on Azure Arc-enabled SQL Managed Instance.

-# Perform a point in time Restore

-Point-in-time restore enables a database to be restored to a specific point in time, within the retention period. To restore a database to a specific point in time, Azure Arc-enabled data services applies the backup files in a specific order. For example:

-## Create a database from a point in time using az

-## Create a database from a point in time using Azure Data Studio

-You can also restore a database to a point in time from Azure Data Studio as follows:

-> If you disable Automatic Backups for an Azure Arc-enabled SQL managed instance, then any Automatic Backups configured will be deleted and you lose the ability to do a point in time restore. You can change the `retention-days` property to re-initiate automatic backups if needed.

-If your client library or tool doesn't support TLS, then enabling unencrypted connections is possible through the [Azure portal](cache-configure.md#access-ports) or [management APIs](/rest/api/redis/2021-06-01/redis/update). In cases where encrypted connections aren't possible, we recommend placing your cache and client application into a virtual network. For more information about which ports are used in the virtual network cache scenario, see this [table](cache-how-to-premium-vnet.md#outbound-port-requirements).

-```console

-> Similarly, `AzureWebJobsStorage` is used for deployment artifacts when using server-side build in Linux Consumption. When you enable identity-based connections for `AzureWebJobsStorage` in Linux Consmption, you will need to deploy via [an external deployment package](run-functions-from-deployment-package.md).

-## Region Max Scale Out

-```bash

- "direction": "out"

-Push-OutputBinding -Name res -Value ([HttpResponseContext]@{

-When you create a function app in Azure, you must choose a hosting plan for your app. There are three basic hosting plans available for Azure Functions: [Consumption plan](consumption-plan.md), [Premium plan](functions-premium-plan.md), and [Dedicated (App Service) plan](dedicated-plan.md). All hosting plans are generally available (GA) on both Linux and Windows virtual machines.

-|**[Consumption plan](consumption-plan.md)**| Scale automatically and only pay for compute resources when your functions are running.<br/><br/>On the Consumption plan, instances of the Functions host are dynamically added and removed based on the number of incoming events.<br/><br/> Γ£ö Default hosting plan.<br/>Γ£ö Pay only when your functions are running.<br/>Γ£ö Scales automatically, even during periods of high load.|

-|**[Premium plan](functions-premium-plan.md)**|Automatically scales based on demand using pre-warmed workers which run applications with no delay after being idle, runs on more powerful instances, and connects to virtual networks. <br/><br/>Consider the Azure Functions Premium plan in the following situations: <br/><br/>Γ£ö Your function apps run continuously, or nearly continuously.<br/>Γ£ö You have a high number of small executions and a high execution bill, but low GB seconds in the Consumption plan.<br/>Γ£ö You need more CPU or memory options than what is provided by the Consumption plan.<br/>Γ£ö Your code needs to run longer than the maximum execution time allowed on the Consumption plan.<br/>Γ£ö You require features that aren't available on the Consumption plan, such as virtual network connectivity.<br/>Γ£ö You want to provide a custom Linux image on which to run your functions. |

-|**[Dedicated plan](dedicated-plan.md)** |Run your functions within an App Service plan at regular [App Service plan rates](https://azure.microsoft.com/pricing/details/app-service/windows/).<br/><br/>Best for long-running scenarios where [Durable Functions](durable/durable-functions-overview.md) can't be used. Consider an App Service plan in the following situations:<br/><br/>Γ£ö You have existing, underutilized VMs that are already running other App Service instances.<br/>Γ£ö Predictive scaling and costs are required.|

-|**[ASE](dedicated-plan.md)** | App Service Environment (ASE) is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.<br/><br/>ASEs are appropriate for application workloads that require: <br/><br/>Γ£ö Very high scale.<br/>Γ£ö Full compute isolation and secure network access.<br/>Γ£ö High memory usage.|

-| **Kubernetes**<br/>([Direct](functions-kubernetes-keda.md) or<br/>[Azure Arc](../app-service/overview-arc-integration.md)) | Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform.<br/><br/> Kubernetes is appropriate for application workloads that require: <br/>Γ£ö Custom hardware requirements.<br/>Γ£ö Isolation and secure network access.<br/>Γ£ö Ability to run in hybrid or multi-cloud environment.<br/>Γ£ö Run alongside existing Kubernetes applications and services.|

-The following table shows operating system and language support for the hosting plans.

-| | Linux¹<br/>Code-only | Windows²<br/>Code-only | Linux^1,3<br/>Docker container |

-| **[Consumption plan](consumption-plan.md)** | .NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>Python<br/>TypeScript | .NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>TypeScript | No support |

-| **[Premium plan](functions-premium-plan.md)** | .NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>Python<br/>TypeScript |.NET Core<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>TypeScript |.NET Core<br/>Node.js<br/>Java<br/>PowerShell Core<br/>Python<br/>TypeScript |

-| **[Dedicated plan](dedicated-plan.md)** | .NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>Python<br/>TypeScript |.NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>TypeScript |.NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>Python<br/>TypeScript |

-| **[ASE](dedicated-plan.md)** | .NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>Python<br/>TypeScript |.NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>TypeScript |.NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>Python<br/>TypeScript |

-| **[Kubernetes (direct)](functions-kubernetes-keda.md)** | n/a | n/a |.NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>Python<br/>TypeScript |

-| **[Azure Arc (Preview)](../app-service/overview-arc-integration.md)** | .NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>Python<br/>TypeScript | n/a |.NET Core 3.1<br/>.NET 5.0<br/>JavaScript<br/>Java<br/>PowerShell Core<br/>Python<br/>TypeScript |

-² Windows is the only supported operating system for the PowerShell runtime stack.<br/>

-| Plan | Scale out | Max # instances |

-| **[Consumption plan](consumption-plan.md)** | [Event driven](event-driven-scaling.md). Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of incoming trigger events. | 200 |

-| **[Premium plan](functions-premium-plan.md)** | [Event driven](event-driven-scaling.md). Scale out automatically, even during periods of high load. Azure Functions infrastructure scales CPU and memory resources by adding additional instances of the Functions host, based on the number of events that its functions are triggered on. |100|

-| **[Dedicated plan](dedicated-plan.md)**¹ | Manual/autoscale |10-20|

-| **[ASE](dedicated-plan.md)**¹ | Manual/autoscale |100 |

-| **[Kubernetes](functions-kubernetes-keda.md)** | Event-driven autoscale for Kubernetes clusters using [KEDA](https://keda.sh). | Varies&nbsp;by&nbsp;cluster&nbsp;&nbsp;|

-¹ For specific limits for the various App Service plan options, see the [App Service plan limits](../azure-resource-manager/management/azure-subscription-service-limits.md#app-service-limits).

-| **[Consumption&nbsp;plan](consumption-plan.md)** | Apps may scale to zero when idle, meaning some requests may have additional latency at startup. The consumption plan does have some optimizations to help decrease cold start time, including pulling from pre-warmed placeholder functions that already have the function host and language processes running. |

-| **[Premium plan](functions-premium-plan.md)** | Perpetually warm instances to avoid any cold start. |

-| **[Dedicated plan](dedicated-plan.md)** | When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn't really an issue. |

-| **[ASE](dedicated-plan.md)** | When running in a Dedicated plan, the Functions host can run continuously, which means that cold start isn't really an issue. |

-| **[Kubernetes](functions-kubernetes-keda.md)** | Depending on KEDA configuration, apps can be configured to avoid a cold start. If configured to scale to zero, then a cold start is experienced for new events.

-| **[Consumption plan](consumption-plan.md)** | Pay only for the time your functions run. Billing is based on number of executions, execution time, and memory used. |

-| **[Premium plan](functions-premium-plan.md)** | Premium plan is based on the number of core seconds and memory used across needed and pre-warmed instances. At least one instance per plan must be kept warm at all times. This plan provides the most predictable pricing. |

-| **[Dedicated plan](dedicated-plan.md)** | You pay the same for function apps in an App Service Plan as you would for other App Service resources, like web apps.|

-| **[App Service Environment (ASE)](dedicated-plan.md)** | There's a flat monthly rate for an ASE that pays for the infrastructure and doesn't change with the size of the ASE. There's also a cost per App Service plan vCPU. All apps hosted in an ASE are in the Isolated pricing SKU. |

-| **[Kubernetes](functions-kubernetes-keda.md)**| You pay only the costs of your Kubernetes cluster; no additional billing for Functions. Your function app runs as an application workload on top of your cluster, just like a regular app. |

-```bash

-## Private link configuration

-To configure the agent to use private links for network communications with Azure Monitor, you can use [Azure Monitor Private Links Scopes (AMPLS)](../logs/private-link-security.md) and [data collection endpoints](azure-monitor-agent-data-collection-endpoint.md) to enable required network isolation.

-Want to keep your telemetry for longer than the standard retention period? Or process it in some specialized way? Continuous Export is ideal for this. The events you see in the Application Insights portal can be exported to storage in Microsoft Azure in JSON format. From there, you can download your data and write whatever code you need to process it.

-> Continuous export has been deprecated. [Migrate to a workspace-based Application Insights resource](convert-classic-resource.md) to use [diagnostic settings](#diagnostic-settings-based-export) for exporting telemetry.

-After Continuous Export copies your data to storage (where it can stay for as long as you like), it's still available in Application Insights for the usual [retention period](./data-retention-privacy.md).

- Click Add, Export Destination, Storage account, and then either create a new store or choose an existing store.

-Once the first export is complete you will find a structure similar to the following in your Azure Blob storage container: (This will vary depending on the data you are collecting.)

-| [Requests](export-data-model.md#requests)| Sent by [TrackRequest](./api-custom-events-metrics.md#trackrequest). The standard modules use this to reports server response time, measured at the server.|

-Click on continuous export and select the storage account to edit.

-To stop the export, click Disable. When you click Enable again, the export will restart with new data. You won't get the data that arrived in the portal while export was disabled.

-The exported data is the raw telemetry we receive from your application, except that we add location data, which we calculate from the client IP address.

-Data that has been discarded by [sampling](./sampling.md) is not included in the exported data.

-Other calculated metrics are not included. For example, we don't export average CPU utilization, but we do export the raw telemetry from which the average is computed.

-You can inspect the storage directly in the portal. Click home in the leftmost menu, at the top where it says "Azure services" select **Storage accounts**, select the storage account name, on the overview page select **Blobs** under services, and finally select the container name.

-You are responsible for managing your storage capacity and deleting the old data if necessary.

-Open the Continuous Export tab and edit your export. Edit the Export Destination, but just leave the same storage selected. Click OK to confirm.

-On larger scales, consider [HDInsight](https://azure.microsoft.com/services/hdinsight/) - Hadoop clusters in the cloud. HDInsight provides a variety of technologies for managing and analyzing big data, and you could use it to process data that has been exported from Application Insights.

- Yes, you can do that. At the top of the tab, click **Export Data**.

- No. We'll keep pushing data in until you delete the export. We'll stop if we hit the outer limits for blob storage, but that's pretty huge. It's up to you to control how much storage you use.

- * In addition, for applications with high traffic, additional partition units are allocated. In this case, each unit creates a blob every minute.

- Edit the export and open the export destination tab. Leave the same storage selected as before, and click OK to confirm. Export will restart. If the change was within the past few days, you won't lose data.

- Yes. Click Disable.

-Diagnostic settings based export uses a different schema than continuous export. It also supports features that continuous export does not like:

-* Azure storage accounts with vnet, firewalls, and private links.

-* Export to event hub.

-To migrate to diagnostic settings based export:

- ``` sh

- ``` sh

- ```

-```bash

-Azure Monitor provides a complete full stack monitoring solution for applications and services in Azure, in other clouds, and on-premises. In addition to using Azure Monitor for analyzing that data and leveraging it for different monitoring scenarios, you may need to send it to other monitoring tools in your environment. In most cases, the most effective method to stream monitoring data to external tools is using [Azure Event Hubs](../../event-hubs/index.yml). This article provides a brief description on how to do this and then lists some of the partners where you can send data. Some have special integration with Azure Monitor and may be hosted on Azure.

-* The number of partitions allows you to parallelize consumption across many consumers. A single partition can support up to 20MBps or approximately 20,000 messages per second. Depending on the tool consuming the data, it may or may not support consuming from multiple partitions. Four partitions is reasonable to start with if you're not sure about the number of partitions to set.

-* You set message retention on your event hub to at least 7 days. If your consuming tool goes down for more than a day, this ensures that the tool can pick up where it left off for events up to 7 days old.

-* You should use the default consumer group for your event hub. There is no need to create other consumer groups or use a separate consumer group unless you plan to have two different tools consume the same data from the same event hub.

-[Sources of monitoring data for Azure Monitor](../agents/data-sources.md) describes the different tiers of data for Azure applications and the kinds of monitoring data available for each. The following table lists each of these tiers and a description of how that data can be streamed to an event hub. Follow the links provided for further detail.

-| [Azure tenant](../agents/data-sources.md#azure-tenant) | Azure Active Directory audit logs | Configure a tenant diagnostic setting on your AAD tenant. See [Tutorial: Stream Azure Active Directory logs to an Azure event hub](../../active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) for details. |

-| [Application code](../agents/data-sources.md#application-code) | Application Insights | Application Insights doesn't provide a direct method to stream data to event hubs. You can [set up continuous export](../app/export-telemetry.md) of the Application Insights data to a storage account and then use a Logic App to send the data to an event hub as described in [Manual streaming with Logic App](#manual-streaming-with-logic-app). |

-| Splunk | No | [Splunk Add-on for Microsoft Cloud Services](https://splunkbase.splunk.com/app/3110/) is an open source project available in Splunkbase. <br><br> If you cannot install an add-on in your Splunk instance, if for example you're using a proxy or running on Splunk Cloud, you can forward these events to the Splunk HTTP Event Collector using [Azure Function For Splunk](https://github.com/Microsoft/AzureFunctionforSplunkVS), which is triggered by new messages in the event hub. |

-* [Configure ADDS LDAP over TLS for Azure NetApp Files](configure-ldap-over-tls.md)

-* [Configure ADDS LDAP over TLS for Azure NetApp Files](configure-ldap-over-tls.md)

-# Configure ADDS LDAP with extended groups for NFS volume access

-This article explains the considerations and steps for enabling LDAP with extended groups when you create an NFS volume.

- See [Configure ADDS LDAP over TLS](configure-ldap-over-tls.md) for information about this option.

-* [Configure ADDS LDAP over TLS](configure-ldap-over-tls.md)

- * [ADDS LDAP over TLS](configure-ldap-over-tls.md)

-* [ADDS LDAP over TLS](configure-ldap-over-tls.md) (Preview)

-```bash

-```bash

- ```powershell

- ```powershell

-```bash

->Make sure port UDP 500 is open between your on-premises VMware HCX Connector 'uplink' network profile addresses and the Azure VMware Solution HCX Cloud 'uplink' network profile addresses. (4500 UDP was previously required in legacy versions of HCX. See https://ports.vmware.com for latest information)

- ```bash

- ```bash

- ```bash

- ```bash

- ```bash

- ```bash

- ```bash

- ```bash

- ```bash

- ```bash

-```JSON

-```azurepowershell-interactive

-```azurepowershell-interactive

-```azurepowershell-interactive

-## Oracle Real Application Clusters

-[Oracle Real Application Clusters (RAC)](https://docs.oracle.com/en/database/oracle/oracle-database/19/racad/introduction-to-oracle-rac.html#GUID-5A1B02A2-A327-42DD-A1AD-20610B2A9D92) allows multiple interconnected servers to appear as one database service to end users and applications. This feature removes many points of failure and is a recognized high availability active/active solution for Oracle databases.

-As shown in the following figure from Oracle's [High Availability Overview and Best Practices](https://docs.oracle.com/en/database/oracle/oracle-database/19/haovw/ha-features.html), a single RAC database is presented to the application layer. The applications connect to the SCAN listener, which directs traffic to a specific database instance. RAC controls access from multiple instances to maintain data consistency across separate compute nodes.

-

-If one instance fails, the service continues on all other remaining instances. Each database deployed on the solution will be in a RAC configuration of n+1, where n is the minimum processing power required to support the service.

-Oracle Database services are used to allow connections to fail over between nodes when an instance fails transparently. Such failures may be planned or unplanned. Working with Oracle RAC Fast Application Notification, when an instance is made unavailable, the service is moved to a surviving node. The service moves to a node specified in the service configuration as either preferred or available.

-Another key feature of Oracle Database services is only starting a service depending on its role. This feature is used when there's a Data Guard failover. All patterns deployed using Data Guard are required to link a database service to a Data Guard role.

-For example, two services could be created, MY\_DB\_APP and MY\_DB\_AS. The MY\_DB\_APP service is started only when the database instance is started with the Data Guard role of PRIMARY. MY\_DB\_AS is only started when the Data Guard role is PHYSICAL\_STANDBY. This configuration allows for applications to point to the \_APP service, while also reporting, which can be offloaded to Active Standby and pointed to the \_AS service.

-## Oracle Real Application Clusters (RAC) One Node

-This topology supports a RAC configuration with shared storage and GRID cluster. Database instances run only on one node (active-passive configuration).

-Features include:

- - Automatic fail-over

- - Fast restart on second node

-[](media/oracle-baremetal-architecture/one-node-rac-architecture.png#lightbox)

-## RAC

-This topology supports an Oracle RAC configuration with shared storage and Grid cluster while multiple instances per database run concurrently (active-active configuration).

-This configuration allows you to test all changes on an exact copy of the production database before they're applied to the production environment.

-> [!NOTE]

-> If you intend to use Active Data Guard Far Sync (synchronous mode), you'll need to consider the regional zones where this feature is supported. For geographical distributed regions only, we recommend using Data Guard with asynchronous mode.

-[](media/oracle-baremetal-architecture/rac-architecture.png#lightbox)

-The first step to provision your BareMetal instances is to work with your Microsoft CSA. They'll help you based on your specific workload needs and the architecture you're deploying, whether single instance, One Node RAC, or RAC. For more information on these topologies, see [Architecture of BareMetal Infrastructure for Oracle](oracle-baremetal-architecture.md).

-BareMetal Infrastructure for Oracle offers NetApp Network File System (NFS) storage. NFS storage does not require Oracle Real Application Clusters (RAC) certification. For more information, see [Oracle RAC Technologies Matrix for Linux Clusters](https://www.oracle.com/database/technologies/tech-generic-linux-new.html).

-description: Learn how to connect to a VM from a Windows computer by using Bastion and the native client.

-# Connect to a VM using the native client (Preview)

-This article helps you configure Bastion, and then connect to a VM in the VNet using the native client (SSH or RDP) on your local workstation. This feature lets you connect to your target VMs via Bastion using Azure CLI, and expands your sign-in options to include local SSH key pair and Azure Active Directory (Azure AD). For more information about Azure Bastion, see [What is Azure Bastion?](bastion-overview.md)

-> * This configuration requires the Standard SKU tier for Azure Bastion.

-> * You can now upload and download files using the native client. To learn more, refer to [Upload and download files using the native client](vm-upload-download-native.md).

-> * The user's capabilities on the VM using a native client are dependent on what is enabled on the native client. Controlling access to features such as file transfer via the Bastion is not supported.

-* Signing in using an SSH private key stored in Azure Key Vault isnΓÇÖt supported with this feature. Download your private key to a file on your local machine before signing in to your Linux VM using an SSH key pair.

-Before you begin, verify that youΓÇÖve met the following criteria:

- * Enable Azure AD sign-in for a [Windows VM](../active-directory/devices/howto-vm-sign-in-azure-ad-windows.md) or [Linux VM](../active-directory/devices/howto-vm-sign-in-azure-ad-linux.md).

-Follow the instructions that pertain to your environment.

-### <a name="modify-host"></a>To modify an existing bastion host

-If you have already configured Bastion for your VNet, modify the following settings:

-### <a name="configure-new"></a>To configure a new bastion host

-If you don't already have a bastion host configured, see [Create a bastion host](tutorial-create-host-portal.md#createhost). When configuring the bastion host, specify the following settings:

-1. On the **Basics** tab, for **Instance Details -> Tier** select **Standard** to create a bastion host using the Standard SKU.

-* Virtual Machine Administrator Login or Virtual Machine User Login role, if youΓÇÖre using the Azure AD sign-in method. You only need to do this if you're enabling Azure AD login using the process described in this article: [Azure Windows VMs and Azure AD](../active-directory/devices/howto-vm-sign-in-azure-ad-windows.md) or [Azure Linux VMs and Azure AD](../active-directory/devices/howto-vm-sign-in-azure-ad-linux.md).

-## <a name="connect"></a>Connect to a VM from a Windows local workstation

-This section helps you connect to your virtual machine from a Windows local workstation. Use the steps that correspond to the type of VM you want to connect to.

-1. Sign in to your Azure account and select your subscription containing your Bastion resource.

- ```azurecli-interactive

-1. Use the example options that correspond to the type of VM you want to connect to ([Linux VM](#connect-linux) or [Windows VM](#connect-windows)).

-### <a name="connect-linux"></a>Connect to a Linux VM

-1. Sign in to your target Linux VM using one of the following example options.

- > [!NOTE]

- > If you want to specify a custom port value, you should also include the field **--resource-port** in the sign-in command.

- >

- * **Azure AD:** If youΓÇÖre signing in to an Azure AD login-enabled VM, use the following command. For more information, see [Azure Linux VMs and Azure AD](../active-directory/devices/howto-vm-sign-in-azure-ad-linux.md).

- ```azurecli-interactive

- az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>" --auth-type "AAD"

- ```

- * **SSH:** If youΓÇÖre signing in using an SSH key pair, use the following command.

- ```azurecli-interactive

- az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>" --auth-type "ssh-key" --username "<Username>" --ssh-key "<Filepath>"

- ```

- * **Username/password:** If youΓÇÖre signing in using a local username and password, use the following command. YouΓÇÖll then be prompted for the password for the target VM.

- ```azurecli-interactive

- az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>" --auth-type "password" --username "<Username>"

- ```

-

- > [!NOTE]

- > VM sessions using the **az network bastion ssh** command do not support file transfer. To use file transfer with SSH over Bastion, see the [az network bastion tunnel](#connect-tunnel) section.

- >

-### <a name="connect-windows"></a>Connect to a Windows VM

-1. Sign in to your target Windows VM using one of the following example options.

- > [!NOTE]

- > If you want to specify a custom port value, you should also include the field **--resource-port** in the sign-in command.

- >

- * **RDP:** To connect via RDP, use the following command. YouΓÇÖll then be prompted to input your credentials. You can use either a local username and password, or your Azure AD credentials. For more information, see [Azure Windows VMs and Azure AD](../active-directory/devices/howto-vm-sign-in-azure-ad-windows.md).

- ```azurecli-interactive

- az network bastion rdp --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>"

- ```

- * **SSH:** To sign in using an SSH key pair, use the following command. The SSH CLI extension is currently in Preview. The extension can be installed by running, "az extension add --name ssh".

- ```azurecli-interactive

- az network bastion ssh --name "<BastionName>" --resource-group "<ResourceGroupName>" --target-resource-id "<VMResourceId>" --auth-type "ssh-key" --username "<Username>" --ssh-key "<Filepath>"

-1. Once you sign in to your target VM, the native client on your workstation will open up with your VM session; **MSTSC** for RDP sessions, and **SSH CLI extension (az ssh)** for SSH sessions.

-## <a name="connect-tunnel"></a>Connect to a VM using the *az network bastion tunnel* command

-This section helps you connect to your virtual machine using the *az network bastion tunnel* command, which allows you to:

-* Use native clients on *non*-Windows local workstations (ex: a Linux PC).

-* Use a native client of your choice.

-* Set up concurrent VM sessions with Bastion.

-* Upload files to your target VM from your local workstation.

-1. Sign in to your Azure account, and select your subscription containing your Bastion resource.

- ```azurecli-interactive

-2. Open the tunnel to your target VM using the following command.

- ```azurecli-interactive

-3. 1. Connect to your target VM using SSH or RDP, the native client of your choice, and the local machine port you specified in Step 2. For example, you can use the following command if you have the OpenSSH client installed on your local computer:

- ```azurecli-interactive

- ssh <username>@127.0.0.1 -p <LocalMachinePort>

- ```

-Read the [Bastion FAQ](bastion-faq.md).

-# Upload and download files using the native client: Azure Bastion (Preview)

-Azure Bastion offers support for file transfer between your target VM and local computer using Bastion and a native RDP or SSH client. To learn more about native client support, refer to [Connect to a VM using the native client](connect-native-client-windows.md). You can use either SSH or RDP to upload files to a VM from your local computer. To download files from a VM, you must use RDP.

-> [!NOTE]

-> * Uploading and downloading files is supported using the native client only. You can't upload and download files using PowerShell or via the Azure portal.

-> * This feature requires the Standard SKU. The Basic SKU doesn't support using the native client.

->

-## Upload and download files using the *az network bastion rdp* command

-This section helps you transfer files between your local Windows computer and your target VM over RDP. The *az network bastion rdp* command uses the native client MSTSC to connect to the target VM. Once connected to the target VM, you can transfer files using right-click, then **Copy** and **Paste**.

-1. Sign in to your Azure account and select the subscription containing your Bastion resource.

- ```azurecli-interactive

- az login

- az account list

- az account set --subscription "<subscription ID>"

- ```

- ```azurecli-interactive

-## Upload files using the *az network bastion tunnel* command

-This section helps you upload files from your local computer to your target VM over SSH or RDP using the *az network bastion tunnel* command. The *az network tunnel command* allows you to use a native client of your choice on *non*-Windows local workstations. To learn more about the tunnel command, refer to [Connect to a VM using the *az network bastion tunnel* command](connect-native-client-windows.md#connect-tunnel).

-> File download over SSH is not currently supported.

-1. Sign in to your Azure account and select the subscription containing your Bastion resource.

- ```azurecli-interactive

- az login

- az account list

- az account set --subscription "<subscription ID>"

- ```

- ```azurecli-interactive

- ```azurecli-interactive

-1. Connect to your target VM using SSH, the native client of your choice, and the local machine port you specified in Step 3. For example, you can use the following command if you have the OpenSSH client installed on your local computer:

- ```azurecli-interactive

- ```bash

- ```bash

- ```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-Use the same Swagger path as 3.2 but a different port if you have already deployed 3.2 at the 5000 port.

-# [Version 3.2](#tab/version-3-2)

-Use the host, `http://localhost:5000`, for container APIs. You can view the Swagger path at: `http://localhost:5000/swagger/vision-v3.2-read/swagger.json`.

-# [Version 2.0-preview](#tab/version-2)

-Use the host, `http://localhost:5000`, for container APIs. You can view the Swagger path at: `http://localhost:5000/swagger/vision-v2.0-preview-read/swagger.json`.

-|No|Storage:TimeToLiveInDays| v3.x containers only. Result expiration period in days. The setting specifies when the system should clear recognition results. The default is 2 days (48 hours), which means any result live for longer than that period is not guaranteed to be successfully retrieved. |

-|No|EnableSyncNTPServer| v3.x containers only. Enables the NTP server synchronization mechanism, which ensures synchronization between the system time and expected task runtime. Note that this requires external network traffic. The default is `true`. |

-|No|NTPServerAddress| v3.x containers only. NTP server for the time sync-up. The default is `time.windows.com`. |

-|No|Mounts::Shared| v3.x containers only. Local folder for storing recognition result. The default is `/share`. For running container without using Azure blob storage, we recommend mounting a volume to this folder to ensure you have enough space for the recognition results. |

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-```bash

-# Customize pronunciation

-For steps on implementing UPS, see [Structured text data for training phone sets](how-to-custom-speech-test-and-train.md#structured-text-data-for-training-public-preview)

-This structured text data is not the same as [pronunciation files](how-to-custom-speech-test-and-train.md#pronunciation-data-for-training), and they cannot be used together.

-## Languages Supported

-Use the table below to navigate to the UPS for the respective language.

-| Language | Locale |

-|-||

-| [English (United States)](phone-sets.md) | `en-US` |

-* [Provide UPS pronunciation to Custom Speech](how-to-custom-speech-test-and-train.md#structured-text-data-for-training-public-preview)

-## Upload data

-To upload your data:

-1. Go to [Speech Studio](https://aka.ms/speechstudio/customspeech).

-1. After you create a project, go to the **Speech datasets** tab. Select **Upload data** to start the wizard and create your first dataset.

-1. Select a speech data type for your dataset, and upload your data.

-1. Specify whether the dataset will be used for **Training** or **Testing**.

- There are many types of data that can be uploaded and used for **Training** or **Testing**. Each dataset that you upload must be correctly formatted before uploading, and it must meet the requirements for the data type that you choose. Requirements are listed in the following sections.

-1. After your dataset is uploaded, you can either:

- * Go to the **Train custom models** tab to train a custom model.

- * Go to the **Test models** tab to visually inspect quality with audio-only data or evaluate accuracy with audio + human-labeled transcription data.

-### Upload data by using Speech-to-text REST API v3.0

-You can use [Speech-to-text REST API v3.0](rest-speech-to-text.md#speech-to-text-rest-api-v30) to automate any operations related to your custom models. In particular, you can use the REST API to upload a dataset.

-To create and upload a dataset, use a [Create Dataset](https://centralus.dev.cognitive.microsoft.com/docs/services/speech-to-text-api-v3-0/operations/CreateDataset) request.

-A dataset that you create by using the Speech-to-text REST API v3.0 will *not* be connected to any of the Speech Studio projects, unless you specify a special parameter in the request body (see the code block later in this section). Connection with a Speech Studio project is *not* required for any model customization operations, if you perform them by using the REST API.

-When you log on to Speech Studio, its user interface will notify you when any unconnected object is found (like datasets uploaded through the REST API without any project reference). The interface will also offer to connect such objects to an existing project.

-To connect the new dataset to an existing project in Speech Studio during its upload, use [Create Dataset](https://centralus.dev.cognitive.microsoft.com/docs/services/speech-to-text-api-v3-0/operations/CreateDataset) and fill out the request body according to the following format:

-```json

-{

- "kind": "Acoustic",

- "contentUrl": "https://contoso.com/mydatasetlocation",

- "locale": "en-US",

- "displayName": "My speech dataset name",

- "description": "My speech dataset description",

- "project": {

- "self": "https://westeurope.api.cognitive.microsoft.com/speechtotext/v3.0/projects/c1c643ae-7da5-4e38-9853-e56e840efcb2"

- }

-}

-```

-You can obtain the project URL that's required for the `project` element by using the [Get Projects](https://centralus.dev.cognitive.microsoft.com/docs/services/speech-to-text-api-v3-0/operations/GetProjects) request.

-* [Evaluate your data](how-to-custom-speech-evaluate-data.md)

-# Long Audio API

- ```powershell-interactive

- ```powershell-interactive

- ```powershell-interactive

- ```powershell-interactive

-```powershell

- --source https://workerappscliextension.blob.core.windows.net/azure-cli-extension/containerapp-0.2.2-py2.py3-none-any.whl

- --source https://workerappscliextension.blob.core.windows.net/azure-cli-extension/containerapp-0.2.2-py2.py3-none-any.whl

-```bash

-```bash

-```powershell

-```bash

-```bash

-```bash

-```powershell

-```bash

-```

-```console

-$ az acr check-health --name myregistry --ignore-errors --yes

-```azurecli

-```JSON

-```JSON

-```bash

-```bash

- ```bash

- ```bash

- ```bash

- ```bash

-```JSON

- ```bash

- ```bash

- ```bash

-```bash

-```bash

-```console

-$ az acr task list-runs --registry $ACR_NAME --output table

-```console

-$ az acr task list-runs --registry $ACR_NAME --output table

-```console

-```

-```bash

-```Console

-description: Learn how to query diagnostics logs for troubleshooting data stored in Azure Cosmos DB for the Cassandra API.

-In this article, we'll cover how to write more advanced queries to help troubleshoot issues with your Azure Cosmos DB account by using diagnostics logs sent to **Azure Diagnostics (legacy)** and **resource-specific (preview)** tables.

-## Common queries

-Common queries are shown in the resource-specific and Azure Diagnostics tables.

-### Top N(10) Request Unit (RU) consuming requests or queries in a specific time frame

-# [Resource-specific](#tab/resource-specific)

- ```Kusto

- let topRequestsByRUcharge = CDBDataPlaneRequests

- | where TimeGenerated > ago(24h)

- | project RequestCharge , TimeGenerated, ActivityId;

- CDBCassandraRequests

- | project PIICommandText, ActivityId, DatabaseName , CollectionName

- | join kind=inner topRequestsByRUcharge on ActivityId

- | project DatabaseName , CollectionName , PIICommandText , RequestCharge, TimeGenerated

- | order by RequestCharge desc

- | take 10

- ```

-# [Azure Diagnostics](#tab/azure-diagnostics)

- ```Kusto

- let topRequestsByRUcharge = AzureDiagnostics

- | where Category == "DataPlaneRequests" and TimeGenerated > ago(1h)

- | project requestCharge_s , TimeGenerated, activityId_g;

- AzureDiagnostics

- | where Category == "CassandraRequests"

- | project piiCommandText_s, activityId_g, databasename_s , collectionname_s

- | join kind=inner topRequestsByRUcharge on activityId_g

- | project databasename_s , collectionname_s , piiCommandText_s , requestCharge_s, TimeGenerated

- | order by requestCharge_s desc

- | take 10

- ```

-### Requests throttled (statusCode = 429) in a specific time window

-# [Resource-specific](#tab/resource-specific)

- ```Kusto

- let throttledRequests = CDBDataPlaneRequests

- | where StatusCode == "429"

- | project OperationName , TimeGenerated, ActivityId;

- CDBCassandraRequests

- | project PIICommandText, ActivityId, DatabaseName , CollectionName

- | join kind=inner throttledRequests on ActivityId

- | project DatabaseName , CollectionName , PIICommandText , OperationName, TimeGenerated

- ```

-# [Azure Diagnostics](#tab/azure-diagnostics)

- ```Kusto

- let throttledRequests = AzureDiagnostics

- | where Category == "DataPlaneRequests"

- | where statusCode_s == "429"

- | project OperationName , TimeGenerated, activityId_g;

- AzureDiagnostics

- | where Category == "CassandraRequests"

- | project piiCommandText_s, activityId_g, databasename_s , collectionname_s

- | join kind=inner throttledRequests on activityId_g

- | project databasename_s , collectionname_s , piiCommandText_s , OperationName, TimeGenerated

- ```

-### Queries with large response lengths (payload size of the server response)

-# [Resource-specific](#tab/resource-specific)

- ```Kusto

- let operationsbyUserAgent = CDBDataPlaneRequests

- | project OperationName, DurationMs, RequestCharge, ResponseLength, ActivityId;

- CDBCassandraRequests

- //specify collection and database

- //| where DatabaseName == "DBNAME" and CollectionName == "COLLECTIONNAME"

- | join kind=inner operationsbyUserAgent on ActivityId

- | summarize max(ResponseLength) by PIICommandText

- | order by max_ResponseLength desc

- ```

-# [Azure Diagnostics](#tab/azure-diagnostics)

- ```Kusto

- let operationsbyUserAgent = AzureDiagnostics

- | where Category=="DataPlaneRequests"

- | project OperationName, duration_s, requestCharge_s, responseLength_s, activityId_g;

- AzureDiagnostics

- | where Category == "CassandraRequests"

- //specify collection and database

- //| where databasename_s == "DBNAME" and collectioname_s == "COLLECTIONNAME"

- | join kind=inner operationsbyUserAgent on activityId_g

- | summarize max(responseLength_s1) by piiCommandText_s

- | order by max_responseLength_s1 desc

- ```

-### RU consumption by physical partition (across all replicas in the replica set)

-# [Resource-specific](#tab/resource-specific)

- ```Kusto

- CDBPartitionKeyRUConsumption

- | where TimeGenerated >= now(-1d)

- //specify collection and database

- //| where DatabaseName == "DBNAME" and CollectionName == "COLLECTIONNAME"

- // filter by operation type

- //| where operationType_s == 'Create'

- | summarize sum(todouble(RequestCharge)) by toint(PartitionKeyRangeId)

- | render columnchart

- ```

-# [Azure Diagnostics](#tab/azure-diagnostics)

- ```Kusto

- AzureDiagnostics

- | where TimeGenerated >= now(-1d)

- | where Category == 'PartitionKeyRUConsumption'

- //specify collection and database

- //| where databasename_s == "DBNAME" and collectioname_s == "COLLECTIONNAME"

- // filter by operation type

- //| where operationType_s == 'Create'

- | summarize sum(todouble(requestCharge_s)) by toint(partitionKeyRangeId_s)

- | render columnchart

- ```

-### RU consumption by logical partition (across all replicas in the replica set)

-# [Resource-specific](#tab/resource-specific)

- ```Kusto

- CDBPartitionKeyRUConsumption

- | where TimeGenerated >= now(-1d)

- //specify collection and database

- //| where DatabaseName == "DBNAME" and CollectionName == "COLLECTIONNAME"

- // filter by operation type

- //| where operationType_s == 'Create'

- | summarize sum(todouble(RequestCharge)) by PartitionKey, PartitionKeyRangeId

- | render columnchart

- ```

-# [Azure Diagnostics](#tab/azure-diagnostics)

- ```Kusto

- AzureDiagnostics

- | where TimeGenerated >= now(-1d)

- | where Category == 'PartitionKeyRUConsumption'

- //specify collection and database

- //| where databasename_s == "DBNAME" and collectioname_s == "COLLECTIONNAME"

- // filter by operation type

- //| where operationType_s == 'Create'

- | summarize sum(todouble(requestCharge_s)) by partitionKey_s, partitionKeyRangeId_s

- | render columnchart

- ```

-## Next steps

-* For more information on how to create diagnostic settings for Azure Cosmos DB, see [Create diagnostic settings](../cosmosdb-monitor-resource-logs.md).

-* For detailed information about how to create a diagnostic setting by using the Azure portal, the Azure CLI, or PowerShell, see [Create diagnostic settings to collect platform logs and metrics in Azure](../../azure-monitor/essentials/diagnostic-settings.md).

-| **Client drivers** | **SQL API** | **Azure Cosmos DB's API for Cassandra** | **Azure Cosmos DB's API for MongoDB** | **Gremlin API**|**Table API** |

-* If you donΓÇÖt want to rewrite your entire data access layer.

-This API stores data in a document structure, via BSON format. It is compatible with MongoDB wire protocol; however, it does not use any native MongoDB related code. This API is a great choice if you want to use the broader MongoDB ecosystem and skills, without compromising on using Azure Cosmos DBΓÇÖs features such as scaling, high availability, geo-replication, multiple write locations, automatic and transparent shard management, transparent replication between operational and analytical stores, and more.

-This API stores data in column-oriented schema. Apache Cassandra offers a highly distributed, horizontally scaling approach to storing large volumes of data while offering a flexible approach to a column-oriented schema. Cassandra API in Azure Cosmos DB aligns with this philosophy to approaching distributed NoSQL databases. Cassandra API is wire protocol compatible with the Apache Cassandra. You should consider Cassandra API if you want to benefit the elasticity and fully managed nature of Azure Cosmos DB and still use most of the native Apache Cassandra features, tools, and ecosystem. This means on Cassandra API you donΓÇÖt need to manage the OS, Java VM, garbage collector, read/write performance, nodes, clusters, etc.

-This API allows users to make graph queries and stores data as edges and vertices. Use this API for scenarios involving dynamic data, data with complex relations, data that is too complex to be modeled with relational databases, and if you want to use the existing Gremlin ecosystem and skills. Azure Cosmos DB's Gremlin API combines the power of graph database algorithms with highly scalable, managed infrastructure. It provides a unique, flexible solution to most common data problems associated with lack of flexibility and relational approaches. Gremlin API currently only supports OLTP scenarios.

-Azure Cosmos DB's Gremlin API is based on the [Apache TinkerPop](https://tinkerpop.apache.org/) graph computing framework. Gremlin API uses the same Graph query language to ingest and query data. It uses the Azure Cosmos DBΓÇÖs partition strategy to do the read/write operations from the Graph database engine. Gremlin API has a wire protocol support with the open-source Gremlin, so you can use the open-source Gremlin SDKs to build your application. Azure Cosmos DB Gremlin API also works with Apache Spark and [GraphFrames](https://github.com/graphframes/graphframes) for complex analytical graph scenarios. To learn more, see [Gremlin API](graph-introduction.md) article.

-This API stores data in key/value format. If you are currently using Azure Table storage, you may see some limitations in latency, scaling, throughput, global distribution, index management, low query performance. Table API overcomes these limitations and itΓÇÖs recommended to migrate your app if you want to use the benefits of Azure Cosmos DB. Table API only supports OLTP scenarios.

-* [Get started with Azure Cosmos DB's API for MongoDB](mongodb/create-mongodb-nodejs.md)

-* [Get started with Azure Cosmos DB's API for MongoDB](mongodb/create-mongodb-nodejs.md)

-To restore Azure Cosmos DB live accounts that are not deleted, it is a best practice to always identify the [latest restorable timestamp](get-latest-restore-timestamp.md) for the container. You can then use this timestamp to restore the account to it's latest version.

- |MongoRequests | Mongo | Logs user-initiated requests from the front end to serve requests to Azure Cosmos DB's API for MongoDB. When you enable this category, make sure to disable DataPlaneRequests. | `Requestcharge`, `opCode`, `retryCount`, `piiCommandText` |

- |CassandraRequests | Cassandra | Logs user-initiated requests from the front end to serve requests to Azure Cosmos DB's API for Cassandra. When you enable this category, make sure to disable DataPlaneRequests. | `operationName`, `requestCharge`, `piiCommandText` |

- |GremlinRequests | Gremlin | Logs user-initiated requests from the front end to serve requests to Azure Cosmos DB's API for Gremlin. When you enable this category, make sure to disable DataPlaneRequests. | `operationName`, `requestCharge`, `piiCommandText`, `retriedDueToRateLimiting` |

- |TableApiRequests | Table API | Logs user-initiated requests from the front end to serve requests to Azure Cosmos DB's API for Table. When you enable this category, make sure to disable DataPlaneRequests. | `operationName`, `requestCharge`, `piiCommandText` |

-* [Build a .NET web app using Azure Cosmos DB's API for MongoDB](mongodb/create-mongodb-dotnet.md)

-> The method of updating indexing policies described in this article only applies to Azure Cosmos DB's SQL (Core) API. Learn about indexing in [Azure Cosmos DB's API for MongoDB](mongodb/mongodb-indexing.md)

-description: Learn about Azure Cosmos DB. This globally-distributed multi-model database is built for low latency, elastic scalability, high availability, and offers native support for NoSQL data.

- - If all you know is the number of vcores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](convert-vcore-to-request-unit.md)

-description: This article presents an overview of Azure Cosmos DB indexing capabilities using Azure Cosmos DB's API for MongoDB

-# Manage indexing in Azure Cosmos DB's API for MongoDB

-Azure Cosmos DB's API for MongoDB takes advantage of the core index-management capabilities of Azure Cosmos DB. This article focuses on how to add indexes using Azure Cosmos DB's API for MongoDB. Indexes are specialized data structures that make querying your data roughly an order of magnitude faster.

-Azure Cosmos DB's API for MongoDB server version 3.6+ automatically indexes the `_id` field and the shard key (only in sharded collections). The API automatically enforces the uniqueness of the `_id` field per shard key.

-We recommend editing your indexing policy in the Data Explorer within the Azure portal.

-. You can add single field and wildcard indexes from the indexing policy editor in the Data Explorer:

-Many geospatial operators will benefit from geospatial indexes. Currently, Azure Cosmos DB's API for MongoDB supports `2dsphere` indexes. The API does not yet support `2d` indexes.

-Azure Cosmos DB's API for MongoDB does not currently support text indexes. For text search queries on strings, you should use [Azure Cognitive Search](../../search/search-howto-index-cosmosdb.md) integration with Azure Cosmos DB.

-**Unlike in MongoDB**, in Azure Cosmos DB's API for MongoDB you **can't** use wildcard indexes for:

-*cannot create unique index over {student_id : 1.0} with shard key pattern { university : 1.0 }*

-Version 3.6+ of Azure Cosmos DB's API for MongoDB support the `currentOp()` command to track index progress on a database instance. This command returns a document that contains information about in-progress operations on a database instance. You use the `currentOp` command to track all in-progress operations in native MongoDB. In Azure Cosmos DB's API for MongoDB, this command only supports tracking the index operation.

-Unlike the 3.6+ versions of Azure Cosmos DB's API for MongoDB, version 3.2 indexes every property by default. You can use the following command to drop these default indexes for a collection (```coll```):

- * If all you know is the number of vcores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](../convert-vcore-to-request-unit.md)

-description: Learn how to monitor the normalized request unit usage of an operation in Azure Cosmos DB. Owners of an Azure Cosmos DB account can understand which operations are consuming more request units.

-Azure Monitor for Azure Cosmos DB provides a metrics view to monitor your account and create dashboards. The Azure Cosmos DB metrics are collected by default, this feature does not require you to enable or configure anything explicitly.

-The **Normalized RU Consumption** metric is used to see how well saturated the partition key ranges are with respect to the traffic. Azure Cosmos DB distributes the throughput equally across all the partition key ranges. This metric provides a per second view of the maximum throughput utilization for partition key range. Use this metric to calculate the RU/s usage across partition key range for given container. By using this metric, if you see high percentage of request units utilization across all partition key ranges in Azure monitor, you should increase the throughput to meet the needs of your workload.

-Example - Normalized utilization is defined as the max of the RU/s utilization across all partition key ranges. For example, suppose your max throughput is 24,000 RU/s and you have three partition key ranges, P_1, P_2, and P_3 each capable of scaling to 8,000 RU/s. In a given second, if P_1 has used 6000 RUs, P_2 7000 RUs, and P_3 5000 RUs the normalized utilization is MAX(6000 RU / 8000 RU, 7000 RU / 8000 RU, 5000 RU / 8000 RU) = 0.875.

-When the normalized RU/s consumption reaches 100% for given partition key range, and if a client still makes requests in that time window of 1 second to that specific partition key range - it receives a rate limited error. The client should respect the suggested wait time and retry the request. The SDK makes it easy to handle this situation by retrying preconfigured times by waiting appropriately. It is not necessary that you see the RU rate limiting error just because the normalized RU has reached 100%. That's because the normalized RU is a single value that represents the max usage over all partition key ranges, one partition key range may be busy but the other partition key ranges can serve the requests without issues. For example, a single operation such as a stored procedure that consumes all the RU/s on a partition key range will lead to a short spike in the normalized RU/s consumption. In such cases, there will not be any immediate rate limiting errors if the request rate is low or requests are made to other partitions on different partition key ranges.

-The Azure Monitor metrics help you to find the operations per status code for SQL API by using the **Total Requests** metric. Later you can filter on these requests by the 429 status code and split them by **Operation Type**.

-To find the requests, which are rate limited, the recommended way is to get this information through diagnostic logs.

-If there is continuous peak of 100% normalized RU/s consumption or close to 100% across multiple partition key ranges, it's recommended to increase the throughput. You can find out which operations are heavy and their peak usage by utilizing the Azure monitor metrics and Azure monitor diagnostic logs.

-In summary, the **Normalized RU Consumption** metric is used to see which partition key range is more warm in terms of usage. So it gives you the skew of throughput towards a partition key range. You can later follow up to see the **PartitionKeyRUConsumption** log in Azure Monitor logs to get information about which logical partition keys are hot in terms of usage. This will point to change in either the partition key choice, or the change in application logic. To resolve the rate limiting, distribute the load of data say across multiple partitions or just increase in the throughput as it is required.

-### Filters for normalized request unit consumption

-You can also filter metrics and the chart displayed by a specific **CollectionName**, **DatabaseName**, **PartitionKeyRangeID**, and **Region**. To filter the metrics, select **Add filter** and choose the required property such as **CollectionName** and corresponding value you are interested in. The graph then displays the Normalized RU Consumption units consumed for the container for the selected period.

-* The number of throughput provisioned (each individual physical partition can provide a throughput of up to 10,000 request units per second). The 10,000 RU/s limit for physical partitions implies that logical partitions also have a 10,000 RU/s limit, as each logical partition is only mapped to one physical partition.

-If you provision a throughput of 18,000 request units per second (RU/s), then each of the three physical partition can utilize 1/3 of the total provisioned throughput. Within the selected physical partition, the logical partition keys `Beef Products`, `Vegetable and Vegetable Products`, and `Soups, Sauces, and Gravies` can, collectively, utilize the physical partition's 6,000 provisioned RU/s. Because provisioned throughput is evenly divided across your container's physical partitions, it's important to choose a partition key that evenly distributes throughput consumption by [choosing the right logical partition key](#choose-partitionkey).

-A partition key has two components: **partition key path** and the **partition key value**. For example, consider an item { "userId" : "Andrew", "worksFor": "Microsoft" } if you choose "userId" as the partition key, the following are the two partition key components:

-* The partition key path (For example: "/userId"). The partition key path accepts alphanumeric and underscore(_) characters. You can also use nested objects by using the standard path notation(/).

- * If all you know is the number of vcores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](convert-vcore-to-request-unit.md)

-1. **Provisioned throughput mode**: In this mode, you provision the number of RUs for your application on a per-second basis in increments of 100 RUs per second. To scale the provisioned throughput for your application, you can increase or decrease the number of RUs at any time in increments or decrements of 100 RUs. You can make your changes either programmatically or by using the Azure portal. You are billed on an hourly basis for the amount of RUs per second you have provisioned. To learn more, see the [Provisioned throughput](set-throughput.md) article.

-2. **Serverless mode**: In this mode, you don't have to provision any throughput when creating resources in your Azure Cosmos account. At the end of your billing period, you get billed for the amount of Request Units that has been consumed by your database operations. To learn more, see the [Serverless throughput](serverless.md) article.

-3. **Autoscale mode**: In this mode, you can automatically and instantly scale the throughput (RU/s) of your database or container based on it's usage, without impacting the availability, latency, throughput, or performance of the workload. This mode is well suited for mission-critical workloads that have variable or unpredictable traffic patterns, and require SLAs on high performance and scale. To learn more, see the [autoscale throughput](provision-throughput-autoscale.md) article.

- The same query on the same data will always costs the same number of RUs on repeated executions.

- - If all you know is the number of vcores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](convert-vcore-to-request-unit.md)

-| When using Direct mode with an account with multiple write locations, the SDK might not detect when a region is added to the account. The background process that [refreshes the account information](troubleshoot-sdk-availability.md#adding-a-region-to-an-account) fails to start. |If a new region is added to the account which is part of the PreferredLocations on a higher order than the current region, the SDK won't detect the new available region. |Restart the application. |https://github.com/Azure/azure-cosmos-dotnet-v2/issues/852 |

-| When using Direct mode with an account with multiple write locations, the SDK might not detect when a region is added to the account. The background process that [refreshes the account information](troubleshoot-sdk-availability.md#adding-a-region-to-an-account) fails to start. |If a new region is added to the account which is part of the PreferredLocations on a higher order than the current region, the SDK won't detect the new available region. |Restart the application. |https://github.com/Azure/azure-cosmos-dotnet-v2/issues/852 |

-This article contains known causes and solutions for various 429 status code errors for the SQL API. If you are using the API for MongoDB, see the [Troubleshoot common issues in API for MongoDB](../mongodb/error-codes-solutions.md) article for how to debug status code 16500.

-Before taking an action to change the RU/s, it's important to understand the root cause of rate limiting and address the underlying issue.

-This is the most common scenario. It occurs when the request units consumed by operations on data exceed the provisioned number of RU/s.

-Seeing 429 error messages doesn't necessarily mean there is a problem with your database or container.

-Determine what percent of your requests to your database or container resulted in 429s, compared to the overall count of successful requests. From your Azure Cosmos DB account blade, navigate to **Insights** > **Requests** > **Total Requests by Status Code**. Filter to a specific database and container.

-By default, the Azure Cosmos DB client SDKs and data import tools such as Azure Data Factory and bulk executor library automatically retry requests on 429s. They retry typically up to 9 times. As a result, while you may see 429s in the metrics, these errors may not even have been returned to your application.

-In general, for a production workload, if you see between 1-5% of requests with 429s, and your end to end latency is acceptable, this is a healthy sign that the RU/s are being fully utilized. No action is required. Otherwise, move to the next troubleshooting steps.

-### Step 2: Determine if there is a hot partition

-A hot partition arises when one or a few logical partition keys consume a disproportionate amount of the total RU/s due to higher request volume. This can be caused by a partition key design that doesn't evenly distribute requests. It results in many requests being directed to a small subset of logical (which implies physical) partitions that become "hot." Because all data for a logical partition resides on one physical partition and total RU/s is evenly distributed among the physical partitions, a hot partition can lead to 429s and inefficient use of throughput.

- - Instead, for this scenario, a partition key like `id` (either a GUID or device id), or a [synthetic partition key](./synthetic-partition-keys.md) combining `id` and `date` would yield a higher cardinality of values and better distribution of request volume.

- - For this previous scenario, consider having a dedicated container for the largest tenant, partitioned by a more granular property such as `UserId`.

-

-Each PartitionKeyRangeId maps to one physical partition. If there's one PartitionKeyRangeId that has significantly higher Normalized RU consumption than others (for example, one is consistently at 100%, but others are at 30% or less), this can be a sign of a hot partition. Learn more about the [Normalized RU Consumption metric](../monitor-normalized-request-units.md).

-To see which logical partition keys are consuming the most RU/s,

-use [Azure Diagnostic Logs](../cosmosdb-monitor-resource-logs.md). This sample query sums up the total request units consumed per second on each logical partition key.

-> Enabling diagnostic logs incurs a separate charge for the Log Analytics service, which is billed based on the volume of data ingested. It is recommended you turn on diagnostic logs for a limited amount of time for debugging, and turn off when no longer required. See [pricing page](https://azure.microsoft.com/pricing/details/monitor/) for details.

-```kusto

-AzureDiagnostics

-| where TimeGenerated >= ago(24hour)

-| where Category == "PartitionKeyRUConsumption"

-| where collectionName_s == "CollectionName"

-| where isnotempty(partitionKey_s)

-// Sum total request units consumed by logical partition key for each second

-| summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)

-| order by sum_requestCharge_s desc

-```

-This sample output shows that in a particular minute, the logical partition key with value "Contoso" consumed around 12,000 RU/s, while the logical partition key with value "Fabrikam" consumed less than 600 RU/s. If this pattern was consistent during the time period where rate limiting occurred, this would indicate a hot partition.

-> When you increase the throughput, the scale-up operation will either complete instantaneously or require up to 5-6 hours to complete, depending on the number of RU/s you want to scale up to. If you want to know the highest number of RU/s you can set without triggering the asynchronous scale-up operation (which requires Azure Cosmos DB to provision more physical partitions), multiply the number of distinct PartitionKeyRangeIds by 10,0000 RU/s. For example, if you have 30,000 RU/s provisioned and 5 physical partitions (6000 RU/s allocated per physical partition), you can increase to 50,000 RU/s (10,000 RU/s per physical partition) in an instantaneous scale-up operation. Increasing to >50,000 RU/s would require an asynchronous scale-up operation.

-Use [Azure Diagnostic Logs](../cosmosdb-monitor-resource-logs.md) to identify which requests are returning 429s and how many RUs they consumed. This sample query aggregates at the minute level.

-```kusto

-AzureDiagnostics

-| where TimeGenerated >= ago(24h)

-| where Category == "DataPlaneRequests"

-| summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, bin(TimeGenerated, 1min)

-| extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations

-| extend fractionOf429s = 1.0 * throttledOperations / totalOperations

-| order by fractionOf429s desc

-```

-You can leverage the [Azure Cosmos DB capacity planner](estimate-ru-with-capacity-planner.md) to understand what is the best provisioned throughput based on your workload (volume and type of operations and size of documents). You can customize further the calculations by providing sample data to get a more accurate estimation.

-This will lower the Request Units required per create document operation, which will reduce the likelihood of seeing 429s or allow you to achieve higher operations per second for the same amount of provisioned RU/s.

-Navigate to **Insights** > **System** > **Metadata Requests By Status Code**. Filter to a specific database and container if desired.

-[Azure Cosmos DB](../cosmos-db/introduction.md) is MicrosoftΓÇÖs fast NoSQL database with open APIs for any scale. The service is designed to allow customers to elastically (and independently) scale throughput and storage across any number of geographical regions. Azure Cosmos DB is the first globally distributed database service in the market today to offer comprehensive [service level agreements](https://azure.microsoft.com/support/legal/sla/cosmos-db/) encompassing throughput, latency, availability, and consistency.

-## Web Activity

- 1. Enter a **VLAN ID** as a unique number in 1-4094 range.

- 1. Enter a **VLAN ID** as a unique number in 1-4094 range.

-#Customer intent: As an IT admin, I need to understand what Azure Stack Edge Pro GPU is and how it works so I can use it to process and transform data before sending to Azure.

-The Azure Stack Edge Pro GPU physical device, Azure resource, and target storage account to which you transfer data donΓÇÖt all have to be in the same region.

- For a list of all the countries/regions where the Azure Stack Edge Pro GPU device is available, go to **Availability** section in the **Azure Stack Edge Pro** tab for [Azure Stack Edge Pro GPU pricing](https://azure.microsoft.com/pricing/details/azure-stack/edge/#azureStackEdgePro).

-These devices can be ordered via the Azure Edge Hardware center. These devices are billed as a monthly service through the Azure portal. For more information, see [Azure Stack Edge Pro 2 pricing](azure-stack-edge-placeholder.md).

-description: Learn how to use the Azure portal to add a virtual machine to a lab in Azure DevTest Labs. You can choose a base that is either a custom image or a formula.

-# Create and add virtual machines to a lab in Azure DevTest Labs

-This article walks you through on how to create and add Azure virtual machines (VMs) to a lab in your existing DevTest Labs using the Azure portal.

-## Create and add virtual machines

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

-1. Navigate to your lab in **DevTest Labs**.

-1. On the **Overview** page, select **+ Add**.

-1. On the **Choose a base** page, select a marketplace image for the VM. This guide use **Windows 11 Pro**. Certain options may differ if you use a different image.

-1. From the **Basics Settings** tab, provide the following information:

- |Property |Description |

- |||

- |Virtual&nbsp;machine&nbsp;name| The text box is pre-filled with a unique autogenerated name. The name corresponds to the user name within your email address followed by a unique three-digit number. Leave as-is, or enter a unique name of your choosing.|

- |User Name| The text box is pre-filled with a unique autogenerated name. The name corresponds to the user name within your email address. Leave as-is, or enter a name of your choosing. The user is granted **administrator** privileges on the virtual machine.|

- |Use a saved secret| For this walk-through, leave the box unchecked. You can save secrets in Azure Key Vault first and then use it here. For more information, see [Store secrets in a key vault](devtest-lab-store-secrets-in-key-vault.md). If you prefer to use a saved secret, check the box and then select the secret from the **Secret** drop-down list.|

- |Password|Enter a password between 8 and 123 characters long.|

- |Save as default password| Select the checkbox to save the password in the Azure Key Vault associated with the lab.|

- |Virtual machine size| Keep the default value or select **Change Size** to select different physical components. This walk-through uses **Standard_B2**.|

- |OS disk type|Keep the default value or select a different option from the drop-down list.|

- |Artifacts| Select **Add or Remove Artifacts**. Select and configure the artifacts that you want to add to the base image. Each lab includes artifacts from the Public DevTest Labs Artifact Repository and artifacts that you've created and added to your own Artifact Repository. For expanded instructions, see [Add artifacts during installation](#add-artifacts-during-installation), further below.|

-1. Select the **Advanced Settings** tab and provide the following information:

- |Property |Description |

- |||

- |Virtual network| Leave as-is or select a different network from the drop-down list.|

- |Subnet&nbsp;Selector| Leave as-is or select a different subnet from the drop-down list.|

- |IP address| For this walk-through, leave the default value **Shared**.|

- |Expiration date| Leave as is for no expiration date, or select the calendar icon to set an expiration date.|

- |Make this machine claimable| To make the VM claimable by a lab user, select **Yes**. Marking the machine as claimable means that it won't be assigned ownership at the time of creation. This walk-through selects **Yes**.|

- |Number of instances| For this walk-through, enter **2**. The number of virtual machine instances to be created.|

- |Automation | Optional. Selecting **View ARM Template** will open the template in a new page. You can copy and save the template to create the same virtual machine later. Once saved, you can use the Azure Resource Manager template to [deploy new VMs with Azure PowerShell](../azure-resource-manager/templates/overview.md).|

- :::image type="content" source="./media/devtest-lab-add-vm/portal-lab-vm-advanced-settings.png" alt-text="Virtual machine advanced settings page.":::

-1. Return to the **Basic Settings** tab and then select **Create**.

-1. From the **DevTest Lab** page, under **My Lab**, select **Claimable virtual machines**.

- :::image type="content" source="./media/devtest-lab-add-vm/portal-lab-vm-creation-status.png" alt-text="Lab VM creation status page.":::

-1. After a few minutes, select **Refresh** if your virtual machines don't appear. Installations times will vary based on the selected hardware, base image, and artifact(s). The installation for the configurations used in this walk-through was approximately 25 minutes.

-## Add artifacts during installation

-These steps are expanded instructions from the prior section. The steps begin after you've selected **Add or Remove Artifacts** from the **Basic Settings** tab. For more information on artifacts, see [Learn how to author your own artifacts for use with DevTest Labs](devtest-lab-artifact-author.md).

-1. From the **Add artifacts** page, identify an artifact, and then select **>** (greater-than symbol). Then select **OK**.

-1. Select another artifact: **Install PowerShell Module**. This artifact requires additional information, specifically, the name of a PowerShell module. Enter **Az**, and then select **OK**.

-1. Continue adding artifacts as needed for your VM.

-1. Select **...** (ellipsis) from one of your selected artifacts and note the various options, including the ability to change the install order.

-1. When you're done adding artifacts, select **OK** to return to the **Basic Settings** tab.

-## Add artifacts after installation

-You can also add artifacts after the VM has been created.

-1. From the **DevTest Lab** page, under **My Lab**, select **All resources**. **All resources** will list both claimed and unclaimed VMs.

- :::image type="content" source="./media/devtest-lab-add-vm/portal-lab-vm-all-resources.png" alt-text="Lab showing status of all resources.":::

-1. Select your VM once the **Status** shows **Available**.

-1. From your **virtual machine** page, select **Start** to start the VM.

-1. A few moments after the page shows **Running**, then under **Operations**, select **Artifacts**.

- :::image type="content" source="./media/devtest-lab-add-vm/portal-lab-vm-overview.png" alt-text="Lab VM overview showing start button.":::

-1. Select **Apply artifacts** to open the **Add artifacts** page.

-1. From here, the steps are basically the same as from [Add artifacts during installation](#add-artifacts-during-installation), above.

-* Once the VM has been created, you can connect to the VM by selecting **Connect** on the VM's pane.

-* Learn how to [create custom artifacts for your DevTest Labs VM](devtest-lab-artifact-author.md).

-* Explore the [DevTest Labs Azure Resource Manager QuickStart template gallery](https://github.com/Azure/azure-devtestlab/tree/master/samples/DevTestLabs/QuickStartTemplates).

-description: Learn the basic concepts of DevTest Labs, and how it can make it easy to create, manage, and monitor Azure virtual machines

-This article lists key DevTest Labs concepts and definitions:

-## Lab

-A lab is the infrastructure that encompasses a group of resources, such as Virtual Machines (VMs), that lets you better manage those resources by specifying limits and quotas.

-## Virtual machine

-An Azure VM is one type of [on-demand, scalable computing resource](/azure/architecture/guide/technology-choices/compute-decision-tree) that Azure offers. Azure VMs give you the flexibility of virtualization without having to buy and maintain the physical hardware that runs it.

-[Overview of Windows virtual machines in Azure](../virtual-machines/windows/overview.md) gives you information to consider before you create a VM, how you create it, and how you manage it.

-## Claimable VM

-An Azure Claimable VM is a virtual machine available to any lab user with permissions. Lab admins can prepare VMs with specific base images and artifacts and then save them to a shared pool. Lab users can claim a VM from the pool when they need one with that specific configuration.

-A VM that is claimable isn't initially assigned to any particular user, but will show up in every user's list under "Claimable virtual machines". After a VM is claimed by a user, it's moved up to **My virtual machines** and is no longer claimable by any other user.

-## Environment

-In DevTest Labs, an environment refers to a collection of Azure resources in a lab. [Create an environment](./devtest-lab-create-environment-from-arm.md) discusses how to create multi-VM environments from your Azure Resource Manager templates.

-## Base images

-Base images are VM images with all the tools and settings preinstalled and configured. You can create a VM by picking an existing base and adding an artifact to install your test agent. The use of base images reduces VM creation time.

-## Artifacts

-Artifacts are used to deploy and configure your application after a VM is provisioned. Artifacts can be:

-* Tools that you want to install on the VM - such as agents, Fiddler, and Visual Studio.

-* Actions that you want to run on the VM - such as cloning a repo.

-* Applications that you want to test.

-Artifacts are [Azure Resource Manager](../azure-resource-manager/management/overview.md) JSON files that contain instructions to deploy and apply configurations.

-## Artifact repositories

-Artifact repositories are git repositories where artifacts are checked in. Artifact repositories can be added to multiple labs in your organization enabling reuse and sharing.

-## Formulas

-Formulas provide a mechanism for fast VM provisioning. A formula in DevTest Labs is a list of default property values used to create a lab VM.

-With formulas, VMs with the same set of properties - such as base image, VM size, virtual network, and artifacts - can be created without needing to specify those

-properties each time. When creating a VM from a formula, the default values can be used as-is or modified.

-## Policies

-Policies help in controlling cost in your lab. For example, you can create a policy to automatically shut down VMs based on a defined schedule.

-## Caps

-Caps is a mechanism to minimize waste in your lab. For example, you can set a cap to restrict the number of VMs that can be created per user, or in a lab.

-## Security levels

-Security access is determined by Azure role-based access control (Azure RBAC). To understand how access works, it helps to understand the differences between a permission, a role, and a scope as defined by Azure RBAC.

-|Term | Description |

-|||

-|Permission|A defined access to a specific action (for example, read-access to all virtual machines).|

-|Role| A set of permissions that can be grouped and assigned to a user. For example, the *subscription owner* role has access to all resources within a subscription.|

-|Scope| A level within the hierarchy of an Azure resource, such as a resource group, a single lab, or the entire subscription.|

-Within the scope of DevTest Labs, there are two types of roles to define user permissions: lab owner and lab user.

-|Role | Description |

-|||

-|Lab&nbsp;Owner| Has access to any resources within the lab. A lab owner can modify policies, read and write any VMs, change the virtual network, and so on.|

-|Lab User | Can view all lab resources, such as VMs, policies, and virtual networks, but can't modify policies or any VMs created by other users.|

-To see how to create custom roles in DevTest Labs, refer to the article [Grant user permissions to specific lab policies](devtest-lab-grant-user-permissions-to-specific-lab-policies.md).

-Since scopes are hierarchical, when a user has permissions at a certain scope, they also have permissions at every lower-level scope. Subscription owners have access to all resources in a subscription, which include virtual machines, virtual networks, and labs. A subscription owner automatically inherits the role of lab owner. However, the opposite isn't true; a lab owner has access to a lab, which is a lower scope than the subscription level. So, a lab owner can't see virtual machines or virtual networks or any resources that are outside of the lab.

-## Azure Resource Manager templates

-The concepts discussed in this article can be configured by using Azure Resource Manager (ARM) templates. ARM templates let you define the infrastructure/configuration of your Azure solution and repeatedly deploy it in a consistent state.

-[Template format](../azure-resource-manager/templates/syntax.md#template-format) describes the structure of an Azure Resource Manager template and the properties that are available in the different sections of a template.

-## Next steps

-[Create a lab in DevTest Labs](devtest-lab-create-lab.md)

-description: In this quickstart, you create a lab using the Azure portal and Azure DevTest Labs.

-# Quickstart: Create a lab in Azure DevTest Labs in Azure portal

-Get started with Azure DevTest Labs by using the Azure portal to create a lab. Azure DevTest Labs encompasses a group of resources, such as Azure virtual machines (VMs) and networks. This infrastructure lets you better manage those resources by specifying limits and quotas. This quickstart walks you through the process of creating a lab using the Azure portal.

-## Prerequisites

-An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F). You must be the owner of the subscription to create the lab.

-## Sign in to the Azure portal

-By selecting the following link, you'll be transferred to the Azure portal page that allows you to start creating a new lab in Azure DevTest Labs.

-[Get started with Azure DevTest Labs in minutes](https://go.microsoft.com/fwlink/?LinkID=627034&clcid=0x409)

-## Create a DevTest Labs resource

-The **Create Devtest Lab** page contains five tabs. The first tab is **Basic Settings**.

-> At the bottom of each page, you will find a link that allows you to **download a template for automation**.

-### Basic Settings tab

-Provide the following information:

-|Property | Description |

-|||

-|Subscription| From the drop-down list, select the Azure subscription to be used for the lab.|

-|Resource&nbsp;group| From the drop-down list, select your existing resource group, or select **Create new**.|

-|Lab name| Enter a unique name within your subscription for the lab.|

-|Location| From the drop-down list, select a location that's used for the lab.|

-|Public environments| Public environment repository contains a list of curated Azure Resource Manager templates that enable lab users to create PaaS resources within Labs. For more information, see [Configure and use public environments](devtest-lab-configure-use-public-environments.md).|

-Auto-shutdown allows you to automatically shut down all machines in a lab at a scheduled time each day. The auto-shutdown feature is mainly a cost-saving feature. To change the auto-shutdown settings after creating the lab, see [Manage all policies for a lab in Azure DevTest Labs](./devtest-lab-set-lab-policy.md#set-auto-shutdown).

-Provide the following information:

-|Property | Description |

-|||

-|Enabled| Select **On** to enable this policy, or **Off** to disable it.|

-|Scheduled&nbsp;shutdown| Enter a time to shut down all VMs in the current lab.|

-|Time zone| Select a time zone from the drop-down list.|

-|Send notification before auto-shutdown? | Select **Yes** or **No** to send a notification 30 minutes before the specified auto-shutdown time. If you choose **Yes**, enter a webhook URL endpoint or email address specifying where you want the notification to be posted or sent. The user receives notification and is given the option to delay the shutdown.|

-|Webhook URL| A notification will be posted to the specified webhook endpoint when the auto-shutdown is about to happen.|

-|Email address| Enter a set of semicolon-delimited email addresses to receive alert notification emails.|

-A default network will be created for you (that can be changed/configured later), or an existing virtual network can be selected.

-Provide the following information:

-|Property | Description |

-|||

-|Virtual&nbsp;Network| Keep the default or select an existing one from the drop-down list. Virtual networks are logically isolated from each other in Azure. By default, virtual machines in the same virtual network can access each other.|

-|Subnet| Keep the default or select an existing one from the drop-down list. A subnet is a range of IP addresses in your virtual network, which can be used to isolate virtual machines from each other or from the Internet.|

-Tags are useful to help you manage and organize lab resources by category. For more information, see [Add tags to a lab](devtest-lab-add-tag.md).

-Provide the following information:

-|Property | Description |

-|||

-|Name| Tag names are case-insensitive and are limited to 512 characters.|

-|Value| Tag values are case-sensitive and are limited to 256 characters.|

-### Review + create tab

-The **Review + create** tab validates all of your configurations. If all settings are valid, **Succeeded** will appear at the top. Review your settings and then select **Create**. You can monitor the status of the lab creation process by watching the **Notifications** area at the top-right of the portal page.

-## Post creation

-1. After the creation process finishes, from the deployment notification, select **Go to resource**.

- :::image type="content" source="./media/devtest-lab-create-lab/creation-notification.png" alt-text="Screenshot of DevTest Labs deployment notification.":::

-1. The lab's **Overview** page looks similar to the following image:

- :::image type="content" source="./media/devtest-lab-create-lab/lab-home-page.png" alt-text="Screenshot of DevTest Labs overview page.":::

-Delete resources to avoid charges for running the lab on Azure. If you plan to go through the next article to add a VM to the lab, you can clean up the resources after you finish that article. Otherwise, follow these steps:

-1. Return to the home page for the lab you created.

-1. From the top menu, select **Delete**.

-1. On the **Are you sure you want to delete it** page, enter the lab name in the text box and then select **Delete**.

-1. During the deletion, you can select **Notifications** at the top of your screen to view progress. Deleting the lab takes a while. Continue to the next step once the lab is deleted.

-1. If you created the lab in an existing resource group, then all of the lab resources have been removed. If you created a new resource group for this tutorial, it's now empty and can be deleted. It wouldn't have been possible to have deleted the resource group earlier while the lab was still in it.

-In this quickstart, you created a lab. To learn how to add a VM, advance to the next article:

-description: Learn how DevTest Labs can make it easy to create, manage, and monitor Azure virtual machines

-Azure DevTest Labs is a service that enables developers to efficiently self-manage virtual machines (VMs) and Platform as a service (PaaS) resources without waiting for approvals. DevTest Labs creates labs consisting of pre-configured bases or Azure Resource Manager templates. These labs have all the necessary tools and software that you can use to create environments.

-By using DevTest Labs, you can test the latest versions of your applications by doing the following tasks:

-To learn more about the key concepts of DevTest Labs, see [DevTest Labs concepts](devtest-lab-concepts.md).

-## Cost control and governance

-DevTest Labs makes it easier to control costs by allowing you to do the following tasks:

-## Quickly get to ready-to-test

-DevTest Labs lets you create pre-provisioned environments to develop and test applications. Just [claim the environment](devtest-lab-add-claimable-vm.md) of your application's last good build and start working. Or use containers for even faster, leaner environment creation.

-## Create once, use everywhere

-Capture and share PaaS [environment templates](devtest-lab-create-environment-from-arm.md) and [artifacts](add-artifact-repository.md) within your team or organizationΓÇöall in source controlΓÇöto easily create developer and test environments.

-## Worry-free self-service

-DevTest Labs enables your developers and testers to quickly and easily [create IaaS VMs](devtest-lab-add-vm.md) and [PaaS resources](devtest-lab-create-environment-from-arm.md) by using a set of pre-configured resources.

-## Use IaaS and PaaS resources

-Spin up resources, such as Azure Service Fabric clusters, or SharePoint farms, by using Resource Manager templates. The templates come from the [public environment repository](devtest-lab-configure-use-public-environments.md) or [connect the lab to your own Git repository](devtest-lab-create-environment-from-arm.md#configure-your-own-template-repositories). You can also spin up an empty resource group (sandbox) by using a Resource Manager template to explore Azure within the context of a lab.

-## Integrate with your existing toolchain

-Use pre-made plug-ins or the API to create development/testing environments directly from your preferred [continuous integration (CI) tool](devtest-lab-integrate-ci-cd.md), integrated development environment (IDE), or automated release pipeline. You can also use the comprehensive command-line tool.

-See the following articles:

-To enable the Azure Firewall Premium Performance boost feature, run the following commands in Azure PowerShell. Stop and start the firewall for the feature to take effect immediatately. Otherwise, the firewall/s is updated with the feature within several days.

-Currently, the performance boost feature isn't recommended for SecureHub Firewalls. Refer back to this article for the latest updates as we work to change this recommendation. Also, this setting has no effect on Standard Firewalls.

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleHttpVersionConditionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleHttpVersionConditionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleCookiesConditionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleCookiesConditionParameters'

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleUrlFilenameConditionParameters'

-## Request file extension

- 'DELETE

- 'HTTP

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleCacheExpirationActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleCacheExpirationActionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleCacheKeyQueryStringBehaviorActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleCacheKeyQueryStringBehaviorActionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleHeaderActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleHeaderActionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleHeaderActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleHeaderActionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleUrlRedirectActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleUrlRedirectActionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleUrlRewriteActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleUrlRewriteActionParameters'

- "@odata.type": "#Microsoft.Azure.Cdn.Models.DeliveryRuleOriginGroupOverrideActionParameters"

- '@odata.type': '#Microsoft.Azure.Cdn.Models.DeliveryRuleOriginGroupOverrideActionParameters'

-Automatic hive log deletion is not configured in the advanced hive-log4j2 configurations. The default size limit of 60GB takes too much space for the customer's usage pattern.

-# FHIR Rest API capabilities for Azure API for FHIR

-# FHIR Rest API capabilities for Azure Healthcare APIs FHIR service

-You can create a workspace from the [Azure portal](../healthcare-apis-quickstart.md) or using PowerShell, Azure CLI and Rest API]. You can find scripts from the [Healthcare APIs samples](https://github.com/microsoft/healthcare-apis-samples/tree/main/src/scripts).

-In any case, the manufacturer uses an intermediate CA certificate at the end of this chain to sign the device CA certificate placed on the end device. Generally, these intermediate certificates are closely guarded at the manufacturing plant. They undergo strict processes, both physical and electronic for their usage.

-| Device CA Certificate | iotgateway.ca ("iotgateway" was passed in as the CA cert name to the convenience scripts) |

-| Microsoft Container Registry | mcr.microsoft.com | TCP | 443 |

-| Storage&nbsp;type | Authentication&nbsp;type | [Azure&nbsp;Machine&nbsp;Learning studio](https://ml.azure.com/) | [Azure&nbsp;Machine&nbsp;Learning&nbsp; Python SDK](/python/api/overview/azure/ml/intro) | [Azure&nbsp;Machine&nbsp;Learning CLI](reference-azure-machine-learning-cli.md) | [Azure&nbsp;Machine&nbsp;Learning&nbsp; Rest API](/rest/api/azureml/) | VS Code

-The following example shows a sample breakdown of costs and payouts to demonstrate the agency model. In this example, Microsoft bills $100.00 to the customer for your software license and pays out $80.00 to the publisher.

-| Analytics | Added a [Revenue Dashboard](revenue-dashboard.md) to Partner Center, including a revenue report, [sample queries](analytics-sample-queries.md#revenue-report-queries), and [FAQs](/azure/marketplace/analytics-faq#revenue) page. | 2021-12-08 |

-| Offers | Additional properties at the plan level are now available for Azure Virtual Machine offers. See the [virtual machine technical configuration properties](azure-vm-plan-technical-configuration.md#properties) article for more information. | 2021-07-26 |

-| Fees | Microsoft has reduced its standard store service fee to 3%. See [Commercial marketplace transact capabilities](marketplace-commercial-transaction-capabilities-and-considerations.md#examples-of-pricing-and-store-fees) and Common questions about payouts and taxes, "[How do I find the current Store Service Fee and the payout rate?](/partner-center/payout-faq)". | 2021-07-14 |

-| Taxation | End-customer taxation in Australia is managed by Microsoft, except for customer purchases made through an enterprise agreement, which are managed by the publisher. | 2021-07-01 |

-| Taxation | Updated [tax details page](/partner-center/tax-details-marketplace) country list to include the following: <br><br> - Argentina <br> - Bulgaria <br> - Hong Kong SAR <br> - Korea (South) <br>- Pakistan <br> - Palestinian Authority <br> - Panama <br> - Paraguay <br> - Peru <br> - Philippines <br> - Saint Kitts and Nevis <br> - Senegal <br> - Sri Lanka <br> - Tajikistan <br> - Tanzania <br> - Thailand <br> - Trinidad and Tobago <br> - Tunisia <br> - Turkmenistan <br> - Uganda <br> - Uzbekistan <br> - Zimbabwe | 2021-07-01 |

-| Taxation | Nigeria moved from the "shared publisher/developer-managed countries" list to the ΓÇ£end-customer taxation with differences in Marketplaces". | 2021-07-01 |

-| Payouts | Updated the payment schedule on [Payout schedules and processes](/partner-center/payout-policy-details), including terminology and graphics. | 2022-01-19 |

-> Currently, neither the Azure Media Services v3 Python SDK, nor Azure CLI did support the creation of a FaceRedaction Transform. We therefore the Rest API method to create the transform job.

-The [Microsoft.Azure.Management.Media](https://www.nuget.org/packages/Microsoft.Azure.Management.Media/5.0.0) .NET SDK version 5.0.0 is now released on NuGet. This version is generated to work with the [2021-06-01 stable](https://github.com/Azure/azure-rest-api-specs/tree/master/specification/mediaservices/resource-manager/Microsoft.Media/stable/2021-06-01) version of the Open API (Swagger) ARM Rest API.

- "description": "Rest API Functions\nhttps://msdn.microsoft.com/library/azure/jj683097.aspx\n",

-The [Azure Migrate appliance](migrate-appliance.md) is a lightweight appliance used by Azure Migrate: Discovery and assessment to discover on-premises servers running in VMware environment and send server configuration and performance metadata to Azure. The appliance can also be used to perform software inventory, agentless dependency analysis and discover of web app, and SQL Server instances and databases.

-If you want to use these features, you can provide server credentials by following the steps below. The appliance will attempt to automatically map the credentials to the servers to perform the discovery features.

-## Add credentials for servers running in VMware environment

-**Domain credentials** | You can add **Domain credentials** by selecting the option from the drop-down in the **Add credentials** modal. <br/><br/> To provide domain credentials, you need to specify the **Domain name** which must be provided in the FQDN format (for example, prod.corp.contoso.com). <br/><br/> You also need to specify a friendly name for credentials, username, and password. <br/><br/> The domain credentials added will be automatically validated for authenticity against the Active Directory of the domain. This is to prevent any account lockouts when the appliance attempts to map the domain credentials against discovered servers. <br/><br/>For the appliance to validate the domain credentials with the domain controller, it should be able to resolve the domain name. Ensure that you have provided the correct domain name while adding the credentials else the validation will fail.<br/><br/> The appliance will not attempt to map the domain credentials that have failed validation. You need to have at least one successfully validated domain credential or at least one non-domain credential to proceed with software inventory.<br/><br/>The domain credentials mapped automatically against the Windows servers will be used to perform software inventory and can also be used to discover web apps, and SQL Server instances and databases _(if you have configured Windows authentication mode on your SQL Servers)_.<br/> [Learn more](/dotnet/framework/data/adonet/sql/authentication-in-sql-server) about the types of authentication modes supported on SQL Servers.

-Review the tutorials for [discovery of servers running in your VMware environment](tutorial-discover-vmware.md)

-If you're using the Azure Migrate appliance for assessment, learn about the metadata and performance data that's collected for [VMware](migrate-appliance.md#collected-datavmware) and [Hyper-V](migrate-appliance.md#collected-datahyper-v).

-If you're using the Azure Migrate appliance for assessment, learn about the metadata and performance data that's collected for [VMware](migrate-appliance.md#collected-datavmware).

-| **Sizing criterion** | Sets the criteria to be used to determine memory, cpu and storage requirements for AVS nodes. You can opt for*performance-based* sizing or *as on-premises* without considering the performance history. To simply lift and shift choose as on-premises. To obtain usage based sizing choose performance based. |

-| **vCPU Oversubscription** | Specifies the ratio of number of virtual cores tied to one physical core in the AVS node. The default value in the calculations is 4 vCPU:1 physical core in AVS. API users can set this value as an integer. Note that vCPU Oversubscription > 4:1 may impact workloads depending on their CPU usage. When sizing we always assume 100% utilization of the cores chosen. |

-| **Memory overcommit factor** | Specifies the ratio of memory over commit on the cluster. A value of 1 represents 100% memory use, 0.5 for example is 50%, and 2 would be using 200% of available memory. You can only add values from 0.5 to 10 up to one decimal place. |

-AVS assessments assess each on-premises VMs for its suitability for AVS by reviewing the server properties. It also assigns each assessed server to one of the following suitability categories:

->If you import serves by using a CSV file, the performance values you specify (CPU utilization, Memory utilization, Storage in use, Disk IOPS and throughput) are used if you choose performance-based sizing. You will not be able to provide performance history and percentile information.

-**Storage sizing**: Azure Migrate uses the total on-premises VM disk space as a calculation parameter to determine AVS vSAN storage requirements in addition to the customer-selected FTT setting. FTT - Failures to tolerate as well as requiring a minimum no of nodes per FTT option will determine the total vSAN storage required combined with the VM disk requirement. If you import serves by using a CSV file, storage utilization is taken into consideration when you create a performance based assessment. If you create an as-on-premises assessment, the logic only looks at allocated storage per VM.

-CPU utilization assumes 100% usage of the available cores. To reduce the no of nodes required one can increase the oversubscription from 4:1 to say 6:1 based on workload characteristics and on-premises experience. Unlike for disk, AVS does not place any limits on CPU utilization, it's up to customers to ensure their cluster performs optimally so if "running hot" is required adjust accordingly. To allow more room for growth, reduce the oversubscription or increase the value for growth factor.

-1. Size required for VM's (either allocated as is or performance based used space)

-The available storage on a 3 node cluster will be based on the default storage policy which is Raid-1 and uses thick provisioning. When calculating for erasure coding or Raid-5 for example, a minimum of 4 nodes is required. Note that in Azure VMware Solution, the storage policy for customer workload can be changed by the admin or Run Command(Currently in Preview). [Learn more] (./azure-vmware/configure-storage-policy.md)

-The limiting factor shown in assessments could be CPU or memory or storage resources based on the utilization on nodes. It is the resource which is limiting or determining the number of hosts/nodes required to accommodate the resources. For example, in an assessment if it was found that after migrating 8 VMware VMs to Azure VMware Solution, 50% of CPU resources will be utilized, 14% of memory is utilized and 18% of storage will be utilized on the 3 Av36 nodes and thus CPU is the limiting factor.

- - For Hyper-V VMs dynamic memory is enabled

-> [!IMPORTANT]

->Agentless dependency analysis is currently available only for servers running in your VMware environment, discovered with the Azure Migrate:Discovery and assessment tool.

-## Deploy and configure the Azure Migrate appliance

-1. [Review](migrate-appliance.md#appliancevmware) the requirements for deploying the Azure Migrate appliance.

-2. Review the Azure URLs that the appliance will need to access in the [public](migrate-appliance.md#public-cloud-urls) and [government clouds](migrate-appliance.md#government-cloud-urls).

-3. [Review data](migrate-appliance.md#collected-datavmware) that the appliance collects during discovery and assessment.

-4. [Note](migrate-support-matrix-vmware.md#port-access-requirements) port access requirements for the appliance.

-5. [Deploy the Azure Migrate appliance](how-to-set-up-appliance-vmware.md) to start discovery. To deploy the appliance, you download and import an OVA template into VMware to create a server running in your vCenter Server. After deploying the appliance, you need to register it with the project and configure it to initiate the discovery.

-6. As you configure the appliance, you need to specify the following in the appliance configuration

- - The details of the vCenter Server to which you want to connect.

- - vCenter Server credentials scoped to discover the servers in your VMware environment.

- - Server credentials, which can be domain/ Windows(non-domain)/ Linux(non-domain) credentials. [Learn more](add-server-credentials.md) about how to provide credentials and how we handle them.

-## Verify permissions

-1. In **Step 1: Provide vCenter Server credentials**, click on **Add credentials** to provide credentials for the vCenter Server account that the appliance will use to discover servers running on the vCenter Server.

-1. In **Step 2: Provide vCenter Server details**, click on **Add discovery source** to select the friendly name for credentials from the drop-down, specify the **IP address/FQDN** of the vCenter Server instance

-1. In **Step 3: Provide server credentials to perform software inventory, agentless dependency analysis and discovery of SQL Server instances and databases**, click **Add credentials** to provide multiple server credentials to initiate software inventory.

-1. Click on **Start discovery**, to kick off vCenter Server discovery.

- After the vCenter Server discovery is complete, appliance initiates the discovery of installed applications, roles and features (software inventory).During software inventory, the added servers credentials will be iterated against servers and validated for agentless dependency analysis. You can enable agentless dependency analysis for servers from the portal. Only the servers where the validation succeeds can be selected to enable agentless dependency analysis.

-This article describes how to discover installed software inventory, web apps, and SQL Server instances and databases on servers running in your VMware environment, using Azure Migrate: Discovery and assessment tool.

-## Deploy and configure the Azure Migrate appliance

-1. [Review](migrate-appliance.md#appliancevmware) the requirements for deploying the Azure Migrate appliance.

-2. Review the Azure URLs that the appliance will need to access in the [public](migrate-appliance.md#public-cloud-urls) and [government clouds](migrate-appliance.md#government-cloud-urls).

-3. [Review data](migrate-appliance.md#collected-datavmware) that the appliance collects during discovery and assessment.

-4. [Note](migrate-support-matrix-vmware.md#port-access-requirements) port access requirements for the appliance.

-5. [Deploy the Azure Migrate appliance](how-to-set-up-appliance-vmware.md) to start discovery. To deploy the appliance, you download and import an OVA template into VMware to create a server running in your vCenter Server. After deploying the appliance, you need to register it with the project and configure it to initiate the discovery.

-6. As you configure the appliance, you need to specify the following in the appliance configuration

- - The details of the vCenter Server to which you want to connect.

- - vCenter Server credentials scoped to discover the servers in your VMware environment.

- - Server credentials, which can be domain/ Windows(non-domain)/ Linux(non-domain) credentials. [Learn more](add-server-credentials.md) about how to provide credentials and how we handle them.

-## Verify permissions

-1. In **Step 1: Provide vCenter Server credentials**, click on **Add credentials** to provide credentials for the vCenter Server account that the appliance will use to discover servers running on the vCenter Server.

-1. In **Step 2: Provide vCenter Server details**, click on **Add discovery source** to select the friendly name for credentials from the drop-down, specify the **IP address/FQDN** of the vCenter Server instance

-1. In **Step 3: Provide server credentials to perform software inventory, agentless dependency analysis, discovery of SQL Server instances and databases and discovery of ASP.NET web apps in your VMware environment.**, click **Add credentials** to provide multiple server credentials to initiate software inventory.

-1. Click on **Start discovery**, to kick off vCenter Server discovery.

- After the vCenter Server discovery is complete, appliance initiates the discovery of installed applications, roles, and features (software inventory). The duration depends on the number of discovered servers. For 500 servers, it takes approximately one hour for the discovered inventory to appear in the Azure Migrate portal.

-Software inventory identifies web server role existing on discovered servers. If a server is found to have web server role enabled, Azure Migrate will perform web apps discovery on the server.

-User can add both domain and non-domain credentials on appliance. Make sure that the account used has local admin privileges on source servers. Azure Migrate automatically maps credentials to the respective servers, so one doesnΓÇÖt have to map them manually. Most importantly, these credentials are never sent to Microsoft and remain on the appliance running in source environment.

-After the appliance is connected, it gathers configuration data for IIS web server and ASP.NET web apps. Web apps configuration data is updated once every 24 hours.

- 

- 

- 

- 

- 

-1. Click on **Start discovery**, to kick off server discovery from the successfully validated hosts/clusters. After the discovery has been successfully initiated, you can check the discovery status against each host/cluster in the table.

-This starts discovery. It takes approximately 2 minutes per host for metadata of discovered servers to appear in the Azure portal.

- 

- 

- 

- 

-1. Click on **Start discovery**, to kick off discovery of the successfully validated servers. After the discovery has been successfully initiated, you can check the discovery status against each server in the table.

-This starts discovery. It takes approximately 2 minutes per server for metadata of discovered server to appear in the Azure portal.

-description: Provides an overview of the Azure Migrate appliance used in server discovery, assessment, and migration.

-ms.

-# Azure Migrate appliance architecture

-This article describes the Azure Migrate appliance architecture and processes. The Azure Migrate appliance is a lightweight appliance that's deployed on premises, to discover servers for migration to Azure.

-## Deployment scenarios

-The Azure Migrate appliance is used in the following scenarios.

-**Scenario** | **Tool** | **Used to**

- | |

-**Discovery and assessment of servers running in VMware environment** | Azure Migrate: Discovery and assessment | Discover servers running in your VMware environment<br/><br/> Perform discovery of installed software inventory, ASP.NET web apps, SQL Server instances and databases, and agentless dependency analysis.<br/><br/> Collect server configuration and performance metadata for assessments.

-**Agentless migration of servers running in VMware environment** | Azure Migrate:Server Migration | Discover servers running in your VMware environment.<br/><br/> Replicate servers without installing any agents on them.

-**Discovery and assessment of servers running in Hyper-V environment** | Azure Migrate: Discovery and assessment | Discover servers running in your Hyper-V environment.<br/><br/> Collect server configuration and performance metadata for assessments.

-**Discovery and assessment of physical or virtualized servers on-premises** | Azure Migrate: Discovery and assessment | Discover physical or virtualized servers on-premises.<br/><br/> Collect server configuration and performance metadata for assessments.

-## Deployment methods

-The appliance can be deployed using the following methods:

-## Appliance services

-The appliance has the following

-> [!Note]

-> The last 4 services are only available in the appliance used for discovery and assessment of servers running in your VMware environment.

-## Discovery and collection process

-The appliance communicates with the discovery sources using the following process.

-**Process** | **VMware appliance** | **Hyper-V appliance** | **Physical appliance**

-|||

-**Start discovery** | The appliance communicates with the vCenter server on TCP port 443 by default. If the vCenter server listens on a different port, you can configure it in the appliance configuration manager. | The appliance communicates with the Hyper-V hosts on WinRM port 5985 (HTTP). | The appliance communicates with Windows servers over WinRM port 5985 (HTTP) with Linux servers over port 22 (TCP).

-**Gather configuration and performance metadata** | The appliance collects the metadata of servers running on vCenter Server(s) using vSphere APIs by connecting on port 443 (default port) or any other port each vCenter Server listens on. | The appliance collects the metadata of servers running on Hyper-V hosts using a Common Information Model (CIM) session with hosts on port 5985.| The appliance collects metadata from Windows servers using Common Information Model (CIM) session with servers on port 5985 and from Linux servers using SSH connectivity on port 22.

-**Send discovery data** | The appliance sends the collected data to Azure Migrate: Discovery and assessment and Azure Migrate: Server Migration over SSL port 443.<br/><br/> The appliance can connect to Azure over the internet or via ExpressRoute private peering or Microsoft peering circuits. | The appliance sends the collected data to Azure Migrate: Discovery and assessment over SSL port 443.<br/><br/> The appliance can connect to Azure over the internet or via ExpressRoute private peering or Microsoft peering circuits. | The appliance sends the collected data to Azure Migrate: Discovery and assessment over SSL port 443.<br/><br/> The appliance can connect to Azure over the internet or via ExpressRoute private peering or Microsoft peering circuits.

-**Data collection frequency** | Configuration metadata is collected and sent every 15 minutes. <br/><br/> Performance metadata is collected every 50 minutes to send a data point to Azure. <br/><br/> Software inventory data is sent to Azure once every 24 hours. <br/><br/> Agentless dependency data is collected every 5 minutes, aggregated on appliance and sent to Azure every 6 hours. <br/><br/> The SQL Server configuration data is updated once every 24 hours and the performance data is captured every 30 seconds. <br/><br/> The web apps configuration data is updated once every 24 hours. Performance data is not captured for web apps.| Configuration metadata is collected and sent every 30 minutes. <br/><br/> Performance metadata is collected every 30 seconds and is aggregated to send a data point to Azure every 15 minutes.| Configuration metadata is collected and sent every 3 hours. <br/><br/> Performance metadata is collected every 5 minutes to send a data point to Azure.

-**Assess and migrate** | You can create assessments from the metadata collected by the appliance using Azure Migrate: Discovery and assessment tool.<br/><br/>In addition, you can also start migrating servers running in your VMware environment using Azure Migrate: Server Migration tool to orchestrate agentless server replication.| You can create assessments from the metadata collected by the appliance using Azure Migrate: Discovery and assessment tool. | You can create assessments from the metadata collected by the appliance using Azure Migrate: Discovery and assessment tool.

-## Next steps

-[Review](migrate-appliance.md) the appliance support matrix.

-**Discovery and assessment of servers running in VMware environment** | Azure Migrate: Discovery and assessment | Discover servers running in your VMware environment<br><br> Perform discovery of installed software inventory, ASP.NET web apps, SQL Server instances and databases, and agentless dependency analysis.<br><br> Collect server configuration and performance metadata for assessments.

-**Agentless migration of servers running in VMware environment** | Azure Migrate: Server Migration | Discover servers running in your VMware environment. <br><br> Replicate servers without installing any agents on them.

-**Discovery and assessment of servers running in Hyper-V environment** | Azure Migrate: Discovery and assessment | Discover servers running in your Hyper-V environment.<br><br> Collect server configuration and performance metadata for assessments.

-**Discovery and assessment of physical or virtualized servers on-premises** | Azure Migrate: Discovery and assessment | Discover physical or virtualized servers on-premises.<br><br> Collect server configuration and performance metadata for assessments.

-**PowerShell script** | Refer to this [article](./deploy-appliance-script.md#set-up-the-appliance-for-vmware) on how to deploy an appliance using the PowerShell installer script.<br><br>

-**Hardware and network requirements** | The appliance should run on server with Windows Server 2016, 32-GB RAM, 8 vCPUs, around 80 GB of disk storage, and an external virtual switch.<br> The appliance requires internet access, either directly or through a proxy.<br><br> If you deploy the appliance using OVA template, you need enough resources on the vCenter Server to create a server that meets the hardware requirements.<br><br> If you run the appliance on an existing server, make sure that it is running Windows Server 2016, and meets hardware requirements.<br>_(Currently the deployment of appliance is only supported on Windows Server 2016.)_

-**VMware requirements** | If you deploy the appliance as a server on vCenter Server, it must be deployed on a vCenter Server running 5.5, 6.0, 6.5, 6.7 or 7.0 and an ESXi host running version 5.5 or later.<br><br>

-**PowerShell script** | Refer to this [article](./deploy-appliance-script.md#set-up-the-appliance-for-hyper-v) on how to deploy an appliance using the PowerShell installer script.<br>

-**Hardware and network requirements** | The appliance should run on server with Windows Server 2016, 16-GB RAM, 8 vCPUs, around 80 GB of disk storage, and an external virtual switch.<br> The appliance needs a static or dynamic IP address, and requires internet access, either directly or through a proxy.<br><br> If you run the appliance as a server running on a Hyper-V host, you need enough resources on the host to create a server that meets the hardware requirements.<br><br> If you run the appliance on an existing server, make sure that it is running Windows Server 2016, and meets hardware requirements.<br>_(Currently the deployment of appliance is only supported on Windows Server 2016.)_

-**Hyper-V requirements** | If you deploy the appliance with the VHD template, the appliance provided by Azure Migrate is Hyper-V VM version 5.0.<br><br> The Hyper-V host must be running Windows Server 2012 R2 or later.

-**Hardware and network requirements** | The appliance should run on server with Windows Server 2016, 16-GB RAM, 8 vCPUs, around 80 GB of disk storage.<br> The appliance needs a static or dynamic IP address, and requires internet access, either directly or through a proxy.<br><br> If you run the appliance on an existing server, make sure that it is running Windows Server 2016, and meets hardware requirements.<br>_(Currently the deployment of appliance is only supported on Windows Server 2016.)_

-*.cn2.hypervrecoverymanager.windowsazure.cn | **Used for VMware agentless migration.** Connect to Azure Migrate service URLs.

-## Collected data - VMware

-The appliance collects configuration metadata, performance metadata, and server dependencies data (if agentless [dependency analysis](concepts-dependency-visualization.md) is used).

-### Metadata

-Metadata discovered by the Azure Migrate appliance helps you to figure out whether servers are ready for migration to Azure, right-size servers, plans costs, and analyze application dependencies. Microsoft doesn't use this data in any license compliance audit.

-Here's the full list of server metadata that the appliance collects and sends to Azure.

-**DATA** | **COUNTER**

- |

-**Server details** |

-Server ID | vm.Config.InstanceUuid

-Server name | vm.Config.Name

-vCenter Server ID | VMwareClient.Instance.Uuid

-Server description | vm.Summary.Config.Annotation

-License product name | vm.Client.ServiceContent.About.LicenseProductName

-Operating system type | vm.SummaryConfig.GuestFullName

-Boot type | vm.Config.Firmware

-Number of cores | vm.Config.Hardware.NumCPU

-Memory (MB) | vm.Config.Hardware.MemoryMB

-Number of disks | vm.Config.Hardware.Device.ToList().FindAll(x => is VirtualDisk).count

-Disk size list | vm.Config.Hardware.Device.ToList().FindAll(x => is VirtualDisk)

-Network adapters list | vm.Config.Hardware.Device.ToList().FindAll(x => is VirtualEthernet).count

-CPU utilization | cpu.usage.average

-Memory utilization |mem.usage.average

-**Per disk details** |

-Disk key value | disk.Key

-Dikunit number | disk.UnitNumber

-Disk controller key value | disk.ControllerKey.Value

-Gigabytes provisioned | virtualDisk.DeviceInfo.Summary

-Disk name | Value generated using disk.UnitNumber, disk.Key, disk.ControllerKey.VAlue

-Read operations per second | virtualDisk.numberReadAveraged.average

-Write operations per second | virtualDisk.numberWriteAveraged.average

-Read throughput (MB per second) | virtualDisk.read.average

-Write throughput (MB per second) | virtualDisk.write.average

-**Per NIC details** |

-Network adapter name | nic.Key

-MAC address | ((VirtualEthernetCard)nic).MacAddress

-IPv4 addresses | vm.Guest.Net

-IPv6 addresses | vm.Guest.Net

-Read throughput (MB per second) | net.received.average

-Write throughput (MB per second) | net.transmitted.average

-**Inventory path details** |

-Name | container.GetType().Name

-Type of child object | container.ChildType

-Reference details | container.MoRef

-Parent details | Container.Parent

-Folder details per server | ((Folder)container).ChildEntity.Type

-Datacenter details per server | ((Datacenter)container).VmFolder

-Datacenter details per host folder | ((Datacenter)container).HostFolder

-Cluster details per host | ((ClusterComputeResource)container).Host

-Host details per server | ((HostSystem)container).VM

-### Performance data

-Here's the performance data that an appliance collects for a server running on VMware and sends to Azure.

-**Data** | **Counter** | **Assessment impact**

- | |

-CPU utilization | cpu.usage.average | Recommended server size/cost

-Memory utilization | mem.usage.average | Recommended server size/cost

-Disk read throughput (MB per second) | virtualDisk.read.average | Calculation for disk size, storage cost, server size

-Disk writes throughput (MB per second) | virtualDisk.write.average | Calculation for disk size, storage cost, server size

-Disk read operations per second | virtualDisk.numberReadAveraged.average | Calculation for disk size, storage cost, server size

-Disk writes operations per second | virtualDisk.numberWriteAveraged.average | Calculation for disk size, storage cost, server size

-NIC read throughput (MB per second) | net.received.average | Calculation for server size

-NIC writes throughput (MB per second) | net.transmitted.average |Calculation for server size

-### Installed software inventory

-The appliance collects data about installed software inventory on servers.

-#### Windows server software inventory data

-Here's the software inventory data that the appliance collects from each Windows server discovered in your VMware environment.

-**Data** | **Registry Location** | **Key**

- | |

-Application Name | HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* <br> HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | DisplayName

-Version | HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* <br> HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | DisplayVersion

-Provider | HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* <br> HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Publisher

-#### Windows server features data

-Here's the features data that the appliance collects from each Windows server discovered in your VMware environment.

-**Data** | **PowerShell cmdlet** | **Property**

- | |

-Name | Get-WindowsFeature | Name

-Feature Type | Get-WindowsFeature | FeatureType

-Parent | Get-WindowsFeature | Parent

-#### SQL Server metadata

-Here's the SQL Server data that the appliance collects from each Windows server discovered in your VMware environment.

-**Data** | **Registry Location** | **Key**

- | |

-Name | HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL | installedInstance

-Edition | HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\\\<InstanceName>\Setup | Edition

-Service Pack | HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\\\<InstanceName>\Setup | SP

-Version | HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\\\<InstanceName>\Setup | Version

-#### ASP.NET web apps data

-Here's the web apps configuration data that the appliance collects from each Windows server discovered in your VMware environment.

-**Entity** | **Data**

- |

-Web apps | Application Name <br>Configuration Path <br>Frontend Bindings <br>Enabled Frameworks <br>Hosting Web Server<br>Sub-Applications and virtual applications <br>Application Pool name <br>Runtime version <br>Managed pipeline mode

-Web server | Server Name <br>Server Type (currently only IIS) <br>Configuration Location <br>Version <br>FQDN <br>Credentials used for discovery <br>List of Applications

-#### Windows server operating system data

-Here's the operating system data that the appliance collects from each Windows server discovered in your VMware environment.

-**Data** | **WMI class** | **WMI Class Property**

- | |

-Name | Win32_operatingsystem | Caption

-Version | Win32_operatingsystem | Version

-Architecture | Win32_operatingsystem | OSArchitecture

-#### Linux server software inventory data

-Here's the software inventory data that the appliance collects from each Linux server discovered in your VMware environment. Based on the operating system of the server, one or more of the commands are run.

-**Data** | **Commands**

- |

-Name | rpm, dpkg-query, snap

-Version | rpm, dpkg-query, snap

-Provider | rpm, dpkg-query, snap

-#### Linux server operating system data

-Here's the operating system data that the appliance collects from each Linux server discovered in your VMware environment.

-**Data** | **Commands**

- |

-Name <br> version | Gathered from one or more of the following files:<br> <br>/etc/os-release <br> /usr/lib/os-release <br> /etc/enterprise-release <br> /etc/redhat-release <br> /etc/oracle-release <br> /etc/SuSE-release <br> /etc/lsb-release <br> /etc/debian_version

-Architecture | uname

-### SQL Server instances and databases data

-Appliance collects data on SQL Server instances and databases.

-#### SQL database metadata

-**Database Metadata** | **Views/ SQL Server properties**

- |

-Unique identifier of the database | sys.databases

-Server defined database ID | sys.databases

-Name of the database | sys.databases

-Compatibility level of database | sys.databases

-Collation name of database | sys.databases

-State of the database | sys.databases

-Size of the database (in MBs) | sys.master_files

-Drive letter of location containing data files | SERVERPROPERTY, and Software\Microsoft\MSSQLServer\MSSQLServer

-List of database files | sys.databases, sys.master_files

-Service broker is enabled or not | sys.databases

-Database is enabled for change data capture or not | sys.databases

-#### SQL Server metadata

-**Server Metadata** | **Views/ SQL server properties**

- |

-Server name |SERVERPROPERTY

-FQDN | Connection string derived from discovery of installed applications

-Install ID | sys.dm_server_registry

-Server version | SERVERPROPERTY

-Server edition | SERVERPROPERTY

-Server host platform (Windows/Linux) | SERVERPROPERTY

-Product level of the server (RTM SP CTP) | SERVERPROPERTY

-Default Backup path | SERVERPROPERTY

-Default path of the data files | SERVERPROPERTY, and Software\Microsoft\MSSQLServer\MSSQLServer

-Default path of the log files | SERVERPROPERTY, and Software\Microsoft\MSSQLServer\MSSQLServer

-No. of cores on the server | sys.dm_os_schedulers, sys.dm_os_sys_info

-Server collation name | SERVERPROPERTY

-No. of cores on the server with VISIBLE ONLINE status | sys.dm_os_schedulers

-Unique Server ID | sys.dm_server_registry

-HA enabled or not | SERVERPROPERTY

-Buffer Pool Extension enabled or not | sys.dm_os_buffer_pool_extension_configuration

-Failover cluster configured or not | SERVERPROPERTY

-Server using Windows Authentication mode only | SERVERPROPERTY

-Server installs PolyBase | SERVERPROPERTY

-No. of logical CPUs on the system | sys.dm_server_registry, sys.dm_os_sys_info

-Ratio of the no of logical or physical cores that are exposed by one physical processor package | sys.dm_os_schedulers, sys.dm_os_sys_info

-No of physical CPUs on the system | sys.dm_os_schedulers, sys.dm_os_sys_info

-Date and time server last started | sys.dm_server_registry

-Max server memory use (in MBs) | sys.dm_os_process_memory

-Total no. of users across all databases | sys.databases, sys.logins

-Total size of all user databases | sys.databases

-Size of temp database | sys.master_files, sys.configurations, sys.dm_os_sys_info

-No. of logins | sys.logins

-List of linked servers | sys.servers

-List of agent job | [msdb].[dbo].[sysjobs], [sys].[syslogins], [msdb].[dbo].[syscategories]

-### Performance metadata

-**Performance** | **Views/ SQL server properties** | **Assessment Impact**

- | |

-SQL Server CPU utilization| sys.dm_os_ring_buffers| Recommended SKU size (CPU dimension)

-SQL logical CPU count| sys.dm_os_sys_info| Recommended SKU size (CPU dimension)

-SQL physical memory in use| sys.dm_os_process_memory| Unused

-SQL memory utilization percentage| sys.dm_os_process_memory | Unused

-Database CPU utilization| sys.dm_exec_query_stats, sys.dm_exec_plan_attributes| Recommended SKU size (CPU dimension)

-Database memory in use (buffer pool)| sys.dm_os_buffer_descriptors| Recommended SKU size (Memory dimension)

-File read/write IO| sys.dm_io_virtual_file_stats, sys.master_files| Recommended SKU size (IO dimension)

-File num of reads/writes| sys.dm_io_virtual_file_stats, sys.master_files| Recommended SKU size (Throughput dimension)

-File IO stall read/write (ms)| sys.dm_io_virtual_file_stats, sys.master_files| Recommended SKU size (IO latency dimension)

-File size| sys.master_files| Recommended SKU size (Storage dimension)

-### Application dependency data

-Agentless dependency analysis collects the connection and process data.

-#### Windows server dependencies data

-Here's the connection data that the appliance collects from each Windows server, enabled for agentless dependency analysis.

-**Data** | **Commands**

- |

-Local port | netstat

-Local IP address | netstat

-Remote port | netstat

-Remote IP address | netstat

-TCP connection state | netstat

-Process ID | netstat

-Number of active connections | netstat

-Here's the connection data that the appliance collects from each Windows server, enabled for agentless dependency analysis.

-**Data** | **WMI class** | **WMI class property**

- | |

-Process name | Win32_Process | ExecutablePath

-Process arguments | Win32_Process | CommandLine

-Application name | Win32_Process | VersionInfo.ProductName parameter of ExecutablePath property

-#### Linux server dependencies data

-Here's the connection data that the appliance collects from each Linux server, enabled for agentless dependency analysis.

-**Data** | **Commands**

- |

-Local port | netstat

-Local IP address | netstat

-Remote port | netstat

-Remote IP address | netstat

-TCP connection state | netstat

-Number of active connections | netstat

-Process ID | netstat

-Process name | ps

-Process arguments | ps

-Application name | dpkg or rpm

-## Collected data - Hyper-V

-The appliance collects configuration and performance metadata from servers running in Hyper-V environment.

-### Metadata

-Metadata discovered by the Azure Migrate appliance helps you to figure out whether servers are ready for migration to Azure, right-size servers, and plans costs. Microsoft doesn't use this data in any license compliance audit.

-Here's the full list of server metadata that the appliance collects and sends to Azure.

-**Data** | **WMI class** | **WMI class property**

- | |

-**Server details** |

-Serial number of BIOS | Msvm_BIOSElement | BIOSSerialNumber

-Server type (Gen 1 or 2) | Msvm_VirtualSystemSettingData | VirtualSystemSubType

-Server display name | Msvm_VirtualSystemSettingData | ElementName

-Server version | Msvm_ProcessorSettingData | VirtualQuantity

-Memory (bytes) | Msvm_MemorySettingData | VirtualQuantity

-Maximum memory that can be consumed by server | Msvm_MemorySettingData | Limit

-Dynamic memory enabled | Msvm_MemorySettingData | DynamicMemoryEnabled

-Operating system name/version/FQDN | Msvm_KvpExchangeComponent | GuestIntrinsicExchangeItems Name Data

-Server power status | Msvm_ComputerSystem | EnabledState

-**Per disk details** |

-Disk identifier | Msvm_VirtualHardDiskSettingData | VirtualDiskId

-Virtual hard disk type | Msvm_VirtualHardDiskSettingData | Type

-Virtual hard disk size | Msvm_VirtualHardDiskSettingData | MaxInternalSize

-Virtual hard disk parent | Msvm_VirtualHardDiskSettingData | ParentPath

-**Per NIC details** |

-IP addresses (synthetic NICs) | Msvm_GuestNetworkAdapterConfiguration | IPAddresses

-DHCP enabled (synthetic NICs) | Msvm_GuestNetworkAdapterConfiguration | DHCPEnabled

-NIC ID (synthetic NICs) | Msvm_SyntheticEthernetPortSettingData | InstanceID

-NIC MAC address (synthetic NICs) | Msvm_SyntheticEthernetPortSettingData | Address

-NIC ID (legacy NICs) | MsvmEmulatedEthernetPortSetting Data | InstanceID

-NIC MAC ID (legacy NICs) | MsvmEmulatedEthernetPortSetting Data | Address

-### Performance data

-Here's the server performance data that the appliance collects and sends to Azure.

-**Performance counter class** | **Counter** | **Assessment impact**

- | |

-Hyper-V Hypervisor Virtual Processor | % Guest Run Time | Recommended server size/cost

-Hyper-V Dynamic Memory Server | Current Pressure (%)<br> Guest Visible Physical Memory (MB) | Recommended server size/cost

-Hyper-V Virtual Storage Device | Read Bytes/Second | Calculation for disk size, storage cost, server size

-Hyper-V Virtual Storage Device | Write Bytes/Second | Calculation for disk size, storage cost, server size

-Hyper-V Virtual Network Adapter | Bytes Received/Second | Calculation for server size

-Hyper-V Virtual Network Adapter | Bytes Sent/Second | Calculation for server size

-## Collected data - Physical

-The appliance collects configuration and performance metadata from physical or virtual servers running on-premises.

-### Metadata

-Metadata discovered by the Azure Migrate appliance helps you to figure out whether servers are ready for migration to Azure, right-size servers, and plans costs. Microsoft doesn't use this data in any license compliance audit.

-### Windows server metadata

-Here's the full list of Windows server metadata that the appliance collects and sends to Azure.

-**Data** | **WMI class** | **WMI class property**

- | |

-FQDN | Win32_ComputerSystem | Domain, Name, PartOfDomain

-Processor core count | Win32_PRocessor | NumberOfCores

-Memory allocated | Win32_ComputerSystem | TotalPhysicalMemory

-BIOS serial number | Win32_ComputerSystemProduct | IdentifyingNumber

-BIOS GUID | Win32_ComputerSystemProduct | UUID

-Boot type | Win32_DiskPartition | Check for partition with Type = **GPT:System** for EFI/BIOS

-OS name | Win32_OperatingSystem | Caption

-OS version |Win32_OperatingSystem | Version

-OS architecture | Win32_OperatingSystem | OSArchitecture

-Disk count | Win32_DiskDrive | Model, Size, DeviceID, MediaType, Name

-Disk size | Win32_DiskDrive | Size

-NIC list | Win32_NetworkAdapterConfiguration | Description, Index

-NIC IP address | Win32_NetworkAdapterConfiguration | IPAddress

-NIC MAC address | Win32_NetworkAdapterConfiguration | MACAddress

-### Linux server metadata

-Here's the full list of Linux server metadata that the appliance collects and sends to Azure.

-**Data** | **Commands**

- |

-FQDN | cat /proc/sys/kernel/hostname, hostname -f

-Processor core count | cat/proc/cpuinfo \| awk '/^processor/{print $3}' \| wc -l

-Memory allocated | cat /proc/meminfo \| grep MemTotal \| awk '{printf "%.0f", $2/1024}'

-BIOS serial number | lshw \| grep "serial:" \| head -n1 \| awk '{print $2}' <br> /usr/sbin/dmidecode -t 1 \| grep 'Serial' \| awk '{ $1="" ; $2=""; print}'

-BIOS GUID | cat /sys/class/dmi/id/product_uuid

-Boot type | [ -d /sys/firmware/efi ] && echo EFI \|\| echo BIOS

-OS name/version | We access these files for the OS version and name:<br><br> /etc/os-release<br> /usr/lib/os-release <br> /etc/enterprise-release <br> /etc/redhat-release<br> /etc/oracle-release<br> /etc/SuSE-release<br> /etc/lsb-release <br> /etc/debian_version

-OS architecture | uname -m

-Disk count | fdisk -l \| egrep 'Disk.*bytes' \| awk '{print $2}' \| cut -f1 -d ':'

-Boot disk | df /boot \| sed -n 2p \| awk '{print $1}'

-Disk size | fdisk -l \| egrep 'Disk.*bytes' \| egrep $disk: \| awk '{print $5}'

-NIC list | ip -o -4 addr show \| awk '{print $2}'

-NIC IP address | ip addr show $nic \| grep inet \| awk '{print $2}' \| cut -f1 -d "/"

-NIC MAC address | ip addr show $nic \| grep ether \| awk '{print $2}'

-### Windows performance data

-Here's the Windows server performance data that the appliance collects and sends to Azure.

-**Data** | **WMI class** | **WMI class property**

- | |

-CPU usage | Win32_PerfFormattedData_PerfOS_Processor | PercentIdleTime

-Memory usage | Win32_PerfFormattedData_PerfOS_Memory | AvailableMBytes

-NIC count | Win32_PerfFormattedData_Tcpip_NetworkInterface | Get the network device count.

-Data received per NIC | Win32_PerfFormattedData_Tcpip_NetworkInterface | BytesReceivedPerSec

-Data transmitted per NIC | BWin32_PerfFormattedData_Tcpip_NetworkInterface | BytesSentPersec

-Disk count | BWin32_PerfFormattedData_PerfDisk_PhysicalDisk | Count of disks

-Disk details | Win32_PerfFormattedData_PerfDisk_PhysicalDisk | DiskWritesPerSec, DiskWriteBytesPerSec, DiskReadsPerSec, DiskReadBytesPerSec.

-### Linux performance data

-Here's the Linux server performance data that the appliance collects and sends to Azure.

-| **Data** | **Commands** |

-| | |

-| CPU usage | cat /proc/stat/ \| grep 'cpu' /proc/stat |

-| Memory usage | free \| grep Mem \| awk '{print $3/$2 * 100.0}' |

-| NIC count | lshw -class network \| grep eth[0-60] \| wc -l |

-| Data received per NIC | cat /sys/class/net/eth$nic/statistics/rx_bytes |

-| Data transmitted per NIC | cat /sys/class/net/eth$nic/statistics/tx_bytes |

-| Disk count | fdisk -l \| egrep 'Disk.\*bytes' \| awk '{print $2}' \| cut -f1 -d ':' |

-| Disk details | cat /proc/diskstats |

- 

- 

- 

- 

-**Hyper-V host/cluster** | Inbound connection on WinRM port 5985 (HTTP) or 5986 (HTTPS) to pull metadata and performance data for servers on Hyper-V, using a Common Information Model (CIM) session.

-> Currently, Azure Migrate does not support the discovery of para-virtualized servers.

- **Command** | **Purpose**

- | |

- `setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/fdisk` <br></br> `setcap CAP_DAC_READ_SEARCH+eip /sbin/fdisk` _(if /usr/sbin/fdisk is not present)_ | To collect disk configuration data

- `setcap "cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid,<br>cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin,<br>cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvm` | To collect disk performance data

- `setcap CAP_DAC_READ_SEARCH+eip /usr/sbin/dmidecode` | To collect BIOS serial number

- `chmod a+r /sys/class/dmi/id/product_uuid` | To collect BIOS GUID

-In addition to discovering servers, Azure Migrate: Discovery and assessment can perform software inventory on servers. Software inventory allows you to identify and plan a migration path tailored for your on-premises workloads.

-**Supported servers** | Currently supported only for servers in your VMware environment. You can perform software inventory on up to 10,000 servers from each Azure Migrate appliance.

-**VM requirements** | For software inventory, VMware Tools must be installed and running on your servers. <br /><br /> The VMware Tools version must be version 10.2.1 or later.<br /><br /> Windows servers must have PowerShell version 2.0 or later installed.

-**Discovery** | Software inventory is performed from vCenter Server by using VMware Tools installed on the servers. The appliance gathers the information about the software inventory from the server running vCenter Server through vSphere APIs. Software inventory is agentless. No agent is installed on the server, and the appliance doesn't connect directly to the servers. WMI must be enabled and available on Windows servers to gather the details of the roles and features installed on the servers.

-**vCenter Server user account** | To interact with the servers for software inventory, the vCenter Server read-only account that's used for assessment must have privileges for guest operations on VMware VMs.

-[Dependency analysis](concepts-dependency-visualization.md) helps you identify dependencies between on-premises servers that you want to assess and migrate to Azure. The following table summarizes the requirements for setting up agentless dependency analysis:

-**Supported servers** | You can enable agentless dependency analysis on up to 1000 servers (across multiple vCenter Servers), discovered per appliance. Currently supported only for servers in your VMware environment.

-**Server requirements** | VMware Tools (10.2.1 and later) must be installed and running on servers you want to analyze.<br /><br /> Servers must have PowerShell version 2.0 or later installed.

-**Discovery method** | Dependency information between servers is gathered by using VMware Tools installed on the server running vCenter Server. The appliance gathers the information from the server by using vSphere APIs. No agent is installed on the server, and the appliance doesnΓÇÖt connect directly to servers. WMI should be enabled and available on Windows servers.

-**vCenter account** | The read-only account used by Azure Migrate for assessment must have privileges for guest operations on VMware VMs.

-**Windows server permissions** | A user account (local or domain) with administrator permissions on servers.

-**Linux account** | A root user account, or an account that has these permissions on /bin/netstat and /bin/ls files: <br />CAP_DAC_READ_SEARCH<br /> CAP_SYS_PTRACE<br /><br /> Set these capabilities by using the following commands:<br /><code>sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/ls<br /> sudo setcap CAP_DAC_READ_SEARCH,CAP_SYS_PTRACE=ep /bin/netstat</code>

-Azure Migrate supports agentless dependency analysis by using Azure Migrate: Discovery and assessment. Agentless dependency analysis is currently supported for VMware only. [Learn more](how-to-create-group-machine-dependencies-agentless.md) about the requirements for agentless dependency analysis.

-The list of agentless dependency analysis errors is summarized in the following table.

-After you install the required PowerShell version, verify if the error was resolved by following the steps on [this website](troubleshoot-dependencies.md#mitigation-verification-by-using-vmware-powercli).

-After you get the required access, verify if the error was resolved by following the steps on [this website](troubleshoot-dependencies.md#mitigation-verification-by-using-vmware-powercli).

-## Mitigation verification by using VMware PowerCLI

-1. After you verify that the mitigation worked, go to the **Azure Migrate project** > **Discovery and assessment** > **Overview** > **Manage** > **Appliances**, select the appliance name, and select **Refresh services** to start a fresh discovery cycle.

-Azure Migrate supports software inventory by using Azure Migrate: Discovery and assessment. Software inventory is currently supported for VMware only. [Learn more](how-to-discover-applications.md) about the requirements for software inventory.

-The list of software inventory errors is summarized in the following table.

-After you install the required PowerShell version, verify if the error was resolved by following the steps on [this website](troubleshoot-discovery.md#mitigation-verification-by-using-vmware-powercli).

-After you get the required access, verify if the error was resolved by following the steps on [this website](troubleshoot-discovery.md#mitigation-verification-by-using-vmware-powercli).

-## Mitigation verification by using VMware PowerCLI

-1. For agentless dependency analysis, run the following commands to see if you get a successful output:

- - For Windows servers:

- ````

- Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'Get-WmiObject Win32_Process'" -GuestCredential $credential

-

- Invoke-VMScript -VM $vm -ScriptText "powershell.exe 'netstat -ano -p tcp'" -GuestCredential $credential

- ````

- - For Linux servers:

- ````

- Invoke-VMScript -VM $vm -ScriptText "ps -o pid,cmd | grep -v ]$" -GuestCredential $credential

- Invoke-VMScript -VM $vm -ScriptText "netstat -atnp | awk '{print $4,$5,$7}'" -GuestCredential $credential

- ````

-1. After you verify that the mitigation worked, go to the **Azure Migrate project** > **Discovery and assessment** > **Overview** > **Manage** > **Appliances**, select the appliance name, and select **Refresh services** to start a fresh discovery cycle.

-**Windows instances** | Allow inbound connections on WinRM port 5985 (HTTP), so that the appliance can pull configuration and performance metadata.

-**Linux instances** | Allow inbound connections on port 22 (TCP).<br/><br/> The instances should use `bash` as the default shell, otherwise discovery will fail.

-* Permissions to register Azure Active Directory (AAD) apps.

- 

- 

- 

-1. To register the appliance, your Azure account needs **permissions to register AAD apps.**

- 

-1. In case the 'App registrations' settings is set to 'No', request the tenant/global admin to assign the required permission. Alternately, the tenant/global admin can assign the **Application Developer** role to an account to allow the registration of AAD App. [Learn more](../active-directory/fundamentals/active-directory-users-assign-role-azure-portal.md).

- 

-

- 

- 

-1. Click on **Start discovery**, to kick off discovery of the successfully validated servers. After the discovery has been successfully initiated, you can check the discovery status against each server in the table.

-This starts discovery. It takes approximately 2 minutes per server for metadata of discovered server to appear in the Azure portal.

-**Windows server instances** | Allow inbound connections on WinRM port 5985 (HTTP), so that the appliance can pull configuration and performance metadata.

-**Linux server instances** | Allow inbound connections on port 22 (TCP).

-* Permissions to register Azure Active Directory (AAD) apps.

- 

- 

- 

-1. To register the appliance, your Azure account needs **permissions to register AAD apps.**

- 

-1. In case the 'App registrations' settings is set to 'No', request the tenant/global admin to assign the required permission. Alternately, the tenant/global admin can assign the **Application Developer** role to an account to allow the registration of AAD App. [Learn more](../active-directory/fundamentals/active-directory-users-assign-role-azure-portal.md).

- 

-

- 

- 

-7. Click on **Start discovery**, to kick off discovery of the successfully validated servers. After the discovery has been successfully initiated, you can check the discovery status against each server in the table.

-This starts discovery. It takes approximately 2 minutes per server for metadata of discovered server to appear in the Azure portal.

-* [Review the data](migrate-appliance.md#collected-dataphysical) that the appliance collects during discovery.

-**Servers** | Servers can be running any Windows or Linux operating system.

- 

- 

- 

-1. To register the appliance, your Azure account needs **permissions to register AAD apps.**

-1. In Azure portal, navigate to **Azure Active Directory** > **Users** > **User Settings**.

- 

-9. In case the 'App registrations' settings is set to 'No', request the tenant/global admin to assign the required permission. Alternately, the tenant/global admin can assign the **Application Developer** role to an account to allow the registration of AAD App. [Learn more](../active-directory/fundamentals/active-directory-users-assign-role-azure-portal.md).

- 

-

-Make sure that the appliance can connect to Azure URLs for [public](migrate-appliance.md#public-cloud-urls) and [government](migrate-appliance.md#government-cloud-urls) clouds.

- 

-1. Click on **Start discovery**, to kick off server discovery from the successfully validated hosts/clusters. After the discovery has been successfully initiated, you can check the discovery status against each host/cluster in the table.

-This starts discovery. It takes approximately 2 minutes per host for metadata of discovered servers to appear in the Azure portal.

-Before you start this tutorial, check you have these prerequisites in place.

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

-**Windows servers** | Allow inbound connections on WinRM port 5985 (HTTP), so that the appliance can pull configuration and performance metadata.

-**Linux servers** | Allow inbound connections on port 22 (TCP).

- 

-2. In the **Subscriptions** page, select the subscription in which you want to create project.

- 

- 

-1. To register the appliance, your Azure account needs **permissions to register AAD apps.**

- 

-9. In case the 'App registrations' settings is set to 'No', request the tenant/global admin to assign the required permission. Alternately, the tenant/global admin can assign the **Application Developer** role to an account to allow the registration of AAD App. [Learn more](../active-directory/fundamentals/active-directory-users-assign-role-azure-portal.md).

-setcap "cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_setuid,<br>cap_setpcap,cap_net_bind_service,cap_net_admin,cap_sys_chroot,cap_sys_admin,<br>cap_sys_resource,cap_audit_control,cap_setfcap=+eip" /sbin/lvm | To collect disk performance data

- 

-

-> If you have already created a project, you can use the same project to register additional appliances to discover and assess more no of servers.[Learn more](create-manage-projects.md#find-a-project)

-To set up the appliance you:

-2. Download a zipped file with Azure Migrate installer script from the Azure portal.

- [ ](./media/tutorial-assess-physical/generate-key-physical-expanded-1.png#lightbox)

-In **2: Download Azure Migrate appliance**, click on **Download**.

-5. Select from the scenario, cloud and connectivity options to deploy an appliance with the desired configuration. For instance, the selection shown below sets up an appliance to discover and assess **physical servers** _(or servers running on other clouds like AWS, GCP, Xen etc.)_ to an Azure Migrate project with **default _(public endpoint)_ connectivity** on **Azure public cloud**.

- :::image type="content" source="./media/tutorial-discover-physical/script-physical-default-inline.png" alt-text="Screenshot that shows how to set up appliance with desired configuration" lightbox="./media/tutorial-discover-physical/script-physical-default-expanded.png":::

- - Install Windows roles, including Windows Activation Service, IIS, and PowerShell ISE.

- - Download and installs an IIS rewritable module.

-1. Paste the **project key** copied from the portal. If you do not have the key, go to **Azure Migrate: Discovery and assessment> Discover> Manage existing appliances**, select the appliance name you provided at the time of key generation and copy the corresponding key.

- 

-1. On the new tab, paste the device code and sign-in by using your Azure username and password. Sign-in with a PIN isn't supported.

-1. After you successfully logged in, go back to the previous tab with the appliance configuration manager.

-1. If the Azure user account used for logging has the right [permissions]() on the Azure resources created during key generation, the appliance registration will be initiated.

- 

- - If you choose **Add multiple items**, you can add multiple records at once by specifying server **IP address/FQDN** with the friendly name for credentials in the text box. Verify** the added records and click on **Save**.

-1. On clicking Save, appliance will try validating the connection to the servers added and show the **Validation status** in the table against each server.

-1. Click on **Start discovery**, to kick off discovery of the successfully validated servers. After the discovery has been successfully initiated, you can check the discovery status against each server in the table.

-It takes approximately 2 minutes to complete discovery of 100 servers and their metadata to appear in the Azure portal.

- - [Single Server](single-server-overview.md) is a fully managed database service designed for minimal customization. The single server platform is designed to handle most of the database management functions such as patching, backups, high availability, security with minimal user configuration and control. The architecture is optimized for built-in high availability with 99.99% availability on single availability zone. It supports community version of MySQL 5.6 (retired), 5.7 and 8.0. The service is generally available today in wide variety of [Azure regions](https://azure.microsoft.com/global-infrastructure/services/). Single servers are best suited **only for existing applications already leveraging single server**. For all new developments or migrations, Flexible Server would be the recommended deployment option. To learn about the differences between Flexible Server and Single Server deployment options, refer [select the right deployment option for you](select-right-deployment-type.md) documentation.

-# Azure Red Hat OpenShift support policy

-* The cluster must have a minimum of three worker nodes and three manager nodes. Do not have taints that prevent OpenShift components to be scheduled. Do not scale the cluster workers to zero, or attempt a graceful cluster shutdown.

-* Don't remove or modify network security groups.

-* Don't place policies within your subscription or management group that prevent SREs from performing normal maintenance against the ARO cluster, such as requiring tags on the ARO RP-managed cluster resource group.

-### Master nodes

-The following instance types are supported as a day 2 operation by configuring machinesets. For information on how to create a machineset, see [Creating a machineset in Azure](https://docs.openshift.com/container-platform/4.8/machine_management/creating_machinesets/creating-machineset-azure.html).

-1. Navigate to your Azure Purview resource in the Azure portal.

-| 5 | [Azure Purview connector overview](purview-connector-overview.md) <br> [Azure Purview private endpoint networking](catalog-private-link.md) |

-Use [this guide](azure-purview-connector-overview.md) to read more about each connector and their supported authentication options.

-* An active [Azure Purview resource](create-catalog-portal.md).

-In order to create and manage collections in Azure Purview, you will need to be a **Collection Admin** within Azure Purview. We can check these permissions in the [Azure Purview Studio](https://web.purview.azure.com/resource/). You can find Studio in the overview page of the Azure Purview resource in [Azure portal](https://portal.azure.com).

-1. Select your root collection. This is the top collection in your collection list and will have the same name as your Azure Purview resource. In the following example, it's called Contoso Azure Purview. Alternatively, if collections already exist you can select any collection where you want to create a subcollection.

-1. To create a collection, you'll need to be in the collection admin list under role assignments. If you created the Azure Purview resource, you should be listed as a collection admin under the root collection already. If not, you'll need to contact the collection admin to grant your permission.

-Collection permissions are inherited automatically from the parent collection. For example, any permissions on the root collection (the collection at the top of the list that has the same name as your Azure Purview resource), will be inherited by all collections below it. You can restrict inheritance from a parent collection at any time, using the restrict inherited permissions option.

-1. Start by ingesting your Azure Purview logs into Microsoft Sentinel through a data connector.

-* An active [Azure Purview resource](create-catalog-portal.md).

-In order to create and manage collections in Azure Purview, you will need to be a **Collection Admin** within Azure Purview. We can check these permissions in the [Azure Purview Studio](use-azure-purview-studio.md). You can find the studio by going to your Azure Purview resource in the [Azure portal](https://portal.azure.com), and selecting the **Open Azure Purview Studio** tile on the overview page.

-1. Select your root collection. This is the top collection in your collection list and will have the same name as your Azure Purview resource. In our example below, it's called Contoso Azure Purview.

-1. To create a collection, you will need to be in the collection admin list under role assignments. If you created the Azure Purview resource, you should be listed as a collection admin under the root collection already. If not, you'll need to contact the collection admin to grant you permission.

-To create your collection, we'll start in the [Azure Purview Studio](use-azure-purview-studio.md). You can find the studio by going to your Azure Purview resource in the Azure portal and selecting the **Open Azure Purview Studio** tile on the overview page.

-A single Azure Purview resource.

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

- Paste your bucket name in a secure file, and add an `s3://` prefix to it to create the value you'll need to enter when configuring your bucket as an Azure Purview resource.

-## Add a single Amazon S3 bucket as an Azure Purview resource

-## Add an AWS account as an Azure Purview resource

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* You must have an active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* You must have an active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* An active [Azure Purview resource](create-catalog-portal.md).

-* [Demo of data owner access policies for Azure Storage](https://www.youtube.com/watch?v=CFE8ltT19Ss)

-* [Demo of access policy for Azure Storage](https://www.youtube.com/watch?v=CFE8ltT19Ss)

-To interact with Azure Purview, you'll connect to the [Azure Purview Studio](https://web.purview.azure.com/resource/) through the Azure portal. You can find the studio by going to your Azure Purview resource in the [Azure portal](https://portal.azure.com), and selecting the **Open Azure Purview Studio** tile on the overview page.

-1. Select your root collection. The root collection is the top collection in your collection list and will have the same name as your Azure Purview resource. In our example below, it is called Azure Purview Account.

-1. To create a collection, you'll need to be in the collection admin list under role assignments. If you created the Azure Purview resource, you should be listed as a collection admin under the root collection already. If not, you'll need to contact the collection admin to grant you permission.

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | Syslog |

-| **Log Analytics table(s)** | CommonSecurityLog |

-| **Log Analytics table(s)** | CommonSecurityLog |

- 

- 

- - **Target storage accounts (source VM doesn't use managed disks)**: By default, Site Recovery creates a new target storage account mimicking your source VM storage configuration. In case storage account already exists, it's reused.

- 

- 

- 

- - In **Availability set**, you can add availability set settings to the VM, if they're part of an availability set in the source region.

- - In **Target Storage accounts**, select the account you want to use.

- 

-

-5. Click **Create target resource** > **Enable Replication**.

-6. After the VMs are enabled for replication, you can check the status of VM health under **Replicated items**

-## Push your static website to GitHub

-Azure Static Web Apps deploys your app from a GitHub repository and keeps doing so for every pushed commit to a designated branch. Use the following commands sync your changes to GitHub.

-1. Stage all changed files:

- ```bash

- git add .

- ```

-1. Commit all changes

- ```bash

- git commit -m "Update build config"

- ```

-1. Push your changes to GitHub.

- ```bash

- git push origin main

- ```

-1. In the _Output location_ box, enter **out**.