-|[Microsoft Entra ID (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md) | NA | GA | |

-| `UserInterfaceControlType` | Yes | The type of the display control. Currently supported is [VerificationControl](display-control-verification.md), and [TOTP controls](display-control-time-based-one-time-password.md). |

-description: Specify the IDs for a content definition with an ID of api.signuporsignin in a custom policy in Azure Active Directory B2C.

-#Customer intent: As a developer implementing user interface localization in Azure Active Directory B2C, I want to access the list of localization string IDs, so that I can use them in my policy to support multiple locales or languages in the user journeys.

-| `unknown_error` | We are having trouble signing you in. Please try again later. | `All` |

-| `invalid_password` | The password you entered is not in the expected format. | `< 2.0.0` |

-| `ver_fail_server` | We are having trouble verifying your email address. Please enter a valid email address and try again. |

-The following `UxElement` string IDs will display disclaimer link(s) at the bottom of the self-asserted page. These links are not displayed by default unless specified in the localized strings.

-The following example shows the use of some of the user interface elements in the sign-up page, after user clicks on send verification code button:

-The following IDs are used for a [one-time password technical profile](one-time-password-technical-profile.md) error messages

-| `UserMessageIfSessionDoesNotExist` | No | The message to display to the user if the code verification session has expired. It is either the code has expired or the code has never been generated for a given identifier. |

-| `UserMessageIfMaxRetryAttempted` | No | The message to display to the user if they've exceeded the maximum allowed verification attempts. |

-| `UserMessageIfInvalidCode` | No | The message to display to the user if they've provided an invalid code. |

-| `UserMessageIfVerificationFailedRetryAllowed` | No | The message to display to the user if they've provided an invalid code, and user is allowed to provide the correct code. |

-| `UserMessageIfSessionConflict` | No | The message to display to the user if the code cannot be verified.|

-This example shows localized messages for local account signup.

-description: Configure Azure Active Directory B2C with Asignio for multifactor authentication

-zone_pivot_groups: b2c-policy-type

-# Customer intent: I'm a developer integrating Asignio with Azure AD B2C for multifactor authentication. I want to configure an application with Asignio and set it up as an identity provider (IdP) in Azure AD B2C, so I can provide a passwordless, soft biometric, and multifactor authentication experience to customers.

-# Configure Asignio with Azure Active Directory B2C for multifactor authentication

-Learn to integrate Microsoft Entra ID (Azure AD B2C) authentication with [Asignio](https://www.web.asignio.com/). With this integration, provide passwordless, soft biometric, and multifactor authentication experience to customers. Asignio uses patented Asignio Signature and live facial verification for user authentication. The changeable biometric signature helps to reduce passwords, fraud, phishing, and credential reuse through omni-channel authentication.

-## Before you begin

-Choose a policy type selector to indicate the policy type setup. Azure AD B2C has two methods to define how users interact with your applications:

-* Predefined user flows

-* Configurable custom policies

-The steps in this article differ for each method.

-Learn more:

-* [User flows and custom policies overview](user-flow-overview.md)

-* [Azure AD B2C custom policy overview](custom-policy-overview.md)

-## Prerequisites

-* An Azure subscription.

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

-### For custom policies

-Complete [Tutorial: Create user flows and custom policies in Azure AD B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy)

-## Scenario description

-This integration includes the following components:

-* **Azure AD B2C** - authorization server that verifies user credentials

-* **Web or mobile applications** - to secure with Asignio MFA

-* **Asignio web application** - signature biometric collection on the user touch device

-The following diagram illustrates the implementation.

- 

-1. User opens Azure AD B2C sign in page on their mobile or web application, and then signs in or signs up.

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

-3. The user is redirected to the Asignio web application for biometric sign in. If the user hasn't registered their Asignio Signature, they can use an SMS One-Time-Password (OTP) to authenticate. After authentication, user receives a registration link to create their Asignio Signature.

-4. The user authenticates with Asignio Signature and facial verification, or voice and facial verification.

-5. The challenge response goes to Asignio.

-6. Asignio returns the OIDC response to Azure AD B2C sign in.

-7. Azure AD B2C sends an authentication verification request to Asignio to confirm receipt of the authentication data.

-8. The user is granted or denied access to the application.

-## Configure an application with Asignio

-Configurating an application with Asignio is with the Asignio Partner Administration site.

-1. Go to asignio.com [Asignio Partner Administration](https://partner.asignio.com) page to request access for your organization.

-2. With credentials, sign into Asignio Partner Administration.

-3. Create a record for the Azure AD B2C application using your Azure AD B2C tenant. When you use Azure AD B2C with Asignio, Azure AD B2C manages connected applications. Asignio apps represent apps in the Azure portal.

-4. In the Asignio Partner Administration site, generate a Client ID and Client Secret.

-5. Note and store Client ID and Client Secret. You'll use them later. Asignio doesn't store Client Secrets.

-6. Enter the redirect URI in your site the user is returned to after authentication. Use the following URI pattern.

-`[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp]`.

-7. Upload a company logo. It appears on Asignio authentication when users sign in.

-## Register a web application in Azure AD B2C

-Register applications in a tenant you manage, then they can interact with Azure AD B2C.

-Learn more: [Application types that can be used in Active Directory B2C](application-types.md)

-For this tutorial, you're registering `https://jwt.ms`, a Microsoft web application with decoded token contents that don't leave your browser.

-### Register a web application and enable ID token implicit grant

-Complete [Tutorial: Register a web application in Azure Active Directory B2C](tutorial-register-applications.md?tabs=app-reg-ga)

-## Configure Asignio as an identity provider in Azure AD B2C

-For the following instructions, use the Microsoft Entra tenant with the Azure subscription.

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

-2. In the Azure portal toolbar, select **Directories + subscriptions**.

-3. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Microsoft Entra directory.

-4. Select **Switch**.

-5. In the top-left corner of the Azure portal, select **All services**.

-6. Search for and select **Azure AD B2C**.

-7. In the Azure portal, search for and select **Azure AD B2C**.

-8. In the left menu, select **Identity providers**.

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

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

-11. For **Name**, enter the Asignio sign in, or a name you choose.

-12. For **Metadata URL**, enter `https://authorization.asignio.com/.well-known/openid-configuration`.

-13. For **Client ID**, enter the Client ID you generated.

-14. For **Client Secret**, enter the Client Secret you generated.

-15. For **Scope**, use **openid email profile**.

-16. For **Response type**, use **code**.

-17. For **Response mode**, use **query**.

-18. For Domain hint, use `https://asignio.com`.

-19. Select **OK**.

-20. Select **Map this identity provider's claims**.

-21. For **User ID**, use **sub**.

-22. For **Display Name**, use **name**.

-23. For **Given Name**, use **given_name**.

-24. For **Surname**, use **family_name**.

-25. For **Emai**l, use **email**.

-26. Select **Save**.

-## SCreate a user flow policy

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

-2. Select **New user flow**.

-3. Select **Sign up and sign in** user flow type.

-4. Select **Version Recommended**.

-5. Select **Create**.

-6. Enter a user flow **Name**, such as `AsignioSignupSignin`.

-7. Under **Identity providers**, for **Local Accounts**, select **None**. This action disables email and password authentication.

-8. For **Custom identity providers**, select the created Asignio Identity provider.

-9. Select **Create**.

-## Test your user flow

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

-2. Select the created user flow.

-3. For **Application**, select the web application you registered. The **Reply URL** is `https://jwt.ms`.

-4. Select **Run user flow**.

-5. The browser is redirected to the Asignio sign in page.

-6. A sign in screen appears.

-7. At the bottom, select **Asignio** authentication.

-If you have an Asignio Signature, complete the prompt to authenticate. If not, supply the device phone number to authenticate via SMS OTP. Use the link to register your Asignio Signature.

-8. The browser is redirected to `https://jwt.ms`. The token contents returned by Azure AD B2C appear.

-## Create Asignio policy key

-1. Store the generated Client Secret in the Azure AD B2C tenant.

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

-3. In the portal toolbar, select the **Directories + subscriptions**.

-4. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Azure AD B2C directory.

-5. Select **Switch**.

-6. In the top-left corner of the Azure portal, select **All services**.

-7. Search for and select **Azure AD B2C**.

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

-9. Select **Policy Keys**.

-10. Select **Add**.

-11. For **Options**, select **Manual**.

-12. Enter a policy key **Name** for the policy key. The prefix `B2C_1A_` is appended to the key name.

-13. In **Secret**, enter the Client Secret that you noted.

-14. For **Key usage**, select **Signature**.

-15. Select **Create**.

-## Configure Asignio as an Identity provider

->[!TIP]

->Before you begin, ensure the Azure AD B2C policy is configured. If not, follow the instructions in [Custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack).

-For users to sign in with Asignio, define Asignio as a claims provider that Azure AD B2C communicates with through an endpoint. The endpoint provides claims Azure AD B2C uses to verify user authentication with using digital ID on the device.

-### Add Asignio as a claims provider

-Get the custom policy starter packs from GitHub, then update the XML files in the LocalAccounts starter pack with your Azure AD B2C tenant name:

-1. Download the zip [active-directory-b2c-custom-policy-starterpack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/archive/master.zip) or clone the repository:

- ```

- git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

- ```

-

-2. In the files in the **LocalAccounts** directory, replace the string `yourtenant` with the Azure AD B2C tenant name.

-3. Open the **LocalAccounts/ TrustFrameworkExtensions.xml**.

-4. Find the **ClaimsProviders** element. If there isn't one, add it under the root element, `TrustFrameworkPolicy`.

-5. Add a new **ClaimsProvider** similar to the following example:

- ```xml

- <ClaimsProvider>

- <Domain>contoso.com</Domain>

- <DisplayName>Asignio</DisplayName>

- <TechnicalProfiles>

- <TechnicalProfile Id="Asignio-Oauth2">

- <DisplayName>Asignio</DisplayName>

- <Description>Login with your Asignio account</Description>

- <Protocol Name="OAuth2" />

- <Metadata>

- <Item Key="ProviderName">authorization.asignio.com</Item>

- <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>

- <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>

- <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>

- <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>

- <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>

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

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

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

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

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

- <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>

- <!-- trying to add additional claim-->

- <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->

- <Item Key="11111111-1111-1111-1111-111111111111"></Item>

- <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->

- <Item Key="22222222-2222-2222-2222-222222222222"></Item>

- <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->

- <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->

- <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to sign in. -->

- <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>

- </Metadata>

- <CryptographicKeys>

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

- </CryptographicKeys>

- <OutputClaims>

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

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

- <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />

- <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />

- <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />

- <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />

- <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />

- <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />

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

- </OutputClaims>

- <OutputClaimsTransformations>

- <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />

- <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />

- <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />

- <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />

- </OutputClaimsTransformations>

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

- </TechnicalProfile>

- </TechnicalProfiles>

- </ClaimsProvider>

- ```

-6. Set **client_id** with the Asignio Application ID you noted.

-7. Update **client_secret** section with the policy key you created. For example, `B2C_1A_AsignioSecret`:

- ```xml

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

- ```

-8. Save the changes.

-## Add a user journey

-The identity provider isn't in the sign in pages.

-1. If you have a custom user journey continue to **Configure the relying party policy**, otherwise, copy a template user journey:

-2. From the starter pack, open the **LocalAccounts/ TrustFrameworkBase.xml**.

-3. Locate and copy the contents of the **UserJourney** element that include `Id=SignUpOrSignIn`.

-4. Open the **LocalAccounts/ TrustFrameworkExtensions.xml**.

-5. Locate the **UserJourneys** element. If there isn't one, add one.

-6. Paste the UserJourney element contents as a child of the UserJourneys element.]

-7. Rename the user journey **ID**. For example, `Id=AsignioSUSI`.

-Learn more: [User journeys](custom-policy-overview.md#user-journeys)

-## Add the identity provider to 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 has an identity provider list that users sign in with. The order of the elements controls the order of the sign in buttons.

-2. Add a **ClaimsProviderSelection** XML element.

-3. Set the value of **TargetClaimsExchangeId** to a friendly name.

-4. Add a **ClaimsExchange** element.

-5. Set the **Id** to the value of the target claims exchange ID.

-6. Update the value of **TechnicalProfileReferenceId** to the ID of the technical profile you created.

-The following XML demonstrates user journey orchestration with the identity provider.

-```xml

- <UserJourney Id="AsignioSUSI">

- <OrchestrationSteps>

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

- <ClaimsProviderSelections>

- <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />

- <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />

- </ClaimsProviderSelections>

- <ClaimsExchanges>

- <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- Check if the user has selected to sign in using one of the social providers -->

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

- <Preconditions>

- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

- <Value>objectId</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />

- <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />

- </ClaimsExchanges>

- </OrchestrationStep>

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

- <Preconditions>

- <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

- <Value>authenticationSource</Value>

- <Value>localAccountAuthentication</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->

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

- <Preconditions>

- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

- <Value>objectId</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent in the token. -->

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

- <Preconditions>

- <Precondition Type="ClaimEquals" ExecuteActionsIf="true">

- <Value>authenticationSource</Value>

- <Value>socialIdpAuthentication</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->

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

- <Preconditions>

- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">

- <Value>objectId</Value>

- <Action>SkipThisOrchestrationStep</Action>

- </Precondition>

- </Preconditions>

- <ClaimsExchanges>

- <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />

- </ClaimsExchanges>

- </OrchestrationStep>

- <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

- </OrchestrationSteps>

- <ClientDefinition ReferenceId="DefaultWeb" />

- </UserJourney>

-```

-## 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/main/LocalAccounts/SignUpOrSignin.xml), specifies the user journey Azure AD B2C executes.

-1. In the relying party, locate the **DefaultUserJourney** element.

-2. Update the **ReferenceId** to match the user journey ID, in which you added the identity provider.

-In the following example, for the `AsignioSUSI` user journey, the **ReferenceId** is set to `AsignioSUSI`:

-```xml

- <RelyingParty>

- <DefaultUserJourney ReferenceId="AsignioSUSI" />

- <TechnicalProfile Id="PolicyProfile">

- <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}" />

- <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />

- </OutputClaims>

- <SubjectNamingInfo ClaimType="sub" />

- </TechnicalProfile>

- </RelyingParty>

-```

-## Upload the custom policy

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

-2. In the portal toolbar, select the **Directories + subscriptions**.

-3. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Azure AD B2C directory.

-4. Select **Switch**.

-5. In the Azure portal, search for and select **Azure AD B2C**.

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

-7. Select **Upload Custom Policy**.

-8. Upload the two policy files you changed in the following order:

- * Extension policy, for example `TrustFrameworkExtensions.xml`

- * Relying party policy, such as `SignUpOrSignin.xml`

-## Test your custom policy

-1. In your Azure AD B2C tenant, and under **Policies**, select **Identity Experience Framework**.

-2. Under **Custom policies**, select **AsignioSUSI**.

-3. For **Application**, select the web application that you registered. The **Reply URL** is `https://jwt.ms`.

-4. Select **Run now**.

-5. The browser is redirected to the Asignio sign in page.

-6. A sign in screen appears.

-7. At the bottom, select **Asignio** authentication.

-If you have an Asignio Signature, you're prompted to authenticate with your Asignio Signature. If not, supply the device phone number to authenticate via SMS OTP. Use the link to register your Asignio Signature.

-8. The browser is redirected to `https://jwt.ms`. The token contents returned by Azure AD B2C appear.

-## Next steps

-* [Solutions and Training for Azure Active Directory B2C](solution-articles.md)

-* Ask questions on [Stackoverflow](https://stackoverflow.com/questions/tagged/azure-ad-b2c)

-* [Azure AD B2C Samples](https://stackoverflow.com/questions/tagged/azure-ad-b2c)

-* YouTube: [Identity Azure AD B2C Series](https://www.youtube.com/playlist?list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0)

-* [Azure AD B2C custom policy overview](custom-policy-overview.md)

-* [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

-#Customer intent: As a developer using Azure Active Directory B2C, I want to define a self-asserted technical profile with display claims and output claims, so that I can collect and validate user input and return the claims to the next orchestration step.

-* The fifth display claim makes a reference to the `phoneVerificationControl` display control, which collects and verifies a phone number.

-| setting.retryLimit | No | Controls the number of times a user can try to provide the data that is checked against a validation technical profile. For example, a user tries to sign-up with an account that already exists and keeps trying until the limit reached. Check out the [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/technical-profiles/self-asserted#retry-limit) of this metadata.|

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-| `additional_instructions` | string or null | Optional | Appends additional instructions at the end of the instructions for the run. This is useful for modifying the behavior on a per-run basis without overriding other instructions. |

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-POST https://YOUR_RESOURCE_NAME.openai.azure.com/openai/threads{thread_id}?api-version=2024-02-15-preview

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-DELETE https://YOUR_RESOURCE_NAME.openai.azure.com/openai/threads{thread_id}?api-version=2024-02-15-preview

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

-The third generation embeddings models support reducing the size of the embedding via a new `dimensions` parameter. Typically larger embeddings are more expensive from a compute, memory, and storage perspective. Being able to adjust the number of dimensions allows more control over overall cost and performance. Official support for the dimensions parameter was added to the OpenAI Python library in version `1.10.0`. If you are running an earlier version of the 1.x library you will need to upgrade `pip install openai --upgrade`.

-| gpt-4 (vision-preview) | Sweden Central <br> West US <br> Japan East| Switzerland North <br> Australia East |

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- -H "api-key: $AZURE_OPENAI_KEY" \

- api_key = os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

-A fine-tuned model improves on the few-shot learning approach by training the model's weights on your own data. A customized model lets you achieve better results on a wider number of tasks without needing to provide examples in your prompt. The result is less text sent and fewer tokens processed on every API call, potentially saving cost and improving request latency.

-

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = os.getenv("AZURE_OPENAI_KEY"),

- api_key = os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

- api_key=os.getenv("AZURE_OPENAI_KEY"),

- api_key = $Env:AZURE_OPENAI_KEY

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-| Max file size for Assistants | 512 MB |

-<table>

- <tr>

- <th>Model</th>

- <th>Regions</th>

- <th>Tokens per minute</th>

- </tr>

- <tr>

- <td rowspan="2">gpt-35-turbo</td>

- <td>East US, South Central US, West Europe, France Central, UK South</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, Sweden Central, Switzerland North</td>

- <td>300 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-35-turbo-16k</td>

- <td>East US, South Central US, West Europe, France Central, UK South</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, Sweden Central, Switzerland North</td>

- <td>300 K</td>

- </tr>

- <tr>

- <td>gpt-35-turbo-instruct</td>

- <td>East US, Sweden Central</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>gpt-35-turbo (1106)</td>

- <td> Australia East, Canada East, France Central, South India, Sweden Central, UK South, West US

-</td>

- <td>120 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-4</td>

- <td>East US, South Central US, France Central</td>

- <td>20 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, UK South, Sweden Central, Switzerland North</td>

- <td>40 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-4-32k</td>

- <td>East US, South Central US, France Central</td>

- <td>60 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, UK South, Sweden Central, Switzerland North</td>

- <td>80 K</td>

- </tr>

- <tr>

- <td rowspan="2">gpt-4 (1106-preview)<br>GPT-4 Turbo </td>

- <td>Australia East, Canada East, East US 2, France Central, UK South, West US</td>

- <td>80 K</td>

- </tr>

- <tr>

- <td>South India, Norway East, Sweden Central</td>

- <td>150 K</td>

- </tr>

-<tr>

- <td>gpt-4 (vision-preview)<br>GPT-4 Turbo with Vision</td>

- <td>Sweden Central, Switzerland North, Australia East, West US</td>

- <td>30 K</td>

- </tr>

- <tr>

- <td rowspan="2">text-embedding-ada-002</td>

- <td>East US, South Central US, West Europe, France Central</td>

- <td>240 K</td>

- </tr>

- <tr>

- <td>North Central US, Australia East, East US 2, Canada East, Japan East, UK South, Switzerland North</td>

- <td>350 K</td>

- </tr>

-<tr>

- <td>Fine-tuning models (babbage-002, davinci-002, gpt-35-turbo-0613)</td>

- <td>North Central US, Sweden Central</td>

- <td>50 K</td>

- </tr>

- <tr>

- <td>all other models</td>

- <td>East US, South Central US, West Europe, France Central</td>

- <td>120 K</td>

- </tr>

-</table>

-| `AZURE_OPENAI_KEY` | This value can be found in the **Keys & Endpoint** section when examining your resource from the Azure portal. You can use either `KEY1` or `KEY2`.|

-setx AZURE_OPENAI_KEY "REPLACE_WITH_YOUR_KEY_VALUE_HERE"

-[System.Environment]::SetEnvironmentVariable('AZURE_OPENAI_KEY', 'REPLACE_WITH_YOUR_KEY_VALUE_HERE', 'User')

-echo export AZURE_OPENAI_KEY="REPLACE_WITH_YOUR_KEY_VALUE_HERE" >> /etc/environment && source /etc/environment

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-print("Status:", response.id)

-openai.api_key = os.getenv("AZURE_OPENAI_KEY")

- api_key=os.getenv("AZURE_OPENAI_KEY"),

-| `AZURE_OPENAI_KEY` | This value can be found in the **Keys & Endpoint** section when examining your resource from the Azure portal. You can use either `KEY1` or `KEY2`.|

-setx AZURE_OPENAI_KEY "REPLACE_WITH_YOUR_KEY_VALUE_HERE"

-[System.Environment]::SetEnvironmentVariable('AZURE_OPENAI_KEY', 'REPLACE_WITH_YOUR_KEY_VALUE_HERE', 'User')

-echo export AZURE_OPENAI_KEY="REPLACE_WITH_YOUR_KEY_VALUE_HERE" >> /etc/environment && source /etc/environment

-Connections can be set up as shared with all projects in the same Azure AI hub resource, or created exclusively for one project. To manage project connections via Azure AI Studio, navigate to a project page, then navigate to **Settings** > **Connections**. To manage shared connections, navigate to the **Manage** page. As an administrator, you can audit both shared and project-scoped connections on an Azure AI hub resource level to have a single pane of glass of connectivity across projects.

-1. In [Azure AI Studio](https://ai.azure.com), go to **Build** > **Settings** to view your Azure AI project resources such as connections and API keys. There's a link to your Azure AI hub resource in Azure AI Studio and links to view the corresponding project resources in the [Azure portal](https://portal.azure.com).

-description: This article introduces connections in Azure AI Studio

-Connections in Azure AI Studio are a way to authenticate and consume both Microsoft and third-party resources within your Azure AI projects. For example, connections can be used for prompt flow, training data, and deployments. [Connections can be created](../how-to/connections-add.md) exclusively for one project or shared with all projects in the same Azure AI hub resource.

-## Connections to third-party services

-Azure AI Studio supports connections to third-party services, including the following:

-A Uniform Resource Identifier (URI) represents a storage location on your local computer, Azure storage, or a publicly available http(s) location. These examples show URIs for different storage options:

-|Storage location | URI examples |

-|||

-|Azure AI Studio connection | `azureml://datastores/<data_store_name>/paths/<folder1>/<folder2>/<folder3>/<file>.parquet` |

-|Local files | `./home/username/data/my_data` |

-|Public http(s) server | `https://raw.githubusercontent.com/pandas-dev/pandas/main/doc/data/titanic.csv` |

-|Blob storage | `wasbs://<containername>@<accountname>.blob.core.windows.net/<folder>/`|

-|Azure Data Lake (gen2) | `abfss://<file_system>@<account_name>.dfs.core.windows.net/<folder>/<file>.csv` |

-|Microsoft OneLake | `abfss://<file_system>@<account_name>.dfs.core.windows.net/<folder>/<file>.csv` `https://<accountname>.dfs.fabric.microsoft.com/<artifactname>` |

-Azure connections serve as key vault proxies, and interactions with connections are direct interactions with an Azure key vault. Azure AI Studio connections store API keys securely, as secrets, in a key vault. The key vault [Azure role-based access control (Azure RBAC)](./rbac-ai-studio.md) controls access to these connection resources. A connection references the credentials from the key vault storage location for further use. You won't need to directly deal with the credentials after they are stored in the Azure AI hub resource's key vault. You have the option to store the credentials in the YAML file. A CLI command or SDK can override them. We recommend that you avoid credential storage in a YAML file, because a security breach could lead to a credential leak.

-For any model deployment in Azure AI Studio, you could directly use the default content filter, but when you want to have more customized setting on content filter, for example set a stricter or looser filter, or enable more advanced capabilities, like jailbreak risk detection and protected material detection. To create a content filter, you could go to **Build**, choose one of your projects, then select **Content filters** in the left navigation bar, and create a content filter.

-### More filters for Gen-AI scenarios

-You could also enable filters for Gen-AI scenarios: jailbreak risk detection and protected material detection.

-1. Select **Settings** from the collapsible left menu.

-1. Select your project and then select **Settings** from the left navigation menu.

-1. On the collapsible left menu, select **Settings**.

-In the project details page (select **Build** > **Settings**), you can find information about the project, such as the project name, description, and the Azure AI hub resource that hosts the project. You can also find the project ID, which is used to identify the project in the Azure AI Studio API.

-If you're using SDK or CLI to create data, you must specify a `path` that points to the data location. Supported paths include:

-The Azure AI Studio's evaluation page is a versatile hub that not only allows you to visualize and assess your results but also serves as a control center for optimizing, troubleshooting, and selecting the ideal AI model for your deployment needs. It's a one-stop solution for data-driven decision-making and performance enhancement in your AI projects. You can seamlessly access and interpret the results from various sources, including your flow, the playground quick test session, evaluation submission UI, generative SDK and CLI. This flexibility ensures that you can interact with your results in a way that best suits your workflow and preferences.

-Upon submitting your evaluation, you can locate the submitted evaluation run within the run list by navigating to the 'Evaluation' tab.

-You can oversee your evaluation runs within the run list. With the flexibility to modify the columns using the column editor and implement filters, you can customize and create your own version of the run list. Additionally, you have the ability to swiftly review the aggregated evaluation metrics across the runs, enabling you to perform quick comparisons.

-1. Select **Settings** > **Resource providers** from the left menu.

-1. Select **Settings** from the collapsible left menu.

-1. Select **Settings** from the collapsible left menu.

-By default, operational metrics such as requests per minute and request latency show up. The default safety and quality monitoring signal are configured with a 10% sample rate and run on your default workspace Azure Open AI connection.

-1. Go to **Settings** > **Connections**.

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Go to **Settings** > **Connections**.

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-1. Create or open a flow in Azure AI Studio. For more information, see [Create a flow](../flow-develop.md).

-Prompt flow is available independently as an open-source project on [GitHub](https://github.com/microsoft/promptflow), with its own SDK and [VS Code extension](https://marketplace.visualstudio.com/items?itemName=prompt-flow.prompt-flow). Prompt flow is also available and recommended to use as a feature within both [Azure AI Studio](https://aka.ms/AzureAIStudio) and [Azure Machine Learning studio](https://aka.ms/AzureAIStudio). This set of documentation focuses on prompt flow in Azure AI Studio.

-`max_tokens` and `temperature` are optional, the default value for `max_tokens` is 300, the default value for `temperature` is 0.9

-1. Go to your project and select **Settings** from the left menu.

-2. Select your Azure AI hub resource name under **Resource configurations** on the **Settings** page.

-1. Select **Generate product name ideas** from the **Examples** dropdown menu. The system prompt is prepopulated with something resembling the following text:

-1. Select `Generate`. Azure OpenAI generates product name ideas based on. You should get a result that resembles the following list:

-You can still use the Azure AI Studio (that's still open in another browser tab) while working in VS Code Web. You can see the compute is running via **Build** > **Settings** > **Compute instances**. You can pause or stop the compute from here.

-Within **Explore**, you can [explore many capabilities](../how-to/models-foundation-azure-ai.md) found within the secondary navigation. These include [model catalog](../how-to/model-catalog.md), model leaderboard, and pages for Azure AI services such as Speech, Vision, and Content Safety.

-1. Press the **Tab** key until you hear *New project* and select this button.

-The chat session pane is where you can chat to the model and test out your assistant

- ```

- [message from user] [user image]

- [chatbot image] [message from chatbot]

- ```

-Prompt flow is a tool to create executable flows, linking LLMs, prompts and Python tools through a visualized graph. You can use this to prototype, experiment and iterate on your AI applications before deploying.

-With the Build tab selected, navigate to the secondary navigation landmark and press the down arrow until you hear *flows*.

-The prompt flow UI in Azure AI Studio is composed of the following main sections: Command toolbar, Flow (includes list of the flow nodes), Files and the Graph view. The Flow, Files and Graph sections each have their own H2 headings that can be used for navigation.

-Evaluation is a tool to help you evaluate the performance of your generative AI application. You can use this to prototype, experiment and iterate on your applications before deploying.

-1. Navigate to the secondary navigation landmark and press the down arrow until you hear *evaluations*.

-You might prefer to export the data from your evaluation run so that you can view it in an application of your choosing. To do this, select your evaluation run link, then navigate to the **Export results** button and select it.

-There's also a dashboard view provided to allow you to compare evaluation runs. From the main Evaluations list page, navigate to the **Switch to dashboard view** button. You can also export all this data using the **Export table** button.

-This step is also a good time to review the [inbound and outbound network](networking.md#ports-and-network-restrictions) dependency changes in moving to App Service Environment v3. These changes include the port change for Azure Load Balancer, which now uses port 80. Don't move to the next step until you confirm that you made these updates.

-> In rare cases, you might see a notification in the portal that says "Migration to App Service Environment v3 failed" after you start the migration. There's a known bug that might trigger this notification even if the migration is progressing. Check the activity log for the App Service Environment to determine the validity of this error message.

-> :::image type="content" source="./media/migration/migration-error.png" alt-text="Screenshot that shows the potential error notification after migration starts.":::

-This step is your opportunity to test and validate your new App Service Environment v3. Once you confirm your apps are working as expected, you can redirect customer traffic to your new environment by running the following command. This command also deletes your old environment.

-|Your InteralLoadBalancingMode is not currently supported.|App Service Environments that have InternalLoadBalancingMode set to certain values can't be migrated using the migration feature at this time. |Migrate using one of the [manual migration options](migration-alternatives.md) if you want to migrate immediately. |

-|Your InternalLoadBalancingMode is not currently supported.|App Service Environments that have InternalLoadBalancingMode set to certain values can't be migrated using the side by side migration feature at this time. |Migrate using one of the [manual migration options](migration-alternatives.md) if you want to migrate immediately. |

-The final step is to redirect traffic to your new App Service Environment v3 and complete the migration. The platform does this change for you, but only when you initiate it. Before you do this step, you should review your new App Service Environment v3 and perform any needed testing to validate that it's functioning as intended. You can do this review using the IPs associated with your App Service Environment v3 from the IP generation steps. Once you're ready to redirect traffic, you can complete the final step of the migration. This step updates internal DNS records to point to the load balancer IP address of your new App Service Environment v3. Changes are effective immediately. This step also shuts down your old App Service Environment and deletes it. Your new App Service Environment v3 is now your production environment.

-Azure [Confidential VM](../confidential-computing/confidential-vm-overview.md) (CVM) is based on [AMD processors with SEV-SNP technology](../confidential-computing/virtual-machine-solutions.md). CVM offers VM OS disk encryption option with platform-managed keys or customer-managed keys and binds the disk encryption keys to the virtual machine's TPM. When a CVM boots up, SNP report containing the guest VM firmware measurements is sent to Azure Attestation. The service validates the measurements and issues an attestation token that is used to release keys from [Managed-HSM](../key-vault/managed-hsm/overview.md) or [Azure Key Vault](../key-vault/general/basic-concepts.md). These keys are used to decrypt the vTPM state of the guest VM, unlock the OS disk and start the CVM. The attestation and key release process is performed automatically on each CVM boot, and the process ensures the CVM boots up only upon successful attestation of the hardware.

-[Create an Azure Arc VM](create-virtual-machine.md)

-This Quickstart shows you how to connect your SCVMM management server to Azure Arc using a helper script. The script deploys a lightweight Azure Arc appliance (called Azure Arc resource bridge) as a virtual machine running in your VMM environment and installs an SCVMM cluster extension on it, to provide a continuous connection between your VMM management server and Azure Arc.

-1. Open the terminal and navigate to the folder, where you've downloaded the Bash script.

-| **Private cloud selection** | Select the name of the private cloud where the Arc resource bridge VM should be deployed. |

-8. Under **Region**, select an Azure location where the resource metadata will be stored. Currently, supported regions are **East US**, **West Europe**, **Australia East** and **Canada Central**.

-| **Static IP / DHCP** | For deploying Azure Arc resource bridge, the preferred configuration is to use Static IP. Enter **n** to select static IP configuration. While not recommended, if you have DHCP server in your network and want to use it instead, enter **y**. If you're using a DHCP server, reserve the IP address assigned to the Azure Arc Resource Bridge VM (Appliance VM IP). If you use DHCP, the cluster configuration IP address still needs to be a static IP address. </br>When you choose a static IP configuration, you're asked for the following information: </br> 1. **Static IP address prefix**: Network address in CIDR notation. For example: **192.168.0.0/24**. </br> 2. **Static gateway**: Gateway address. For example: **192.168.0.0**. </br> 3. **DNS servers**: IP address(es) of DNS server(s) used by Azure Arc resource bridge VM for DNS resolution. Azure Arc resource bridge VM must be able to resolve external sites, like mcr.microsoft.com and the vCenter server. </br> 4. **Start range IP**: Minimum size of two available IP addresses is required. One IP address is for the Azure Arc resource bridge VM, and the other is reserved for upgrade scenarios. Provide the starting IP address of that range. Ensure the Start range IP has internet access. </br> 5. **End range IP**: Last IP address of the IP range requested in the previous field. Ensure the End range IP has internet access. </br>|

-| **Control Plane IP address** | Azure Arc resource bridge runs a Kubernetes cluster, and its control plane always requires a static IP address. Provide an IP address that meets the following requirements: <br> - The IP address must have internet access. <br> - The IP address must be within the subnet defined by IP address prefix. <br> - If you're using static IP address option for resource bridge VM IP address, the control plane IP address must be outside of the IP address range provided for the VM (Start range IP - End range IP). <br> - If there's a DHCP service on the network, the IP address must be outside of DHCP range.|

-| **VM template Name** | Provide a name for the VM template that will be created in your vCenter Server instance based on the downloaded OVA file. For example: **arc-appliance-template**. |

-[Azure Active Directory authentication]: azure-maps-authentication.md#azure-ad-authentication

-[Azure Active Directory authentication]: azure-maps-authentication.md#azure-ad-authentication

-[Implement dynamic styling for Creator  indoor maps]: indoor-map-dynamic-styling.md

-<center></center>

-<center>

-</center>

-There's usually no difference, with a couple of exceptions:

-We strongly encourage updating to the [new API](https://learn.microsoft.com/azure/azure-monitor/app/resource-manager-app-resource) for better control over resource creation.

-* Python 3.7 or later installed. To install the latest, see [Python.org](https://www.python.org/downloads/)

->**Azure VMware Solution private cloud (source) > ExpressRoute gateway (source) > ExpressRoute gateway (target) > Azure VMware Solution private cloud (target)**

-

- You can have up to eight VLANs per appliance, but you can deploy another appliance to add another eight VLANs. You must also have IP space to account for the more appliances, and it's one IP per appliance. For more information, see [VMware HCX Configuration Limits](https://configmax.vmware.com/guest?vmwareproduct=VMware%20HCX&release=VMware%20HCX&categories=41-0,42-0,43-0,44-0,45-0).

-3. Use VMware HCX to migrate all VM templates from the source's vCenter Server to the target's vCenter.

-In this step, use the source NSX-T Data Center configuration to configure the target NSX-T environment.

->You'll have multiple features configured on the source NSX-T Data Center, so you must copy or read from the source NSX-T Data Center and recreate it in the target private cloud. Use L2 Extension to keep same IP address and Mac Address of the VM while migrating Source to target AVS Private Cloud to avoid downtime due to IP change and related configuration.

-> [Tutorial: Add a custom domain to your Azure CDN endpoint](cdn-map-content-to-custom-domain.md)

-description: An explanation of legacy devices on the Azure Certified Device catalog

-# Legacy devices on the Azure Certified Device catalog

-You may have noticed on the Azure Certified Device catalog that some devices don't have the blue outline or the "Azure Certified Device" label. These devices (dubbed "legacy devices") were previously certified under the legacy program.

-## Certified for Azure IoT program

-Before the launch of the Azure Certified Device program, hardware partners could previously certify their products under the Certified for Azure IoT program. The Azure Certified Device certification program refocuses its mission to deliver on customer promises rather than technical device capabilities.

-Devices that have been certified as an ΓÇÿIoT Hub certified deviceΓÇÖ appear on the Azure Certified Device catalog as a ΓÇÿlegacy device.ΓÇÖ This label indicates devices have previously qualified through the now-retired program, but haven't been certified through the updated Azure Certified Device program. These devices are clearly noted in the catalog by their lack of blue outline, and can be found through the "IoT Hub Certified devices (legacy)" filter.

-## Next steps

-Interested in recertifying a legacy device under the Azure Certified Device program? You can submit your device through our portal and leave a note to our review team to coordinate. Follow the link below to get started!

-description: A description of the different marketing fields collected in the portal and how they will appear on the Azure Certified Device catalog

-# Marketing properties

-In the process of [adding your device details](tutorial-02-adding-device-details.md), you will be required to supply marketing information that will be displayed on the [Azure Certified Device catalog](https://devicecatalog.azure.com). This information is collected within the Azure Certified Device portal during the certification submission process and will be used as filter parameters on the catalog. This article provides a mapping between the fields collected in the portal to how they appear on the catalog. After reading this article, partners should better understand what information to provide during the certification process to best represent their product on the catalog.

-

-## Azure Certified Device catalog product tile

-Visitors to the catalog will first interact with your device as a catalog product tile on the search page. This will provide a basic overview of the device and certifications it has been awarded.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Device Name | Public name of your certified device | Basics tab of Device details|

-| Company name| Public name of your company | Not editable in the portal. Extracted from MPN account name |

-| Product photo | Image of your device with minimum resolution 200p x 200p | Marketing details |

-| Certification classification | Mandatory Azure Certified Device certification label and optional certification badges | Basics tab of Device details. Must pass appropriate testing in Connect & test section. |

-## Product description page information

-Once a customer has clicked on your device tile from the catalog search page, they will be navigated to the product description page of your device. This is where the bulk of the information provided during the certification process will be found.

-The top of the product description page highlights key characteristics, some of which were already used for the product tile.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Device class | Classification of the form factor and primary purpose of your device ([Learn more](./resources-glossary.md)) | Basics tab of Device details|

-| Device type | Classification of device based on implementation readiness ([Learn more](./resources-glossary.md)) | Basics tab of Device details |

-| Geo availability | Regions that your device is available for purchase | Marketing details |

-| Operating systems | Operating system(s) that your device supports | Product details tab of Device details |

-| Target industries | Top 3 industries that your device is optimized for | Marketing details |

-| Product description | Free text field for you to write your marketing description of your product. This can capture details not listed in the portal, or add additional context for the benefits of using your device. | Marketing details|

-The remainder of the page is focused on displaying the technical specifications of your device in table format that will help your customer better understand your product. For convenience, the information displayed at the top of the page is also listed here, along with some additional device information. The rest of the table is sectioned by the components specified in the portal.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Environmental certifications | Official certifications received for performance in different environments | Hardware of Device details |

-| Operating conditions | Ingress Protection value or temperature ranges the device is qualified for | Software of device details |

-| Azure software set-up | Classification of the set-up process to connect the device to Azure ([Learn more](./how-to-software-levels.md)) | Software of Device details |

-| Component type | Classification of the form factor and primary purpose of your device ([Learn more](./resources-glossary.md)) | Hardware of Device details|

-| Component name| Name of the component you are describing | Product details of Device details |

-| Additional component information | Additional hardware specifications such as included sensors, connectivity, accelerators, etc. | Additional component information of Device details ([Learn more](./how-to-using-the-components-feature.md)) |

-| Device dependency text | Partner-provided text describing the different dependencies the product requires to connect to Azure ([Learn more](./how-to-indirectly-connected-devices.md)) | Customer-facing comments section of Dependencies tab of Device details |

-| Device dependency link | Link to a certified device that your current product requires | Dependencies tab of Device details |

-## Shop links

-Available both on the product tile and product description page is a Shop button. When clicked by the customer, a window opens that allows them to select a distributor (you are allowed to list up to 5 distributors). Once selected, the customer is redirected to the partner-provided URL.

-

-| Field | Description | Where to add in the portal |

-||-|-|

-| Distributor name | Name of the distributor who is selling your product | Marketing details|

-| Get Device| Link to external website for customer to purchase the device (or request a quote from the distributor). This may be the same as the Manufacturer's page if the distributor is the same as the device manufacturer. If a purchase page is not available, this will redirect to the distributor's page for customer to contact them directly. | Distributor product page URL in marketing details. If no purchase page is available, link will default to Distributor URL in Marketing detail. |

-## External links

-Also included within the Product Description page are links that navigate to partner-provided sites or files that help the customer better understand the product. They appear towards the top of the page, beneath the product description text. The links displayed will differ for different device types and certification programs.

-| Link | Description | Where to add in the portal |

-||-|-|

-| Get Started guide* | PDF file with user instructions to connect and use your device with Azure services | Add 'Get Started' guide section of the portal|

-| Manufacturer's page*|Link to manufacturer's page. This page may be the specific product page for your device, or to the company home page if a marketing page is not available. | Manufacturer's marketing page in Marketing details |

-| Device model | Public DTDL models for IoT Plug and Play solutions | Not editable in the portal. Device model must be uploaded to the ([public model repository](https://aka.ms/modelrepo) |

-| Device source code | URL to device source code for Dev Kit device types| Basics tab of Device details |

- **Required for all published devices*

-## Next steps

-Now that you have an understanding of how we use the information you provide during certification, you are now ready to certify your device! Begin your certification project, or jump back into the device details stage to add your own marketing information.

-description: A guide to edit you device information after you have certified and published your device through the Azure Certified Device program.

-# Edit your published device

-After your device has been certified and published to the Azure Certified Device catalog, you may need to update your device details. This may be due to an update to your distributor list, changes to purchase page URLs, or updates to the hardware specifications (such as operating system version or a new component addition). You may also have to update your IoT Plug and Play device model from what you originally uploaded to the model repository.

-## Prerequisites

-## Editing your published project information

-On the project summary, you should notice that your project is in read-only mode since it has already been reviewed and accepted. To make changes, you will have to request an edit to your project and have the update re-approved by the Azure Certification team.

-1. Click the `Request Metadata Edit` button on the top of the page

- 

-1. Acknowledge the notification on the page that you will be required to submit your product for review after editing.

- > [!NOTE]

- > By confirming this edit, you are **not** removing your device from the Azure Certified Device catalog if it has already been published. Your previous version of the product will remain on the catalog until you have republished your device.

- > You will also not have to repeat the Connect & test section of the portal.

-1. Once acknowledging this warning, you can edit your device details. Make sure to leave a note in the `Comments for Reviewer` section of `Device Details` of what has been changed.

- 

-1. On the project summary page, click `Submit for review` to have your changes reapproved by the Azure Certification team.

-1. After your changes have been reviewed and approved, you can then republish your changes to the catalog through the portal (See our [tutorial](./tutorial-04-publishing-your-device.md)).

-## Editing your IoT Plug and Play device model

-Once you have submitted your device model to the public model repository, it cannot be removed. If you update your device model and would like to re-link your certified device to the new model, you **must re-certify** your device as a new project. If you do this, please leave a note in the 'Comments for Reviewer' section so the certification team can remove your old device entry.

-## Next steps

-You've now successfully edited your device on the Azure Certified Device catalog. You can check out your changes on the catalog, or certify another device!

-# Mandatory fields.

-description: Learn how to submit a bundled or indirectly connected device for Azure Certified Device certification. See how to configure dependencies and components.

-# Optional fields. Don't forget to remove # if you need a field.

-#

-#

-# Device bundles and indirectly connected devices

-Many devices interact with Azure indirectly. Some communicate through another device, such as a gateway. Others connect through software as a service (SaaS) or platform as a service (PaaS) offerings.

-The [submission portal](https://certify.azure.com/) and [device catalog](https://devicecatalog.azure.com) offer support for indirectly connected devices:

-This functionality gives indirectly connected devices access to the Azure Certified Device program.

-Depending on your product line and the services that you offer or use, your situation might require a combination of dependencies and bundling. The Azure Edge Certification Portal provides a way for you to list dependencies and additional components.

-## Sensors and indirect devices

-Many sensors require a device to connect to Azure. In addition, you might have multiple compatible devices that work with the sensor. **To accommodate these scenarios, certify the devices before you certify the sensor that passes information through them.**

-The following matrix provides some examples of submission combinations:

-To certify a sensor that requires a separate device:

-1. Go to the [Azure Certified Device portal](https://certify.azure.com) to certify the device and publish it to the Azure Certified Device catalog. If you have multiple, compatible pass-through devices, as in the earlier example, submit them separately for certification and catalog publication.

-1. With the sensor connected through the device, submit the sensor for certification. In the **Dependencies** tab of the **Device details** section, set the following values:

- - **Dependency type**: Select **Hardware gateway**.

- - **Dependency URL**: Enter the URL of the device in the device catalog.

- - **Used during testing**: Select **Yes**.

- - **Customer-facing comments**: Enter any comments that you'd like to provide to a user who sees the product description in the device catalog. For example, you might enter **Series 100 devices are required for sensors to connect to Azure**.

-1. If you'd like to add more devices as optional for this device:

- 1. Select **Add additional dependency**.

- 1. Enter **Dependency type** and **Dependency URL** values.

- 1. For **Used during testing**, select **No**.

- 1. For **Customer-facing comments**, enter a comment that informs your customers that other devices are available as alternatives to the device that was used during testing.

-## PaaS and SaaS offerings

-As part of your product portfolio, you might certify a device that requires services from your company or third-party companies. To add this type of dependency:

-1. Go to the [Azure Certified Device portal](https://certify.azure.com) and start the submission process for your device.

-1. In the **Dependencies** tab, enter the following values:

- - **Dependency type**: Select **Software service**.

- - **Service name**: Enter the name of your product.

- - **Dependency URL**: Enter the URL of a product page that describes the service.

- - **Customer-facing comments**: Enter any comments that you'd like to provide to a user who sees the product description in the Azure Certified Device catalog.

-1. If you have other software, services, or hardware dependencies that you'd like to add as optional for this device, select **Add additional dependency** and enter the required information.

-## Bundled products

-With bundled product listings, a device is successfully certified in the Azure Certified Device program with other components. The device and the components are then sold together under one product listing.

-The following matrix provides some examples of bundled products. You can submit a device that includes extra components such as a temperature sensor and a camera sensor, as in submission example 1. You can also submit a touch sensor that includes a pass-through device, as in submission example 2.

-Use the component feature to add multiple components to your listing. Format the product listing image to indicate that your product comes with other components. If your bundle requires additional services for certification, identify those services through service dependencies.

-For a more detailed description of how to use the component functionality in the Azure Certified Device portal, see [Add components on the portal](./how-to-using-the-components-feature.md).

-If a device is a pass-through device with a separate sensor in the same product, create one component to reflect the pass-through device, and another component to reflect the sensor. As the following screenshot shows, you can add components to your project in the **Product details** tab of the **Device details** section:

-Configure the pass-through device first. For **Component type**, select **Customer Ready Product**. Enter the other values, as relevant for your product. The following screenshot provides an example:

-For the sensor, add a second component. For **Component type**, select **Peripheral**. For **Attachment method**, select **Discrete**. The following screenshot provides an example:

-After you've created the sensor component, enter its information. Then go to the **Sensors** tab and enter detailed sensor information, as the following screenshot shows.

-Complete the rest of your project's details, and then submit your device for certification as usual.

-description: A breakdown of the different software levels that an Azure Certified Device may be classified as.

-# Software levels of Azure Certified Devices

-Software levels are a feature defined by the Azure Certified Device program to help device builders indicate the technical level of difficulty a customer can expect when connecting the device to Azure services. Appearing on the catalog as "Azure software set-up," these values are aimed to help viewers better understand the product and its connection to Azure. The definitions of each of these levels are provided below.

-## Level 1

-User can immediately connect device to Azure by simply adding provisioning details. The certified IoT device already contains pre-installed software that was used for certification upon purchase. This level is most similar to having an "out-of-the-box" set-up experience for IoT beginners who are not as comfortable with compiling source code.

-## Level 2

-User must flash/apply manufacturer-provided software image to the device to connect to Azure. Extra tools/software experience may be required. The link to the software image is also provided in our catalog.

-## Level 3

-User must follow a manufacturer-provided guide to prepare and install Azure-specific software. No Azure-specific software image is provided, so some customization and compilation of provided source code is required.

-## Level 4

-User must develop, customize, and recompile their own device code to connect to Azure. No manufacturer-supported source code is available. This level is most well suited for developers looking to create custom deployments for their device.

-## Next steps

-These levels are aimed to help you get started with building IoT solutions with Azure! Ready to get started? Visit the [Azure Certified Device catalog](https://devicecatalog.azure.com) to get searching for devices!

-Are you a device builder who is looking to add this software level to your certified device? Check out the links below.

-description: A guide describing how to test Device Update for IoT Hub on a Linux host in preparation for Edge Secured-core certification.

-# How to test Device Update for IoT Hub

-The [Device Update for IoT Hub](..\iot-hub-device-update\understand-device-update.md) test exercises your deviceΓÇÖs ability to receive an update from IoT Hub. The following steps will guide you through the process to test Device Update for IoT Hub when attempting device certification.

-## Prerequisites

-* Device must be capable of running Linux [IoT Edge supported container](..\iot-edge\support.md).

-* Your device must be capable of receiving an [.SWU update](https://swupdate.org/) and be able to return to a running and connected state after the update is applied.

-* The update package and manifest must be applicable to the device under test. (Example: If the device is running ΓÇ£Version 1.0ΓÇ¥, the update should be ΓÇ£Version 2.0ΓÇ¥.)

-* Upload your .SWU file to a blob storage location of your choice.

-* Create a SAS URL for accessing the uploaded .SWU file.

-## Test the device

-1. On the Connect + test page, select **"Yes"** for the **"Are you able to test Device Update for IoT Hub?"** question.

- > [!Note]

- > If you are not able to test Device Update and select No, you will still be able to run all other Secured-core tests, but your product will not be eligible for certification.

- :::image type="content" source="./media/how-to-adu/connect-test.png" alt-text="Dialog to confirm that you are able to test device for IoT Hub.":::

-2. Proceed with connecting your device to the test infrastructure.

-3. On the Select Requirement Validation step, select **"Upload"**.

- :::image type="content" source="./media/how-to-adu/connect-and-test.png" alt-text="Dialog that shows the selected tests that will be validated.":::

-4. Upload your .importmanifest.json file by selecting the **Choose File** button. Select your file and then select the **Upload** button.

- > [!Note]

- > The file extension must be .importmanifest.json.

-

- :::image type="content" source="./media/how-to-adu/upload-manifest.png" alt-text="Dialog to instruct the user to upload the .importmanifest.json file by selecting the choose File button.":::

-5. Copy and Paste the SAS URL to the location of your .SWU file in the provided input box, then select the **Validate** button.

- :::image type="content" source="./media/how-to-adu/input-sas-url.png" alt-text="Dialog that shows how the SAS url is applied.":::

-6. Once weΓÇÖve validated our service can reach the provided URL, select **Import**.

- :::image type="content" source="./media/how-to-adu/finalize-import.png" alt-text="Dialog to inform the user that the SAS URL was reachable and that the user needs to click import.":::

- > [!Note]

- > If you receive an ΓÇ£Invalid SAS URLΓÇ¥ message, generate a new SAS URL from your storage blob and try again.

-7. Select **Continue** to proceed

-8. Congratulations! You're now ready to proceed with Edge Secured-core testing.

-9. Select the **Run tests** button to begin the testing process. Your device will be updated as the final step in our Edge Secured-core testing.

-description: A guide on how to best use the components feature of the Device details section to accurately describe your device

-# Add components on the portal

-While completing the [tutorial to add device details](tutorial-02-adding-device-details.md) to your certification project, you will be expected to describe the hardware specifications of your device. To do so, users can highlight multiple, separate hardware products (referred to as **components**) that make up your device. This enables you to better promote devices that come with additional hardware, and allows customers to find the right product by searching on the catalog based on these features.

-## Prerequisites

-## How to add components

-Every project submitted for certification will include one **Customer Ready Product** component (which in many cases will represent the holistic product itself). To better understand the distinction of a Customer Ready Product component type, view our [certification glossary](./resources-glossary.md). All additional components are at your discretion to include to accurately capture your device.

-1. Select `Add a component` on the Hardware tab.

- 

-1. Complete relevant form fields for the component.

- 

-1. Save your information using the `Save Product Details` button at the bottom of the page:

- 

-1. Once you have saved your component, you can further tailor the hardware capabilities it supports. Select the `Edit` link by the component name.

- 

-1. Provide relevant hardware capability information where appropriate.

- 

- The editable component fields (shown above) include:

- - **General**: Hardware details such as processors and secure hardware

- - **Connectivity**: Connectivity options, protocols, and interfaces such as radio(s) and GPIO

- - **Accelerators**: Specify hardware acceleration such as GPU and VPU

- - **Sensors**: Specify available sensors such as GPS and vibration

- - **Additional Specs**: Additional information about the device such as physical dimensions and storage/battery information

-1. Select `Save Product Details` at the bottom of the Product details page.

-## Component use requirements and recommendations

-You may have questions regarding how many components to include, or what component type to use. Below are examples of a few sample scenarios of devices that you may be certifying, and how you can use the components feature.

-| Product Type | No. Components | Component 1 / Attachment Type | Components 2+ / Attachment Type |

-|-||-|--|

-| Finished Product | 1 | Customer Ready Product, Discrete | N/A |

-| Finished Product with **detachable peripheral(s)** | 2 or more | Customer Ready Product, Discrete | Peripheral / Discrete or Integrated |

-| Finished Product with **integrated component(s)** | 2 or more | Customer Ready Product, Discrete | Select appropriate type / Discrete or integrated |

-| Solution-Ready Dev Kit | 1 or more | Customer Ready Product or Development Board, Discrete or Integrated| Select appropriate type / Discrete or integrated |

-## Example component usage

-Below are examples of how an OEM called Contoso would use the components feature to certify their product, called Falcon.

-1. Falcon is a complete stand-alone device that does not integrate into a larger product.

- 1. No. of components: 1

- 1. Component device type: Customer Ready Product

- 1. Attachment type: Discrete

- 

-1. Falcon is a device that includes an integrated peripheral camera module manufactured by INC Electronics that connects via USB to Falcon.

- 1. No. of components: 2

- 1. Component device type: Customer Ready Product, Peripheral

- 1. Attachment type: Discrete, Integrated

-

- > [!Note]

- > The peripheral component is considered integrated because it is not removable.

- 

-1. Falcon is a device that includes an integrated System on Module from INC Electronics that uses a built-in processor Apollo52 from company Espressif and has an ARM64 architecture.

- 1. No. of components: 2

- 1. Component device type: Customer Ready Product, System on Module

- 1. Attachment type: Discrete, Integrated

- > [!Note]

- > The peripheral component is considered integrated because it is not removable. The SoM component would also include processor information.

- 

-## Additional tips

-We've provided below more clarifications regarding our component usage policy. If you have any questions about appropriate component usage, contact our team at [iotcert@microsoft.com](mailto:iotcert@microsoft.com), and we'll be more than happy to help!

-1. A project must contain **only** one Customer Ready Product component. If you are certifying a project with two independent devices, those devices should be certified separately.

-1. It is primarily up to you to use (or not use) components to promote your device's capabilities to potential customers.

-1. During our review of your device, the Azure Certification team will only require at least one Customer Ready Product component to be listed. However, we may request edits to the component information if the details are not clear or appear to be lacking (for example, component manufacturer is not supplied for a Customer Ready Product type).

-## Next steps

-Now that you're ready to use our components feature, you're now ready to complete your device details or edit your project for further clarity.

-description: An overview of the Azure Certified Device program for our partners and customers. Use these resources to start the device certification process. Find out how to certify your device, from IoT device requirements to publishing your device.

-# What is the Azure Certified Device program?

-> [!Note]

-> The Azure Certified Device program has met its goals and will conclude on February 23, 2024. This means that the Azure Certified Device catalog, along with certifications for Azure Certified Device, Edge Managed, and IoT Plug and Play will no longer be available after this date. However, the Edge Secured-core program will remain active and will be relocated to a new home at [aka.ms/EdgeSecuredCoreHome](https://aka.ms/EdgeSecuredCoreHome).

-Thank you for your interest in the Azure Certified Device program! Azure Certified Device is a free program that enables you to differentiate, certify, and promote your IoT devices built to run on Azure. From intelligent cameras to connected sensors to edge infrastructure, this enhanced IoT device certification program helps device builders increase their product visibility and saves customers time in building solutions.

-## Our certification promise

-The Azure Certified Device program ensures customer solutions work great on Azure. It is a program that utilizes tools, services, and a catalog to share industry knowledge with our community of builders within the IoT ecosystem to help builders and customers alike.

-Across the device certification process, the three tenets of this program are:

-The Azure Certified Device program serves two different audiences.

-1. **Device builders**: Do you build IoT devices? Easily differentiate your IoT device capabilities and gain access to a worldwide audience looking to reliably purchase devices built to run on Azure. Use the Azure Certified Device Catalog to increase product visibility and connect with customers by certifying your device and show it meets specific IoT device requirements.

-1. **Solution builders**: Wondering what are IoT qualified devices? Confidently find and purchase IoT devices built to run on Azure, knowing they meet specific IoT requirements. Easily search and select the right certified device for your IoT solution on the [Azure Certified Device catalog](https://devicecatalog.azure.com/).

-## Our certification programs and IoT device requirements.

-There are four different certifications available now! Each certification is focused on delivering a different customer value. Depending on the type of device and your target audience, you can choose which certification(s) is most applicable for you to apply for. Select the titles of each program to learn more about the program and IoT requirements.

-| Certification program | Overview |

-|-|

-| [Azure Certified Device](program-requirements-azure-certified-device.md) | Azure Certified Device certification validates that a device can connect with Azure IoT Hub and securely provision through the Device Provisioning Service (DPS). This certification reflects a device's functionality and interoperability, which are a **required baseline** for all other certifications. |

-| [IoT Plug and Play](program-requirements-pnp.md) | IoT Plug and Play certification, an incremental certification beyond the baseline Azure Certified Device certification, validates Digital Twin Definition Language version 2 (DTDL) and interaction based on your device model. It enables a seamless device-to-cloud integration experience and enables hardware partners to build devices that can seamlessly integrate without the need to write custom code. |

-| [Edge Managed](program-requirements-edge-managed.md) | Edge Managed certification, an incremental certification beyond the baseline Azure Certified Device certification, focuses on device management standards for Azure connected devices. |

-| [Edge Secured Core](program-requirements-edge-secured-core.md) | Edge Secured-core certification, an incremental certification beyond the baseline Azure Certified Device certification, is for IoT devices running a full operating system such as Linux or Windows 10 IoT. It validates devices meet additional security requirements around device identity, secure boot, operating system hardening, device updates, data protection, and vulnerability disclosures. |

-## How to certify your device

-Certifying a device involves several major steps on the [Azure Certified Device portal](https://certify.azure.com):

-1. Select the right certification for your device based on the IoT device requirements.

-1. Create your project in the [Azure Certified Device portal](https://certify.azure.com).

-1. Add device details including hardware capability information to begin the device certification process.

-1. Validate device functionality

-1. Submit and complete the review process

-> [!Note]

-> The review process can take up to a week to complete, though sometimes may take longer.

-Once you have certified your device, you then can optionally complete two of the following activities:

-1. Publishing to the Azure Certified Device Catalog (optional)

-1. Updating your project after it has been approved/published (optional)

-Ready to get started with your certification journey? View our resources below to start the device certification process!

-description: Azure Certified Device Certification Requirements

-# Azure Certified Device Certification Requirements

-> [!Note]

-> The Azure Certified Device program has met its goals and will conclude on February 23, 2024. This means that the Azure Certified Device catalog, along with certifications for Azure Certified Device, Edge Managed, and IoT Plug and Play will no longer be available after this date. However, the Edge Secured-core program will remain active and will be relocated to a new home at [aka.ms/EdgeSecuredCoreHome](https://aka.ms/EdgeSecuredCoreHome).

-This document outlines the device specific capabilities that will be represented in the Azure Certified Device catalog. A capability is singular device attribute that may be software implementation or combination of software and hardware implementations.

-## Program Purpose

-Microsoft is simplifying IoT and Azure Certified Device certification is baseline certification program to ensure any device types are provisioned to Azure IoT Hub securely.

-Promise of Azure Certified Device certification are:

-1. Device support telemetry that works with IoT Hub

-2. Device support IoT Hub Device Provisioning Service (DPS) to securely provisioned to Azure IoT Hub

-3. Device supports easy input of target DPS ID scope transfer without requiring user to recompile embedded code.

-4. Optionally validates other elements such as cloud to device messages, direct methods and device twin

-## Requirements

-**[Required] Device to cloud: The purpose of test is to make sure devices that send telemetry works with IoT Hub**

-| **Name** | AzureCertified.D2C |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must send any telemetry schemas to IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com/) to execute the tests. Device to cloud (required): **1.** Validates that the device can send message to AICS managed IoT Hub **2.** User must specify the number and frequency of messages. **3.** AICS validates the telemetry is received by the Hub instance |

-| **Resources** | [Certification steps](./overview.md) (has all the additional resources) |

-**[Required] DPS: The purpose of test is to check the device implements and supports IoT Hub Device Provisioning Service with one of the three attestation methods**

-| **Name** | AzureCertified.DPS |

-| -- | |

-| **Target Availability** | New |

-| **Applies To** | Any device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device supports easy input of target DPS ID scope ownership. Microsoft provides the [portal workflow](https://certify.azure.com) to execute the tests to validate that the device supports DPS **1.** User must select one of the attestation methods (X.509, TPM and SAS key) **2.** Depending on the attestation method, user needs to take corresponding action such as **a)** Upload X.509 cert to AICS managed DPS scope **b)** Implement SAS key or endorsement key into the device |

-| **Resources** | [Device provisioning service overview](../iot-dps/about-iot-dps.md) |

-**[If implemented] Cloud to device: The purpose of test is to make sure messages can be sent from cloud to devices**

-| **Name** | AzureCertified.C2D |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must be able to Cloud to Device messages from IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com) to execute these tests.Cloud to device (if implemented): **1.** Validates that the device can receive message from IoT Hub **2.** AICS sends random message and validates via message ACK from the device |

-| **Resources** | **a)** [Certification steps](./overview.md) (has all the additional resources) **b)** [Send cloud to device messages from an IoT Hub](../iot-hub/iot-hub-devguide-messages-c2d.md) |

-**[If implemented] Direct methods: The purpose of test is to make sure devices works with IoT Hub and supports direct methods**

-| **Name** | AzureCertified.DirectMethods |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must be able to receive and reply commands requests from IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com) to execute the tests. Direct methods (if implemented) **1.** User has to specify the method payload of direct method. **2.** AICS validates the specified payload request is sent from Hub and ACK message received by the device |

-| **Resources** | **a)** [Certification steps](./overview.md) (has all the additional resources) **b)** [Understand direct methods from IoT Hub](../iot-hub/iot-hub-devguide-direct-methods.md) |

-**[If implemented] Device twin property: The purpose of test is to make sure devices that send telemetry works with IoT Hub and supports some of the IoT Hub capabilities such as direct methods, and device twin property**

-| **Name** | AzureCertified.DeviceTwin |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Leaf device/Edge device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | Device must send any telemetry schemas to IoT Hub. Microsoft provides the [portal workflow](https://certify.azure.com) to execute the tests. Device twin property (if implemented) **1.** AICS validates the read/write-able property in device twin JSON **2.** User has to specify the JSON payload to be changed **3.** AICS validates the specified desired properties sent from IoT Hub and ACK message received by the device |

-| **Resources** | **a)** [Certification steps](./overview.md) (has all the additional resources) **b)** [Use device twins with IoT Hub](../iot-hub/iot-hub-devguide-device-twins.md) |

-**[Required] Limit Recompile: The purpose of this policy ensures devices by default should not need users to re-compile code to deploy the device.**

-| **Name** | AzureCertified.Policy.LimitRecompile |

-| -- | |

-| **Target Availability** | Policy |

-| **Applies To** | Any device |

-| **OS** | Agnostic |

-| **Validation Type** | Policy |

-| **Validation** | To simplify device configuration for users, we require all devices can be configured to connect to Azure without the need to recompile and deploy device source code. This includes DPS information, such as Scope ID, which should be set as configuration settings and not compiled. However, if your device contains certain secure hardware or if there are extenuating circumstances in which the user will expect to compile and deploy code, contact the certification team to request an exception review. |

-| **Resources** | **a)** [Device provisioning service overview](../iot-dps/about-iot-dps.md) **b)** Sample config file for DPS ID Scope transfer |

-description: Edge Managed Certification Requirements

-# Edge Managed Certification Requirements

-> [!Note]

-> The Azure Certified Device program has met its goals and will conclude on February 23, 2024. This means that the Azure Certified Device catalog, along with certifications for Azure Certified Device, Edge Managed, and IoT Plug and Play will no longer be available after this date. However, the Edge Secured-core program will remain active and will be relocated to a new home at [aka.ms/EdgeSecuredCoreHome](https://aka.ms/EdgeSecuredCoreHome).

-This document outlines the device specific capabilities that will be represented in the Azure Certified Device catalog. A capability is singular device attribute that may describe the device.

-## Program Purpose

-Edge Managed certification, an incremental certification beyond the baseline Azure Certified Device certification. Edge Managed focuses on device management standards for Azure connected devices and validates the IoT Edge runtime compatibility for module deployment and management. (Previously, this program was identified as the IoT Edge certification program.)

-Edge Managed certification validates IoT Edge runtime compatibility for module deployment and management. This program provides confidence in the management of Azure connected IoT devices.

-## Requirements

-The Edge Managed certification requires that all requirements from the [Azure Certified Device baseline program](.\program-requirements-azure-certified-device.md).

-**DPS: The purpose of test is to check the device implements and supports IoT Hub Device Provisioning Service with one of the three attestation methods**

-| **Name** | AzureReady.DPS |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | Any device |

-| **OS** | Agnostic |

-| **Validation Type** | Automated |

-| **Validation** | AICS validates the device code support DPS. **1.** User has to select one of the attestation methods (X.509, TPM and SAS key). **2.** Depending on the attestation method, user needs to take corresponding action such as **a)** Upload X.509 cert to AICS managed DPS scope **b)** Implement SAS key or endorsement key into the device. **3.** Then, user will hit ΓÇÿConnectΓÇÖ button to connect to AICS managed IoT Hub via DPS |

-| **Resources** | |

-| **Azure Recommended:** | N/A |

-## IoT Edge

-**Edge runtime exists: The purpose of test is to make sure the device contains IoT Edge runtime ($edgehub and $edgeagent) are functioning correctly.**

-| **Name** | EdgeManaged.EdgeRT |

-| -- | |

-| **Target Availability** | Available now |

-| **Applies To** | IoT Edge device |

-| **OS** | [Tier1 and Tier2 OS](../iot-edge/support.md) |

-| **Validation Type** | Automated |

-| **Validation** | AICS validates the deploy-ability of the installed IoT Edge RT. **1.** User needs to specify specific OS (OS not on the list of Tier1/2 are not accepted) **2.** AICS generates its config.yaml and deploys canonical [simulated temp sensor edge module](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/azure-iot.simulated-temperature-sensor?tab=Overview) **3.** AICS validates that docker compatible container subsystem (Moby) is installed on the device **4.** Test result is determined based on successful deployment of the simulated temp sensor edge module and functionality of docker compatible container subsystem |

-| **Resources** | **a)** [AICS blog](https://azure.microsoft.com/blog/expanding-azure-iot-certification-service-to-support-azure-iot-edge-device-certification/), **b)** [Certification steps](./overview.md) (has all the additional resources), **c)** [Requirements](./program-requirements-azure-certified-device.md) |

-| **Azure Recommended:** | N/A |

-### Capability Template:

-**IoT Edge easy setup: The purpose of test is to make sure IoT Edge device is easy to set up and validates IoT Edge runtime is preinstalled during physical device validation**

-| **Name** | EdgeManaged.PhysicalDevice |

-| -- | |

-| **Target Availability** | Available now (currently on hold due to COVID-19) |

-| **Applies To** | IoT Edge device |

-| **OS** | [Tier1 and Tier2 OS](../iot-edge/support.md) |

-| **Validation Type** | Manual / Lab Verified |

-| **Validation** | OEM must ship the physical device to IoT administration (HCL). HCL performs manual validation on the physical device to check: **1.** EdgeRT is using Moby subsystem (allowed redistribution version). Not docker **2.** Pick the latest edge module to validate ability to deploy edge. |

-| **Resources** | **a)** [AICS blog](https://azure.microsoft.com/blog/expanding-azure-iot-certification-service-to-support-azure-iot-edge-device-certification/), **b)** [Certification steps](./overview.md) , **c)** [Requirements](./program-requirements-azure-certified-device.md) |

-| **Azure Recommended:** | N/A |

-# Azure Certified Device - Edge Secured-core #

-## Edge Secured-Core certification requirements ##

-### Program purpose ###

-Edge Secured-core is a security certification for devices running a full operating system. Edge Secured-core currently supports Windows IoT and Azure Sphere OS. Linux support is coming in the future. This program enables device partners to differentiate their devices by meeting an additional set of security criteria. Devices meeting this criteria enable these promises:

-1. Hardware-based device identity

-2. Capable of enforcing system integrity

-3. Stays up to date and is remotely manageable

-4. Provides data at-rest protection

-5. Provides data in-transit protection

-6. Built in security agent and hardening

-Edge Secured-core for Windows IoT requires Windows 10 IoT Enterprise version 1903 or greater

-> [!Note]

-> The Windows secured-core tests require you to download and run the following package (https://aka.ms/Scforwiniot) from an Administrator Command Prompt on the IoT device being validated.

-> * Kernel DMA Protection (also known as Memory Access Protection)

-|Description|The purpose of the requirement is to validate the device identity is rooted in hardware and can be the primary authentication method with Azure IoT Hub Device Provisioning Service (DPS).|

-|Requirements dependency|TPM v2.0 device|

-|Validation Type|Manual/Tools|

-|Validation|Devices are enrolled to DPS using the TPM authentication mechanism during testing.|

-|Resources|Azure IoT Hub Device Provisioning Service: <ul><li>[Quickstart - Provision a simulated TPM device to Microsoft Azure IoT Hub](../iot-dps/quick-create-simulated-device-tpm.md) </li><li>[TPM Attestation Concepts](../iot-dps/concepts-tpm-attestation.md)</li></ul>|

-|Description|The purpose of the requirement is to validate that DMA isn't enabled on externally accessible ports.|

-|Requirements dependency|Only if DMA capable ports exist|

-|Validation Type|Manual/Tools|

-|Validation|If DMA capable external ports exist on the device, toolset to validate that the IOMMU, or SMMU is enabled and configured for those ports.|

-|Description|The purpose of the requirement is to ensure that device has adequate mitigations from Firmware security threats.|

-|Requirements dependency|DRTM + UEFI|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to confirm it's protected from firmware security threats through one of the following approaches: <ul><li>DRTM + UEFI Management Mode mitigations</li><li>DRTM + UEFI Management Mode hardening</li></ul> |

-|Resources| <ul><li>https://trustedcomputinggroup.org/</li><li>[Intel's DRTM based computing whitepaper](https://www.intel.com/content/dam/www/central-libraries/us/en/documents/drtm-based-computing-whitepaper.pdf)</li><li>[AMD Security whitepaper](https://www.amd.com/system/files/documents/amd-security-white-paper.pdf)</li></ul> |

-|Description|The purpose of the requirement is to validate the boot integrity of the device.|

-|Requirements dependency|UEFI|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure that firmware and kernel signatures are validated every time the device boots. <ul><li>UEFI: Secure boot is enabled</li></ul>|

-|Description|The purpose of the requirement is to ensure the device can remotely attest to the Microsoft Azure Attestation service.|

-|Requirements dependency|Azure Attestation Service|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that platform boot logs and measurements of boot activity can be collected and remotely attested to the Microsoft Azure Attestation service.|

-|Resources| [Microsoft Azure Attestation](../attestation/index.yml) |

-## Windows IoT configuration requirements

-|Description|The purpose of the requirement to validate that sensitive data can be encrypted on nonvolatile storage.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure Secure-boot and BitLocker is enabled and bound to PCR7.|

-|Description|The purpose of the requirement is to validate support for required TLS versions and cipher suites.|

-|Requirements dependency|Windows 10 IoT Enterprise Version 1903 or greater. Note: other requirements might require greater versions for other services. |

-|Validation Type|Manual/Tools|

-Validation|Device to be validated through toolset to ensure the device supports a minimum TLS version of 1.2 and supports the following required TLS cipher suites.<ul><li>TLS_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_RSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</li></ul>|

-|Resources| [TLS support in IoT Hub](../iot-hub/iot-hub-tls-support.md) <br /> [TLS Cipher suites in Windows 10](/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903) |

-|Description|The purpose of this requirement is to validate that code integrity is available on this device.|

-|Requirements dependency|HVCI is enabled on the device.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure that HVCI is enabled on the device.|

-|Resources| [Hypervisor-protected Code Integrity enablement](/windows-hardware/design/device-experiences/oem-hvci-enablement) |

-|Description|The purpose of the requirement is to validate that services listening for input from the network aren't running with elevated privileges.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through [Edge Secured-core Agent](https://aka.ms/Scforwiniot) toolset to ensure that third party services accepting network connections aren't running with elevated LocalSystem and LocalService privileges. <ol><li>Exceptions might apply</li></ol>|

-|Description|The purpose of the requirement is to make sure devices can report security information and events by sending data to Azure Defender for IoT. <br>Note: Download and deploy security agent from GitHub|

-|Target Availability|2022|

-|Validation Type|Manual/Tools|

-|Validation |Device must generate security logs and alerts. Device logs and alerts messages to Azure Security Center.<ol><li>Device must have the Azure Defender microagent running</li><li>Configuration_Certification_Check must report TRUE in the module twin</li><li>Validate alert messages from Azure Defender for IoT.</li></ol>|

-|Resources|[Azure Docs IoT Defender for IoT](../defender-for-iot/how-to-configure-agent-based-solution.md)|

-|Description|The purpose of the requirement is to validate that the system conforms to a baseline security configuration.|

-|Target Availability|2022|

-|Requirements dependency|Azure Defender for IoT|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that Defender IOT system configurations benchmarks have been run.|

-|Resources| https://techcommunity.microsoft.com/t5/microsoft-security-baselines/bg-p/Microsoft-Security-Baselines <br> https://www.cisecurity.org/cis-benchmarks/ |

-## Windows IoT Policy Requirements

-Some requirements of this program are based on a business agreement between your company and Microsoft. The following requirements aren't validated through our test harness, but are required by your company in certifying the device.

-</br>

-|Description|The purpose of the requirement is to validate that debug functionality on the device is disabled.|

-|Requirements dependency||

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that debug functionality requires authorization to enable.|

-|Description|The purpose of this requirement is to validate the device against two use cases: a) Ability to perform a reset (remove user data, remove user configs), b) Restore device to last known good in the case of an update causing issues.|

-|Requirements dependency||

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through a combination of toolset and submitted documentation that the device supports this functionality. The device manufacturer can determine whether to implement these capabilities to support remote reset or only local reset.|

-|Description|The purpose of this policy is to ensure that the device remains secure.|

-|Validation Type|Manual|

-|Validation|Commitment from submission that devices certified can be kept up to date for 60 months from date of submission. Specifications available to the purchaser and devices itself in some manner should indicate the duration for which their software will be updated.|

-|Description|The purpose of this policy is to ensure that there's a mechanism for collecting and distributing reports of vulnerabilities in the product.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-|Description|The purpose of this policy is to ensure that vulnerabilities that are high/critical (using CVSS 3.0) are addressed within 180 days of the fix being available.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-> Linux is not yet supported. The below represent expected requirements. Please contact iotcert@microsoft.com if you are interested in certifying a Linux device, including device HW and OS specs, and whether or not it meets each of the draft requirements below.

-|Description|The purpose of the requirement is to validate the device identify is rooted in hardware.|

-|Requirements dependency|TPM v2.0 </br>^{or *other supported method}|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that the device has a HWRoT present and that it can be provisioned through DPS using TPM or SE.|

-|Resources|[Setup auto provisioning with DPS](../iot-dps/quick-setup-auto-provision.md)|

-|Description|The purpose of the requirement is to validate ensure that memory integrity helps protect the device from vulnerable peripherals.|

-|Validation Type|Manual/Tools|

-|Validation|memory regions for peripherals must be gated with hardware/firmware such as memory region domain controllers or SMMU (System memory management Unit).|

-|Description|The purpose of the requirement is to ensure that device has adequate mitigations from Firmware security threats.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to confirm it's protected from firmware security threats through one of the following approaches: <ul><li>Approved FW that does SRTM + runtime firmware hardening</li><li>Firmware scanning and evaluation by approved Microsoft third party</li></ul> |

-|Resources| https://trustedcomputinggroup.org/ |

-|Description|The purpose of the requirement is to validate the boot integrity of the device.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that firmware and kernel signatures are validated every time the device boots. <ul><li>UEFI: Secure boot is enabled</li><li>Uboot: Verified boot is enabled</li></ul>|

-|Description|The purpose of the requirement is to ensure the device can remotely attest to the Microsoft Azure Attestation service.|

-|Dependency|TPM 2.0 </br>^{or *supported OP-TEE based application chained to a HWRoT (Secure Element or Secure Enclave)}|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that platform boot logs and applicable runtime measurements can be collected and remotely attested to the Microsoft Azure Attestation service.|

-|Resources| [Microsoft Azure Attestation](../attestation/index.yml) </br> Certification portal test includes an attestation client that when combined with the TPM 2.0 can validate the Microsoft Azure Attestation service.|

-|Status|Required|

-|Description|The purpose of the requirement to validate the existence of a secure enclave and that the enclave can be used for security functions.|

-|Validation Type|Manual/Tools|

-|Validation||

-|Description|The purpose of the requirement to validate that sensitive data can be encrypted on nonvolatile storage.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure storage encryption is enabled and default algorithm is XTS-AES, with key length 128 bits or higher.|

-|Description|The purpose of the requirement is to validate support for required TLS versions and cipher suites.|

-|Validation Type|Manual/Tools|

-Validation|Device to be validated through toolset to ensure the device supports a minimum TLS version of 1.2 and supports the following required TLS cipher suites.<ul><li>TLS_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_RSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li><li>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</li><li>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</li></ul>|

-|Resources| [TLS support in IoT Hub](../iot-hub/iot-hub-tls-support.md) <br /> |

-|Description|The purpose of this requirement is to validate that authorized code runs with least privilege.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that code integrity is enabled by validating dm-verity and IMA|

-|Status|^*Required|

-|Description|The purpose of the requirement is to validate that applications accepting input from the network aren't running with elevated privileges.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that services accepting network connections aren't running with SYSTEM or root privileges.|

-|Description|The purpose of the requirement is to make sure devices can report security information and events by sending data to Microsoft Defender for IoT.|

-|Validation Type|Manual/Tools|

-|Validation |<ol><li>Device must generate security logs and alerts.</li><li>Device logs and alerts messages to Azure Security Center.</li><li>Device must have the Azure Defender for IoT microagent running</li><li>Configuration_Certification_Check must report TRUE in the module twin</li><li>Validate alert messages from Azure Defender for IoT.</li></ol>|

-|Resources|[Azure Docs IoT Defender for IoT](../defender-for-iot/how-to-configure-agent-based-solution.md)|

-|Description|The purpose of the requirement is to validate that device supports auditing and setting of system configuration (and certain management actions such as reboot) through Azure.|

-|Validation Type|Manual/Tools|

-|Validation|<ol><li>Device must report, via IoT Hub, its firewall state, firewall fingerprint, ip addresses, network adapter state, host name, hosts file, TPM (absence, or presence with version) and package manager sources (see What can I manage) </li><li>Device must accept the creation, via IoT Hub, of a default firewall policy (accept vs drop), and at least one firewall rule, with positive remote acknowledgment (see configurationStatus)</li><li>Device must accept the replacement of /etc/hosts file contents via IoT Hub, with positive remote acknowledgment (see https://learn.microsoft.com/en-us/azure/osconfig/howto-hosts?tabs=portal#the-object-model )</li><li>Device must accept and implement, via IoT Hub, remote reboot</li></ol> Note: Use of other system management toolchains (for example, Ansible, etc.) by operators are not prohibited, but the device must include the azure-osconfig agent such that it's ready to be managed from Azure.|

-|Description|The purpose of the requirement is to validate the device can receive and update its firmware and software.|

-|Validation Type|Manual/Tools|

-|Validation|Partner confirmation that they were able to send an update to the device through Azure Device update and other approved services.|

-|Resources|[Device Update for IoT Hub](../iot-hub-device-update/index.yml)|

-|Name|SecuredCore.Protection.Baselines|

-|Description|The purpose of the requirement is to validate the extent to which the device implements the Azure Security Baseline|

-|Dependency|azure-osconfig|

-|Validation Type|Manual/Tools|

-|Validation|OSConfig is present on the device and reporting to what extent it implements the Azure Security Baseline.|

-|Resources|<ul><li>https://techcommunity.microsoft.com/t5/microsoft-security-baselines/bg-p/Microsoft-Security-Baselines</li><li>https://www.cisecurity.org/cis-benchmarks/</li><li>https://learn.microsoft.com/en-us/azure/governance/policy/samples/guest-configuration-baseline-linux</li></ul>|

-|Name|SecuredCore.Protection.SignedUpdates|

-|Description|The purpose of the requirement is to validate that updates must be signed.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that updates to the operating system, drivers, application software, libraries, packages and firmware won't be applied unless properly signed and validated.

-|Description|The purpose of the requirement is to validate that debug functionality on the device is disabled.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through toolset to ensure that debug functionality requires authorization to enable.|

-|Description|The purpose of this requirement is to validate the device against two use cases: a) Ability to perform a reset (remove user data, remove user configs), b) Restore device to last known good if an update causing issues.|

-|Validation Type|Manual/Tools|

-|Validation|Device to be validated through a combination of toolset and submitted documentation that the device supports this functionality. The device manufacturer can determine whether to implement these capabilities to support remote reset or only local reset.|

-|Description|The purpose of this policy is to ensure that the device remains secure.|

-|Validation Type|Manual|

-|Validation|Commitment from submission that devices certified will be required to keep devices up to date for 60 months from date of submission. Specifications available to the purchaser and devices itself in some manner should indicate the duration for which their software will be updated.|

-|Description|The purpose of this policy is to ensure that there's a mechanism for collecting and distributing reports of vulnerabilities in the product.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-|Description|The purpose of this policy is to ensure that vulnerabilities that are high/critical (using CVSS 3.0) are addressed within 180 days of the fix being available.|

-|Validation Type|Manual|

-|Validation|Documentation on the process for submitting and receiving vulnerability reports for the certified devices will be reviewed.|

-## Azure Sphere platform Support

-The Mediatek MT3620AN must be included in your design. Additional guidance for building secured Azure Sphere applications can be within the [Azure Sphere application notes](/azure-sphere/app-notes/app-notes-overview).

-|Description|The purpose of the requirement is to validate the device identity is rooted in hardware.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to ensure that memory integrity helps protect the device from vulnerable peripherals.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to ensure that device has adequate mitigations from Firmware security threats.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate the boot integrity of the device.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to ensure the device can remotely attest to a Microsoft Azure Attestation service.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate hardware security that is accessible from a secure operating system.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate that sensitive data can be encrypted on nonvolatile storage.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Resources|[Data at rest protection on Azure Sphere](/azure-sphere/app-notes/app-notes-overview)|

-|Description|The purpose of the requirement is to validate support for required TLS versions and cipher suites.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Resources| [TLS support in IoT Hub](../iot-hub/iot-hub-tls-support.md) <br /> |

-|Description|The purpose of this requirement is to validate that authorized code runs with least privilege.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate that applications accepting input from the network aren't running with elevated privileges.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate that applications can't connect to endpoints that haven't been authorized.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to make sure devices can report security information and events by sending data to a Microsoft telemetry service.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this requirement is to validate the device supports remote administration via service-based configuration control.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate the device can receive and update its firmware and software.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the requirement is to validate that the system conforms to a baseline security configuration|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Name|SecuredCore.Protection.SignedUpdates|

-|Description|The purpose of the requirement is to validate that updates must be signed.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of the policy requires that debug functionality on the device is disabled.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The policy requires that the device can execute two use cases: a) Ability to perform a reset (remove user data, remove user configurations), b) Restore device to last known good in the case of an update causing issues.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this policy is to ensure that the device remains secure.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-|Description|The purpose of this policy is to ensure that there's a mechanism for collecting and distributing reports of vulnerabilities in the product.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Azure Sphere vulnerabilities are collected by Microsoft through MSRC and are published to customers through the Tech Community Blog, Azure Sphere ΓÇ£WhatΓÇÖs NewΓÇ¥ page, and through MitreΓÇÖs CVE database.|

-|Description|The purpose of this policy is to ensure that vulnerabilities that are high/critical (using CVSS 3.0) are addressed within 180 days of the fix being available.|

-|Validation Type|Prevalidated, no additional validation is required|

-|Validation|Provided by Microsoft|

-description: A list of common terms used in the Azure Certified Device program

-# Azure Certified Device program glossary

-This guide provides definitions of terms commonly used in the Azure Certified Device program and portal. Refer to this glossary for clarification to the certification process. For your convenience, this glossary is categorized based on major certification concepts that you may have questions about.

-## Device class

-When creating your certification project, you will be asked to specify a device class. Device class refers to the form factor or classification that best represents your device.

- A device that processes data sent over an IoT network.

- A device that detects and responds to changes to an environment and connects to gateways to process the changes.

- If you select Other, add a description of your device class in your own words. Over time, we may continue to add new values to this list, particularly as we continue to monitor feedback from our partners.

-## Device type

-You will also be asked to select one of two device types during the certification process.

- A device that is solution-ready and ready for production deployment. Typically in a finished form factor with firmware and an operating system. These may be general-purpose devices that require additional customization or specialized devices that require no modifications for usage.

- A development kit containing hardware and software ideal for easy prototyping, typically not in a finished form factor. Usually includes sample code and tutorials to enable quick prototyping.

-## Component type

-In the Device details section, you'll describe your device by listing components by component type. You can view more guidance on components [here](./how-to-using-the-components-feature.md).

- A component representation of the overall or primary device. This is different from a **Finished Product**, which is a classification of the device as being ready for customer use without further development. A Finished Product will contain a Customer Ready Product component.

- Either an integrated or detachable board with microprocessor for easy customization.

- Either an integrated or detachable addition to the product (such as an accessory). These are typically devices that connect to the main device, but does not contribute to device primary functions. Instead, it provides additional functions. Memory, RAM, storage, hard disks, and CPUs are not considered peripheral devices (they instead should be listed under Additional Specs of the Customer Ready Product component).

- A board-level circuit that integrates a system function in a single module.

-## Component attachment method

-Component attachment method is another component detail that informs the customer about how the component is integrated into the overall product.

-

- Refers to when a device component is a part of the main chassis of the product. This most commonly refers to a peripheral component type that cannot be removed from the device.

- Example: An integrated temperature sensor inside a gateway chassis.

- Refers to when a component is **not** a part of main chassis of the product.

- Example: An external temperature sensor that must be attached to the device.

-## Next steps

-This glossary will guide you through the process of certifying your project on the portal. You're now ready to begin your project!

-description: Step-by-step guide to selecting the right certification programs for your device

-# Tutorial: Select your certification program

-Congratulations on choosing the Azure Certified Device program! We're excited to have you join our ecosystem of certified devices. To begin, you must first determine which certification programs best suit your device capabilities.

-In this tutorial, you learn to:

-> [!div class="checklist"]

-> * Select the best certification program(s) for your device

-## Selecting a certification program for your device

-All devices are required to meet the baseline requirements outlined by the **Azure Certified Device** certification. To better promote your device and help set it apart, we offer optional certification programs (ΓÇ£IoT Plug and PlayΓÇ¥, ΓÇ£Edge ManagedΓÇ¥ and ΓÇ£Edge Secured-core *preview") that validate additional capabilities.

-1. Review each of the certification programs' in the table below to help identify which program is best suited to promote your device.

- |Program Requirements|Processor|Architecture|OS|

- |||

- [Azure Certified Device](./program-requirements-azure-certified-device.md)|Any|Any|Any|

- [IoT Plug and Play](./program-requirements-edge-secured-core.md)|Any|Any|Any|

- [Edge Managed](./program-requirements-edge-managed.md)|MPU/CPU|ARM/x86/AMD64|[Tier 1 OS](../iot-edge/support.md?view=iotedge-2018-06&preserve-view=true)|

- [*Edge Secured-core](./program-requirements-edge-secured-core.md)|MPU/CPU|ARM/AMD64|[Tier 1 OS](../iot-edge/support.md?view=iotedge-2018-06&preserve-view=true)|

-

-1. Review the specific requirements for the selected program and make sure your device is prepared to connect to Azure to validate the requirements.

-## Next steps

-You're now ready to begin certifying your device! Advance to the next article to begin your project.

-> [!div class="nextstepaction"]

->[Tutorial: Creating your project](tutorial-01-creating-your-project.md)

-description: Guide to create a project on the Azure Certified Device portal

-# Tutorial: Create your project

-Congratulations on choosing to certify your device through the Azure Certified Device program! You've now selected the appropriate certification program for your device, and are ready to get started on the portal.

-In this tutorial, you will learn how to:

-> [!div class="checklist"]

-> * Sign into the [Azure Certified Device portal](https://certify.azure.com/)

-> * Create a new certification project for your device

-> * Specify basic device details of your project

-## Prerequisites

-> [!NOTE]

-> If you're having problems setting up or validating your MPN account, see the [Partner Center Support](/partner-center) documentation.

-## Signing into the Azure Certified Device portal

-To get started, you must sign in to the portal, where you'll be providing your device information, completing certification testing, and managing your device publications to the Azure Certified Device catalog.

-1. Go to the [Azure Certified Device portal](https://certify.azure.com).

-1. Select `Company profile` on the left-hand side and update your manufacturer information.

- 

-1. Accept the program agreement to begin your project.

-## Creating your project on the portal

-Now that you're all set up in the portal, you can begin the certification process. First, you must create a project for your device.

-1. On the home screen, select `Create new project`. This will open a window to add basic device information in the next section.

- 

-## Identifying basic device information

-Then, you must supply basic device information. You can to edit this information later.

-1. Complete the fields requested under the `Basics` section. Refer to the table below for clarification regarding the **required** fields:

- | Fields | Description |

- ||-|

- | Project name | Internal name that will not be visible on the Azure Certified Device catalog |

- | Device name | Public name for your device |

- | Device type | Specification of Finished Product or Solution-Ready Developer Kit. For more information about the terminology, see [Certification glossary](./resources-glossary.md). |

- | Device class | Gateway, Sensor, or other. For more information about the terminology, see [Certification glossary](./resources-glossary.md). |

- | Device source code URL | Required if you are certifying a Solution-Ready Dev Kit, optional otherwise. URL must be to a GitHub location for your device code. |

- > [!Note]

- > If you are marketing a Microsoft service (e.g. Azure Sphere), please ensure that your device name adheres to Microsoft [branding guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks).

-1. Select the `Next` button to continue to the `Certifications` tab.

- 

-1. Specify which certification(s) you wish to achieve for your device.

-1. Select `Create` and the new project will be saved and visible in the home page of the portal.

- 

-1. Select on the Project name in the table. This will launch the project summary page where you can add and view other details about your device.

- 

-## Next steps

-You are now ready to add device details and test your device using our certification service. Advance to the next article to learn how to edit your device details.

-> [!div class="nextstepaction"]

-> [Tutorial: Adding device details](tutorial-02-adding-device-details.md)

-description: A step-by-step guide to add device details to your project on the Azure Certified Device portal

-# Tutorial: Add device details

-Now you've created your project for your device, and you're all set to begin the certification process! First, let's add your device details. These will include technical specifications that your customers will be able to view on the Azure Certified Device catalog and the marketing details that they will use to purchase once they've made a decision.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Add device details using the Components and Dependencies features

-> * Upload a Get Started guide for your device

-> * Specify marketing details for customers to purchase your device

-> * Optionally identify any industry certifications

-## Prerequisites

-* You should be signed in and have a project for your device created on the [Azure Certified Device portal](https://certify.azure.com). For more information, view the [tutorial](tutorial-01-creating-your-project.md).

-* You should have a Get Started guide for your device in PDF format. We provide many Get Started templates for you to use, depending on both the certification program and your preferred language. The templates are available at our [Get started templates](https://aka.ms/GSTemplate "Get started templates") GitHub location.

-## Adding technical device details

-The first section of your project page, called 'Input device details', allows you to provide information on the core hardware capabilities of your device, such as device name, description, processor, operating system, connectivity options, hardware interfaces, industry protocols, physical dimensions, and more. While many of the fields are optional, most of this information will be made available to potential customers on the Azure Certified Device catalog if you choose to publish your device after it has been certified.

-1. Click `Add` in the 'Input device details' section on your project summary page to open the device details section. You will see six sections for you to complete.

-

-2. Review the information you previously provided when you created the project under the `Basics` tab.

-1. Review the certifications you are applying for with your device under the `Certifications` tab.

-1. Open the `Hardware` tab and add **at least** one discrete component that describes your device. You can also view our guidance on [component usage](how-to-using-the-components-feature.md).

-1. Click `Save`. You will then be able to edit your component device and add more advanced details.

-1. Add any relevant information regarding operating conditions (such as IP rating, operating temperature, or safety certification).

-

-7. List additional device details not captured by the component details under `Additional product details`.

-1. If you marked `Other` in any of the component fields or have a special circumstance you would like to flag with the Azure Certification team, leave a clarifying comment in the `Comments for reviewer` section.

-1. Open the `Software` tab and select **at least** one operating system.

-1. (**Required for Dev Kit devices** and highly recommended for all others) Select a level to indicate the expected set-up process to connect your device to Azure. If you select Level 2, you will be required to provide a link to the available software image.

-

-11. Use the `Dependencies` tab to list any dependencies if your device requires additional hardware or services to send data to Azure. You can also view our additional guidance for [listing dependencies](how-to-indirectly-connected-devices.md).

-1. Once you are satisfied with the information you've provided, you can use the `Review` tab for a read-only overview of the full set of device details that been entered.

-1. Click `Project summary` at the top of the page to return to your summary page.

-

-## Uploading a Get Started guide

-The Get Started guide is a PDF document to simplify the setup and configuration and management of your product. Its purpose is to make it simple for customers to connect and support devices on Azure using your device. As part of the certification process, we require our partners to provide **one** Get Started guide for their most relevant certification program.

-1. Double-check that you have provided all requested information in your Get Started guide PDF according to the supplied [templates](https://aka.ms/GSTemplate). The template that you use should be determined by the certification badge you are applying for. (For example, an IoT Plug and Play device will use the IoT Plug and Play template. Devices applying for *only* the Azure Certified Device baseline certification will use the Azure Certified Device template.)

-1. Click `Add` in the 'Get Started' guide section of the project summary page.

-

-2. Click 'Choose File' to upload your PDF.

-1. Review the document in the preview for formatting.

-1. Save your upload by clicking the 'Save' button.

-1. Click `Project summary` at the top of the page to return to your summary page.

-## Providing marketing details

-In this area, you will provide customer-ready marketing information for your device. These fields will be showcased on the Azure Certified Device catalog if you choose to publish your certified device.

-1. Click `Add` in the 'Add marketing details' section to open the marketing details page.

-

-1. Upload a product photo in JPEG or PNG format that will be used in the catalog.

-1. Write a short description of your device that will be displayed on the product description page of the catalog.

-1. Indicate geographic availability of your device.

-1. Provide a link to the manufacturer's marketing page for this device. This should be a link to a site that provides additional information about the device.

- > [!Note]

- > Please ensure all supplied URLs are valid or will be active at the time of publication following approval.*)

-1. Indicate up to three target industries that your device is optimized for.

-1. Provide information for up to five distributors of your device. This may include the manufacturer's own site.

- > [!Note]

- > If no distributor product page URL is supplied, then the `Shop` button on the catalog will default to the link supplied for `Distributor page`, which may not be specific to the device. Ideally, the distributor URL should lead to a specific page where a customer can purchase a device, but is not mandatory. If the distributor is the same as the manufacturer, this URL may be the same as the manufacturer's marketing page.*)

-1. Click `Save` to confirm your information.

-1. Click `Project summary` at the top of the page to return to your summary page.

-## Declaring additional industry certifications

-You can also promote additional industry certifications you may have received for your device. These certifications can help provide further clarity on the intended use of your device and will be searchable on the Azure Certified Device catalog.

-1. Click `Add` in the 'Provide industry certifications' section.

-1. Click `Add a certification`to select from a list of the common industry certification programs. If your product has achieved a certification not in our list, you can specify a custom string value by selecting `Other (please specify)`.

-1. Optionally provide a description or notes to the reviewer. However, these notes will not be publicly available to view on the catalog.

-1. Click `Save` to confirm your information.

-1. Click `Project summary` at the top of the page to return to your summary page.

-## Next steps

-Now you have completed the process of describing your device! This will help the Azure Certified Device review team and your customer better understand your product. Once you are satisfied with the information you've provided, you are now ready to move on to the testing phase of the certification process.

-> [!div class="nextstepaction"]

-> [Tutorial: Testing your device](tutorial-03-testing-your-device.md)

-description: A step-by-step guide to test you device with AICS service on the Azure Certified Device portal

-# Tutorial: Test and submit your device

-The next major phase of the certification process (though it can be completed before adding your device details) involves testing your device. Through the portal, you'll use the Azure IoT Certification Service (AICS) to demonstrate your device performance according to our certification requirements. Once you've successfully passed the testing phase, you'll then submit your device for final review and approval by the Azure Certification team!

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Connect your device to IoT Hub using Device Provisioning Service (DPS)

-> * Test your device according to your selected certification program(s)

-> * Submit your device for review by the Azure Certification team

-## Prerequisites

-## Connecting your device using DPS

-All certified devices are required to demonstrate the ability to connect to IoT Hub using DPS. The following steps walk you through how to successfully connect your device for testing on the portal.

-1. To begin the testing phase, select the `Connect & test` link on the project summary page:

- 

-1. Depending on the certification(s) selected, you'll see the required tests on the 'Connect & test' page. Review these to ensure that you're applying for the correct certification program.

- 

-1. Connect your device to IoT Hub using the Device Provisioning Service (DPS). DPS supports connectivity options of Symmetric keys, X.509 certification, and a Trusted Platform Module (TPM). This is required for all certifications.

- - *For more information on connecting your device to Azure IoT Hub with DPS, visit [Provisioning devices overview](../iot-dps/about-iot-dps.md "Device Provisioning Service overview").*

-

-1. If using symmetric keys, you'll then be asked to configure the DPS with the supplied DPS ID scope, Device ID, authentication key, and DPS endpoint. Otherwise, you will be asked to provide either X.509 certificate or endorsement key.

-1. After configuring your device with DPS, confirm the connection by clicking the `Connect` button at the bottom of the page. Upon successful connection, you can proceed to the testing phase by clicking the `Next` button.

- 

-## Testing your device

-Once you have successfully connected your device to AICS, you are now ready to run the certification tests specific to the certification program you are applying for.

-1. **For Azure Certified Device certification**: In the 'Select device capability' tab, you will review and select which tests you wish to run on your device.

-1. **For IoT Plug and Play certification**: Carefully review the parameters that will be checked during the test that you declared in your device model.

-1. **For Edge Managed certification**: No additional steps are required beyond demonstrating connectivity.

-1. Once you have completed the necessary preparations for the specified certification program, select `Next` to proceed to the 'Test' phase.

-1. Select `Run tests` on the page to begin running AICS with your device.

-1. Once you have received a notification that you have passed the tests, select `Finish` to return to your summary page.

-

-7. If you have additional questions or need troubleshooting assistance with AICS, visit our troubleshooting guide.

-> [!NOTE]

-> While you will be able to complete the online certification process for IoT Plug and Play and Edge Managed without having to submit your device for manual review, you may be contacted by a Azure Certified Device team member for further device validation beyond what is tested through our automation service.

-## Submitting your device for review

-Once you have completed all of the mandatory fields in the 'Device details' section and successfully passed the automated testing in the 'Connect & test' process, you can now notify the Azure Certified Device team that you are ready for certification review.

-1. select `Submit for review` on the project summary page:

- 

-1. Confirm your submission in the pop-up window. Once a device has been submitted, all device details will be read-only until editing is requested. (See [How to edit your device information after publishing](./how-to-edit-published-device.md).)

- 

-1. Once the project is submitted, the project summary page will indicate the project is `Under Certification Review` by the Azure Certification team:

- 

-1. Within 5-7 business days, expect an email response from the Azure Certification team to the address provided in your company profile regarding the status of your device submission.

- - Approved submission

- Once your project has been reviewed and approved, you will receive an email. The email will include a set of files including the Azure Certified Device badge, badge usage guidelines, and other information on how to amplify the message that your device is certified. Congratulations!

- - Pending submission

- In the case your project is not approved, you will be able to make changes to the project details and then resubmit the device for certification once ready. An email will be sent with information on why the project was not approved and steps to resubmit for certification.

-## Next steps

-Congratulations! Your device has now successfully passed all of the tests and has been approved through the Azure Certified Device program. You can now publish your device to our Azure Certified Device catalog, where customers can shop for your products with confidence in their performance with Azure.

-> [!div class="nextstepaction"]

-> [Tutorial: Publishing your device](tutorial-04-publishing-your-device.md)

-description: A step-by-step guide to publish your certified device to the Azure Certified Device catalog

-# Tutorial: Publish your device

-Congratulations on successfully certifying your device! Your product is joining an ecosystem of exceptional devices that work great with Azure. Now that your device has been certified, you can optionally publish your device details to the [Azure Certified Device catalog](https://devicecatalog.azure.com) for a world of customers to discover and buy.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Publish your device to the Azure Certified Device catalog

-## Prerequisites

-## Publishing your device

-Publishing your device is a simple process that will help bring customers to your product from the Azure Certified Device catalog.

-1. To publish your device, click `Publish to Device Catalog` on the project summary page.

- 

-1. Confirm the publication in the pop-up window

- 

-1. You will receive notification to the email address in your company profile once the device has been processed the Azure Certified Device catalog.

-## Next steps

-Congratulations! Your certified device is now a part of the Azure Certified Device catalog, where customers can shop for your products with confidence in their performance with Azure! Thank you for being part of our ecosystem of certified IoT products. You will notice that your project page is now read-only. If you wish to make any updates to your device information, see our how-to guide.

-> [!div class="nextstepaction"]

-> [How to edit your published device](how-to-edit-published-device.md)

- install:

-With the ability to, connect your Azure AI services to Azure Communication Services, you can enable custom play functionality, using [Text-to-Speech](../../../../articles/cognitive-services/Speech-Service/text-to-speech.md) and [SSML](../../../../articles/cognitive-services/Speech-Service/speech-synthesis-markup.md) configuration, to play more customized and natural sounding audio to users. Through the Azure AI services connection, you can also use the Speech-To-Text service to incorporate recognition of voice responses that can be converted into actionable tasks through business logic in the application. These functions can be further enhanced through the ability to create custom models within Azure AI services that are bespoke to your domain and region, through the ability to choose which languages are spoken and recognized, custom voices and custom models built based on your experience.

-You will need to connect your Azure Communication Services resource with the Azure AI resource through the Azure portal. There are two ways you can accomplish this step:

-2. If system-assigned managed identity isn't enabled, you will need to enable it.

-The custom SIP header key must start with a mandatory ΓÇÿX-MS-Custom-ΓÇÖ prefix. The maximum length of a SIP header key is 64 chars, including the X-MS-Custom prefix. The maximum length of SIP header value is 256 chars. The same limitations apply when configuring the SIP headers on your SBC.

-For `size`, select a confidential VM size. For more information, see [supported confidential VM families](virtual-machine-solutions.md).

- i. For **Size**, select a VM size. For more information, see [supported confidential VM families](virtual-machine-solutions.md).

-The lift and shift offering uses [AMD SEV-SNP (GA)](virtual-machine-solutions.md) or [Intel TDX (preview)](tdx-confidential-vm-overview.md) to encrypt the entire memory of a VM. This allows customers to migrate their existing workloads to Azure confidential Compute without any code changes or performance degradation.

-description: Azure Confidential Computing offers multiple options for confidential virtual machines on AMD and Intel processors.

-# Azure Confidential VM options

-Azure offers multiple confidential VMs options leveraging Trusted Execution Environments (TEE) technologies from both AMD and Intel to harden the virtualization environment. These technologies enable you to provision confidential computing environments with excellent price-to-performance without code changes.

-AMD confidential VMs leverage [Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP)](https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf) which was introduced with 3rd Gen AMD EPYC™ processors. Intel confidential VMs use [Trust Domain Extensions (TDX)](https://www.intel.com/content/dam/develop/external/us/en/documents/tdx-whitepaper-v4.pdf) which was introduced with 4th Gen Intel® Xeon® processors.

-## Sizes

-You can create confidential VMs in the following size families:

-| Size Family | TEE | Description |

-| | | -- |

-| **DCasv5-series** | AMD SEV-SNP | General purpose CVM with remote storage. No local temporary disk. |

-| **DCesv5-series** | Intel TDX | General purpose CVM with remote storage. No local temporary disk. |

-| **DCadsv5-series** | AMD SEV-SNP | General purpose CVM with local temporary disk. |

-| **DCedsv5-series** | Intel TDX | General purpose CVM with local temporary disk. |

-| **ECasv5-series** | AMD SEV-SNP | Memory-optimized CVM with remote storage. No local temporary disk. |

-| **ECesv5-series** | Intel TDX | Memory-optimized CVM with remote storage. No local temporary disk. |

-| **ECadsv5-series** | AMD SEV-SNP | Memory-optimized CVM with local temporary disk. |

-| **ECedsv5-series** | Intel TDX | Memory-optimized CVM with local temporary disk. |

-> [!NOTE]

-> Memory-optimized confidential VMs offer double the ratio of memory per vCPU count.

-## Azure CLI commands

-You can use the [Azure CLI](/cli/azure/install-azure-cli) with your confidential VMs.

-To see a list of confidential VM sizes, run the following command. Replace `<vm-series>` with the series you want to use. The output shows information about available regions and availability zones.

-```azurecli-interactive

-vm_series='DCASv5'

-az vm list-skus \

- --size dc \

- --query "[?family=='standard${vm_series}Family'].{name:name,locations:locationInfo[0].location,AZ_a:locationInfo[0].zones[0],AZ_b:locationInfo[0].zones[1],AZ_c:locationInfo[0].zones[2]}" \

- --all \

- --output table

-```

-For a more detailed list, run the following command instead:

-```azurecli-interactive

-vm_series='DCASv5'

-az vm list-skus \

- --size dc \

- --query "[?family=='standard${vm_series}Family']"

-```

-## Deployment considerations

-Consider the following settings and choices before deploying confidential VMs.

-### Azure subscription

-To deploy a confidential VM instance, consider a [pay-as-you-go subscription](/azure/virtual-machines/linux/azure-hybrid-benefit-linux) or other purchase option. If you're using an [Azure free account](https://azure.microsoft.com/free/), the quota doesn't allow the appropriate number of Azure compute cores.

-You might need to increase the cores quota in your Azure subscription from the default value. Default limits vary depending on your subscription category. Your subscription might also limit the number of cores you can deploy in certain VM size families, including the confidential VM sizes.

-To request a quota increase, [open an online customer support request](../azure-portal/supportability/per-vm-quota-requests.md).

-If you have large-scale capacity needs, contact Azure Support. Azure quotas are credit limits, not capacity guarantees. You only incur charges for cores that you use.

-### Pricing

-For pricing options, see the [Linux Virtual Machines Pricing](https://azure.microsoft.com/pricing/details/virtual-machines/linux/).

-### Regional availability

-For availability information, see which [VM products are available by Azure region](https://azure.microsoft.com/global-infrastructure/services/?products=virtual-machines).

-### Resizing

-Confidential VMs run on specialized hardware, so you can only [resize confidential VM instances](confidential-vm-faq.yml#can-i-convert-a-dcasv5-ecasv5-cvm-into-a-dcesv5-ecesv5-cvm-or-a-dcesv5-ecesv5-cvm-into-a-dcasv5-ecasv5-cvm-) to other confidential sizes in the same region. For example, if you have a DCasv5-series VM, you can resize to another DCasv5-series instance or a DCesv5-series instance.

-It's not possible to resize a non-confidential VM to a confidential VM.

-### Guest Operating System Support

-OS images for confidential VMs have to meet certain security and compatibility requirements. Qualified images support the secure mounting, attestation, optional [confidential OS disk encryption](confidential-vm-overview.md#confidential-os-disk-encryption), and isolation from underlying cloud infrastructure. These images include:

-As we work to onboard more OS images with confidential OS disk encryption, there are various images available in early preview that can be tested. You can sign up below:

-For more information about supported and unsupported VM scenarios, see [support for generation 2 VMs on Azure](../virtual-machines/generation-2.md).

-### High availability and disaster recovery

-You're responsible for creating high availability and disaster recovery solutions for your confidential VMs. Planning for these scenarios helps minimize and avoid prolonged downtime.

-### Deployment with ARM templates

-Azure Resource Manager is the deployment and management service for Azure. You can:

-Make sure to specify the following properties for your VM in the parameters section (`parameters`):

-## Next steps

-> [!div class="nextstepaction"]

-> [Deploy a confidential VM from the Azure portal](quick-create-confidential-vm-portal.md)

-For more information see our [Confidential VM FAQ](confidential-vm-faq.yml).

-You can configure resiliency policies like retries and timeouts for the following outbound and inbound operation directions via a Dapr component:

-resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-08-01-preview' = {

- }

- }

-resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-08-01-preview' = {

-| SLA covers cloud platform | Yes | "Services, hardware, or software provided by a third party, such as cloud platform services on which MongoDB Atlas runs are not covered" |

-| Free tier | [1,000 request units (RUs) and 25 GB storage forever](../try-free.md). Prevents you from exceeding limits if you want | Yes, with 512 MB storage |

-You can add and remove regions to your Azure Cosmos DB account at any time. The throughput that you configure for various Azure Cosmos DB databases and containers is reserved in each region associated with your account. If the throughput provisioned per hour, that is the sum of RU/s configured across all the databases and containers for your Azure Cosmos DB account is `T` and the number of Azure regions associated with your database account is `N`, then the total provisioned throughput for your Azure Cosmos DB account, for a given hour is equal to `T x N RU/s`.

-Provisioned throughput with single write region costs $0.008/hour per 100 RU/s and provisioned throughput with multiple writable regions costs $0.016/per hour per 100 RU/s. To learn more, see Azure Cosmos DB [Pricing page](https://azure.microsoft.com/pricing/details/cosmos-db/).

-In a multi-region writes system, the net available RUs for write operations increases `N` times where `N` is the number of write regions. Unlike single region writes, every region is now writable and supports conflict resolution. From the cost planning point of view, to perform `M` RU/s worth of writes worldwide, you will need to provision M `RUs` at a container or database level. You can then add as many regions as you would like and use them for writes to perform `M` RU worth of worldwide writes.

-Consider that you have a container in West US configured for single-region writes, provisioned with throughput of 10K RU/s, storing 0.5 TB of data this month. LetΓÇÖs assume you add a region, East US, with the same storage and throughput and you want the ability to write to the containers in both the regions from your app. Your new total monthly bill (assuming 730 hours in a month) will be as follows:

-|**Item**|**Usage (monthly)**|**Rate**|**Monthly Cost**|

-|-|-|-|-|

-|Throughput bill for container in West US (single write region) |10K RU/s * 730 hours |$0.008 per 100 RU/s per hour |$584 |

-|Throughput bill for container in 2 regions - West US & East US (multiple write regions) |2 * 10K RU/s * 730 hours |$0.016 per 100 RU/s per hour |$2,336 |

-|Storage bill for container in West US |0.5 TB (or 512 GB) |$0.25/GB |$128 |

-|Storage bill for container in 2 regions - West US & East US |2 * 0.5 TB (or 1,024 GB) |$0.25/GB |$256 |

-If you have inefficient utilization, for example, one or more under-utilized read regions you can take steps to make the maximum use of the RUs in read regions by using change feed from the read-region or move it to another secondary if over-utilized. You will need to ensure you optimize provisioned throughput (RUs) in the write region first. Writes cost more than reads unless very large queries so maintaining even utilization can be challenging. Overall, monitor the consumed throughput in your regions and add or remove regions on demand to scale your read and write throughput, making to sure understand the impact to latency for any apps that are deployed in the same region.

-## Next steps

-Next you can proceed to learn more about cost optimization in Azure Cosmos DB with the following articles:

-* Learn more about [Optimizing for development and testing](optimize-dev-test.md)

-* Learn more about [Understanding your Azure Cosmos DB bill](understand-your-bill.md)

-* Learn more about [Optimizing throughput cost](optimize-cost-throughput.md)

-* Learn more about [Optimizing storage cost](optimize-cost-storage.md)

-* Learn more about [Optimizing the cost of reads and writes](optimize-cost-reads-writes.md)

-* Learn more about [Optimizing the cost of queries](./optimize-cost-reads-writes.md)

-* Trying to do capacity planning for a migration to Azure Cosmos DB? You can use information about your existing database cluster for capacity planning.

- * 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)

- * If you know typical request rates for your current database workload, read about [estimating request units using Azure Cosmos DB capacity planner](estimate-ru-with-capacity-planner.md)

-| xxxxxxxx-xxxx- xxxx - xxxx -xxxxxxxxxxx | Reservations | Purchase | 15 | 120 | 0.8 | 120 | 1 hour | 1800 | Manual calculation of the actual charge: multiply 15 \* 120 \* 1 hour. |

-> - For EA customers `PayGPrice` isn't populated when `PricingModel` = `Reservations`, `Spot`, `Marketplace`, or `SavingsPlan`.

-> - For MCA customers, `PayGPrice` isn't populated when `PricingModel` = `Reservations`, `Spot`, or `Marketplace`.

-> - For EA customers, `UnitPrice` isn't populated when `PricingModel` = `Spot`, or `MarketPlace`.

-> - For MCA customers, `UnitPrice` isn't populated when `PricingModel` = `Reservations`, `Spot`, or `SavingsPlan`.

-> Microsoft no longer updates the Azure Enterprise Reporting APIs. Instead, you should use Cost Management APIs. To learn more, see [Migrate from Azure Enterprise Reporting to Microsoft Cost Management APIs overview](../automate/migrate-ea-reporting-arm-apis-overview.md).

-If you're exchanging for a different size, series, region or payment frequency, the term is reset for the new reservation.

-For customers that pay by credit card, the refunded amount is returned to the credit card that was used for the original purchase. If you've changed your card, [contact support](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest).

-The original reservation purchase invoice is canceled and then a new invoice is created for the refund. For exchanges, the new invoice shows the refund and the new purchase. The refund amount is adjusted against the purchase. If you only refunded a reservation, then the prorated amount stays with Microsoft and it's adjusted against a future reservation purchase. If you bought a reservation at pay-as-you-go rates and later move to a CSP, the reservation can be returned and repurchased without a penalty.

-The original invoice is canceled, and a new invoice is created. The money is refunded to the credit card that was used for the original purchase. If you've changed your card, [contact support](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest).

- - [Understand reservation usage for your Pay-As-You-Go subscription](understand-reserved-instance-usage.md)

- - Partner Center Action Center emails are sent to partners. For more information about how partners can update their transactional notifications, see [Action Center preferences](/partner-center/action-center-overview#preferences).

-4. On the given resource, go to **Networking** -> **Private endpoint connection** to approve it. The private endpoint is named as `data_factory_name.your_defined_private_endpoint_name` with description as "Requested by data_factory_name".

-description: This article shows you how to make a custom tenant and billing profile for educators in your organization

-This article is meant for IT Admins utilizing Azure for Classroom. When signing up for this offer, you should already have a tenant and billing profile created, but this article is meant to help walk you through how to create a custom tenant and billing profile and associate them with an educator.

-This section walks you through how to create a new tenant and associate it with your university tenant using multi-tenant

-4. After the tenant has been created copy the Tenant ID of the new tenant

-2. After the Educator has joined the tenant, go into the tenant properties and click Yes under the Access management for Azure resources.

-For more information, see quotas and limits for [namespaces](quotas-limits.md#namespace-resource-limits).

-| ThrottleType | The type of throttle limit that got exceeded in the namespace. The available values include: <br>- InboundBandwidthPerNamespace <br>- InboundBandwidthPerConnection <br>- IncomingPublishPacketsPerNamespace <br>- IncomingPublishPacketsPerConnection <br>- OutboundPublishPacketsPerNamespace <br>- OutboundPublishPacketsPerConnection <br>- OutboundBandwidthPerNamespace <br>- OutboundBandwidthPerConnection <br>- SubscribeOperationsPerNamespace <br>- SubscribeOperationsPerConnection <br>- ConnectPacketsPerNamespace <br><br>[Learn more about the limits](quotas-limits.md#mqtt-limits-in-namespace). |

-description: In this quickstart, you use Azure CLI to create an Azure Policy assignment to identify non-compliant resources.

-# Quickstart: Create a policy assignment to identify non-compliant resources with Azure CLI

-The first step in understanding compliance in Azure is to identify the status of your resources.

-This quickstart steps you through the process of creating a policy assignment to identify virtual

-machines that aren't using managed disks.

-At the end of this process, you'll successfully identify virtual machines that aren't using managed

-disks. They're _non-compliant_ with the policy assignment.

-Azure CLI is used to create and manage Azure resources from the command line or in scripts. This

-guide uses Azure CLI to create a policy assignment and to identify non-compliant resources in your

-Azure environment.

- account before you begin.

- `az --version`. If you need to install or upgrade, see

- [Install Azure CLI](/cli/azure/install-azure-cli).

- provider makes sure that your subscription works with it. To register a resource provider, you

- must have permission to the register resource provider operation. This operation is included in

- the Contributor and Owner roles. Run the following command to register the resource provider:

- ```azurecli-interactive

- az provider register --namespace 'Microsoft.PolicyInsights'

- ```

- For more information about registering and viewing resource providers, see

- [Resource Providers and Types](../../azure-resource-manager/management/resource-providers-and-types.md)

- tool that sends HTTP requests to Azure Resource Manager-based APIs.

-## Create a policy assignment

-In this quickstart, you create a policy assignment and assign the **Audit VMs that do not use

-managed disks** definition. This policy definition identifies resources that aren't compliant to the

-conditions set in the policy definition.

-Run the following command to create a policy assignment:

-```azurecli-interactive

-az policy assignment create --name 'audit-vm-manageddisks' --display-name 'Audit VMs without managed disks Assignment' --scope '<scope>' --policy '<policy definition ID>'

-The preceding command uses the following information:

- without managed disks Assignment_.

- this case, it's the ID of policy definition _Audit VMs that do not use managed disks_. To get the

- policy definition ID, run this command:

- `az policy definition list --query "[?displayName=='Audit VMs that do not use managed disks']"`

- enforced on. It could range from a subscription to resource groups. Be sure to replace

- &lt;scope&gt; with the name of your resource group.

-## Identify non-compliant resources

-To view the resources that aren't compliant under this new assignment, get the policy assignment ID

-by running the following commands:

-```azurecli-interactive

-az policy assignment list --query "[?displayName=='Audit VMs without managed disks Assignment'].id"

-For more information about policy assignment IDs, see

-[az policy assignment](/cli/azure/policy/assignment).

-Next, run the following command to get the resource IDs of the non-compliant resources that are

-output into a JSON file:

-```console

-armclient post "/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.PolicyInsights/policyStates/latest/queryResults?api-version=2019-10-01&$filter=IsCompliant eq false and PolicyAssignmentId eq '<policyAssignmentID>'&$apply=groupby((ResourceId))" > <json file to direct the output with the resource IDs into>

-Your results resemble the following example:

-```json

-{

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest",

- "@odata.count": 3,

- "value": [{

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "ResourceId": "/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtualmachineId>"

- },

- {

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "ResourceId": "/subscriptions/<subscriptionId>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtualmachine2Id>"

- },

- {

- "@odata.id": null,

- "@odata.context": "https://management.azure.com/subscriptions/<subscriptionId>/providers/Microsoft.PolicyInsights/policyStates/$metadata#latest/$entity",

- "ResourceId": "/subscriptions/<subscriptionName>/resourcegroups/<rgname>/providers/microsoft.compute/virtualmachines/<virtualmachine3ID>"

- }

- ]

-}

-The results are comparable to what you'd typically see listed under **Non-compliant resources** in

-the Azure portal view.

-To remove the assignment created, use the following command:

-```azurecli-interactive

-az policy assignment delete --name 'audit-vm-manageddisks' --scope '/subscriptions/<subscriptionID>/<resourceGroupName>'

-To learn more about assigning policies to validate that new resources are compliant, continue to the

-tutorial for:

-> [Creating and managing policies](./tutorials/create-and-manage.md)

-|[Azure Databricks Workspaces should disable public network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0e7849de-b939-4c50-ab48-fc6b0f5eeba2) |Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. Learn more at: [https://learn.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/private-link](/azure/databricks/administration-guide/cloud-configurations/azure/private-link). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Databricks/Databricks_AuditPublicNetworkAccess.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Machines should be configured to periodically check for missing system updates](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fbd876905-5b84-4f73-ab2d-2e7a7c4568d9) |To ensure periodic assessments for missing system updates are triggered automatically every 24 hours, the AssessmentMode property should be set to 'AutomaticByPlatform'. Learn more about AssessmentMode property for Windows: [https://aka.ms/computevm-windowspatchassessmentmode,](https://aka.ms/computevm-windowspatchassessmentmode,) for Linux: [https://aka.ms/computevm-linuxpatchassessmentmode](https://aka.ms/computevm-linuxpatchassessmentmode). |Audit, Deny, Disabled |[3.5.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Update%20Manager/AzUpdateMgmtCenter_AutoAssessmentMode_Audit.json) |

-### Flaw Remediation

-**ID**: CCCS SI-2

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Machines should be configured to periodically check for missing system updates](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fbd876905-5b84-4f73-ab2d-2e7a7c4568d9) |To ensure periodic assessments for missing system updates are triggered automatically every 24 hours, the AssessmentMode property should be set to 'AutomaticByPlatform'. Learn more about AssessmentMode property for Windows: [https://aka.ms/computevm-windowspatchassessmentmode,](https://aka.ms/computevm-windowspatchassessmentmode,) for Linux: [https://aka.ms/computevm-linuxpatchassessmentmode](https://aka.ms/computevm-linuxpatchassessmentmode). |Audit, Deny, Disabled |[3.5.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Update%20Manager/AzUpdateMgmtCenter_AutoAssessmentMode_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[\[Preview\]: Azure Key Vault should use RBAC permission model](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F12d4fa5e-1f9f-4c21-97a9-b99b3c6611b5) |Enable RBAC permission model across Key Vaults. Learn more at: [https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-migration](../../../key-vault/general/rbac-migration.md) |Audit, Deny, Disabled |[1.0.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVault_Should_Use_RBAC.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### Permitted Actions Without Identification Or

-Authentication

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### Audit And Accountability Policy And

-Procedures

-### Security Assessment And Authorization

-Policy And Procedures

-### Identification And Authentication

-(Organizational Users)

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Azure Databricks Workspaces should disable public network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0e7849de-b939-4c50-ab48-fc6b0f5eeba2) |Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. Learn more at: [https://learn.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/private-link](/azure/databricks/administration-guide/cloud-configurations/azure/private-link). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Databricks/Databricks_AuditPublicNetworkAccess.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### Identification And Authentication

-(Organizational Users)

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-|[Azure Databricks Workspaces should disable public network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0e7849de-b939-4c50-ab48-fc6b0f5eeba2) |Disabling public network access improves security by ensuring that the resource isn't exposed on the public internet. You can control exposure of your resources by creating private endpoints instead. Learn more at: [https://learn.microsoft.com/azure/databricks/administration-guide/cloud-configurations/azure/private-link](/azure/databricks/administration-guide/cloud-configurations/azure/private-link). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Databricks/Databricks_AuditPublicNetworkAccess.json) |

-|[Disk access resources should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff39f5f49-4abf-44de-8c70-0756997bfb51) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The Private Link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to diskAccesses, data leakage risks are reduced. Learn more about private links at: [https://aka.ms/disksprivatelinksdoc](https://aka.ms/disksprivatelinksdoc). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/DiskAccesses_PrivateEndpoints_Audit.json) |

-### PCI DSS requirement 1.3.4

-**ID**: PCI DSS v3.2.1 1.3.4

-**Ownership**: customer

-|Name<br />_{(Azure portal)} |Description |Effect(s) |Version<br />_(GitHub) |

-|||||

-|[Audit diagnostic setting for selected resource types](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F7f89b1eb-583c-429a-8828-af049802c1d9) |Audit diagnostic setting for selected resource types. Be sure to select only resource types which support diagnostics settings. |AuditIfNotExists |[2.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/DiagnosticSettingsForTypes_Audit.json) |

-|[Auditing on SQL server should be enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fa6fb4358-5bf4-4ad7-ba82-2cd2f41ce5e9) |Auditing on your SQL Server should be enabled to track database activities across all databases on the server and save them in an audit log. |AuditIfNotExists, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SQL/SqlServerAuditing_Audit.json) |

-|[Storage accounts should be migrated to new Azure Resource Manager resources](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F37e0d2fe-28a5-43d6-a273-67d37d1f5606) |Use new Azure Resource Manager for your storage accounts to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Storage/Classic_AuditForClassicStorages_Audit.json) |

-|[Virtual machines should be migrated to new Azure Resource Manager resources](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1d84d5fb-01f6-4d12-ba4f-4a26081d403d) |Use new Azure Resource Manager for your virtual machines to provide security enhancements such as: stronger access control (RBAC), better auditing, Azure Resource Manager based deployment and governance, access to managed identities, access to key vault for secrets, Azure AD-based authentication and support for tags and resource groups for easier security management |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Compute/ClassicCompute_Audit.json) |

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-**ID**:

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[\[Preview\]: Certificates should have the specified maximum validity period](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0a075868-4c26-42ef-914c-5bc007359560) |Manage your organizational compliance requirements by specifying the maximum amount of time that a certificate can be valid within your key vault. |audit, Audit, deny, Deny, disabled, Disabled |[2.2.0-preview](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/Certificates_ValidityPeriod.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-|[Storage account containing the container with activity logs must be encrypted with BYOK](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffbb99e8e-e444-4da0-9ff1-75c92f5a85b2) |This policy audits if the Storage account containing the container with activity logs is encrypted with BYOK. The policy works only if the storage account lies on the same subscription as activity logs by design. More information on Azure Storage encryption at rest can be found here [https://aka.ms/azurestoragebyok](https://aka.ms/azurestoragebyok). |AuditIfNotExists, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/ActivityLog_StorageAccountBYOK_Audit.json) |

-### Business continuity is ensured through a documented plan communicated to the potentially affected

-parties (service bureau and customers).

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

-## Connect Resource Graph with Power BI connector

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

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

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

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

-## Related content

-> * Create domain users

-> * Create Ranger policies

-> * Create tables in an HBase cluster

-> * Test Ranger policies

-* Create a [HDInsight HBase cluster with Enterprise Security Package](apache-domain-joined-configure-using-azure-adds.md).

-1. From a browser, connect to the Ranger Admin user interface using the URL `https://<ClusterName>.azurehdinsight.net/Ranger/`. Remember to change `<ClusterName>` to the name of your HBase cluster.

- > [!NOTE]

- > Ranger credentials are not the same as Hadoop cluster credentials. To prevent browsers from using cached Hadoop credentials, use a new InPrivate browser window to connect to the Ranger Admin UI.

-2. Sign in using your Microsoft Entra admin credentials. The Microsoft Entra admin credentials aren't the same as HDInsight cluster credentials or Linux HDInsight node SSH credentials.

-Visit [Create a HDInsight cluster with Enterprise Security Package](./apache-domain-joined-configure-using-azure-adds.md), to learn how to create the **sales_user1** and **marketing_user1** domain users. In a production scenario, domain users come from your Active Directory tenant.

-### To use the HBase shell

-2. Create an HBase table `Customers` with two-column families: `Name` and `Contact`.

-3. Insert some data:

-4. View the contents of the table:

- :::image type="content" source="./media/apache-domain-joined-run-hbase/hbase-shell-scan-table.png" alt-text="HDInsight Hadoop HBase shell output" border="true":::

-1. Open the **Ranger Admin UI**. Click **\<ClusterName>_hbase** under **HBase**.

- :::image type="content" source="./media/apache-domain-joined-run-hbase/apache-ranger-admin-login.png" alt-text="HDInsight Apache Ranger Admin UI" border="true":::

-2. The **List of Policies** screen will display all Ranger policies created for this cluster. One pre-configured policy may be listed. Click **Add New Policy**.

- :::image type="content" source="./media/apache-domain-joined-run-hbase/apache-ranger-hbase-policies-list.png" alt-text="Apache Ranger HBase policies list" border="true":::

-3. On the **Create Policy** screen, enter the following values:

- |**Setting** |**Suggested value** |

- :::image type="content" source="./media/apache-domain-joined-run-hbase/apache-ranger-hbase-policy-create-sales.png" alt-text="Apache Ranger policy create sales" border="true":::

- >Wait a few moments for Ranger to sync with Microsoft Entra ID if a domain user is not automatically populated for **Select User**.

-4. Click **Add** to save the policy.

-5. Click **Add New Policy** and then enter the following values:

- |**Setting** |**Suggested value** |

- :::image type="content" source="./media/apache-domain-joined-run-hbase/apache-ranger-hbase-policy-create-marketing.png" alt-text="Apache Ranger policy create marketing" border="true":::

-6. Click **Add** to save the policy.

-Based on the Ranger policies configured, **sales_user1** can view all of the data for the columns in both the `Name` and `Contact` column families. The **marketing_user1** can only view data in the `Contact` column family.

-1. Use the kinit command to change to the context of our desired user.

-2. Open the HBase shell and scan the table `Customers`.

-3. Notice that the sales user can view all columns of the `Customers` table including the two columns in the `Name` column-family, as well as the five columns in the `Contact` column-family.

-1. Use the kinit command to change to the context of our desired user

- :::image type="content" source="./media/apache-domain-joined-run-hbase/apache-ranger-admin-audit.png" alt-text="HDInsight Ranger UI Policy Audit" border="true":::

-If you're not going to continue to use this application, delete the HBase cluster that you created with the following steps:

-2. In the **Search** box at the top, type **HDInsight**.

-1. Select **HDInsight clusters** under **Services**.

-1. In the list of HDInsight clusters that appears, click the **...** next to the cluster that you created for this tutorial.

-1. Click **Delete**. Click **Yes**.

-Learn how to configure Apache Ranger policies for Apache Hive. In this article, you create two Ranger policies to restrict access to the hivesampletable. The hivesampletable comes with HDInsight clusters. After you've configured the policies, you use Excel and ODBC driver to connect to Hive tables in HDInsight.

-* A HDInsight cluster with Enterprise Security Package. See [Configure HDInsight clusters with ESP](./apache-domain-joined-configure-using-azure-adds.md).

-## Connect to Apache Ranger Admin UI

-**To connect to Ranger Admin UI**

-1. From a browser, navigate to the Ranger Admin UI at `https://CLUSTERNAME.azurehdinsight.net/Ranger/` where CLUSTERNAME is the name of your cluster.

- > [!NOTE]

- > Ranger uses different credentials than Apache Hadoop cluster. To prevent browsers using cached Hadoop credentials, use new InPrivate browser window to connect to the Ranger Admin UI.

-2. Log in using the cluster administrator domain user name and password:

- :::image type="content" source="./media/apache-domain-joined-run-hive/hdinsight-domain-joined-ranger-home-page.png" alt-text="HDInsight ESP Ranger home page" border="true":::

-## Create Domain users

-See [Create a HDInsight cluster with ESP](apache-domain-joined-configure-using-azure-adds.md#create-an-hdinsight-cluster-with-esp), for information on how to create hiveruser1 and hiveuser2. You use the two user accounts in this article.

-In this section, you create two Ranger policies for accessing hivesampletable. You give select permission on different set of columns. Both users were created using [Create a HDInsight cluster with ESP](apache-domain-joined-configure-using-azure-adds.md#create-an-hdinsight-cluster-with-esp). In the next section, you'll test the two policies in Excel.

-**To create Ranger policies**

-1. Open Ranger Admin UI. See Connect to Apache Ranger Admin UI.

-2. Select **CLUSTERNAME_Hive**, under **Hive**. You shall see two pre-configure policies.

-3. Select **Add New Policy**, and then enter the following values:

- :::image type="content" source="./media/apache-domain-joined-run-hive/hdinsight-domain-joined-configure-ranger-policy.png" alt-text="HDInsight ESP Ranger Hive policies configure" border="true":::.

- > [!NOTE]

- > If a domain user is not populated in Select User, wait a few moments for Ranger to sync with AAD.

-4. Select **Add** to save the policy.

-5. Repeat the last two steps to create another policy with the following properties:

-## Create Hive ODBC data source

-The instructions can be found in [Create Hive ODBC data source](../hadoop/apache-hadoop-connect-excel-hive-odbc-driver.md).

- | Data Source Name | Give a name to your data source |

- | Host | Enter CLUSTERNAME.azurehdinsight.net. For example, myHDICluster.azurehdinsight.net |

- | Port | Use **443**. (This port has been changed from 563 to 443.) |

- | Hive Server Type | Select **Hive Server 2** |

- | Mechanism | Select **Azure HDInsight Service** |

- | User Name | Enter hiveuser1@contoso158.onmicrosoft.com. Update the domain name if it's different. |

- | Password | Enter the password for hiveuser1. |

-Make sure to click **Test** before saving the data source.

-In the last section, you've configured two policies. hiveuser1 has the select permission on all the columns, and hiveuser2 has the select permission on two columns. In this section, you impersonate the two users to import data into Excel.

-1. From the **Data** tab, navigate to **Get Data** > **From Other Sources** > **From ODBC** to launch the **From ODBC** window.

- :::image type="content" source="./media/apache-domain-joined-run-hive/simbahiveodbc-excel-dataconnection1.png" alt-text="Open data connection wizard" border="true":::

-1. From the drop-down list, select the data source name that you created in the last section and then select **OK**.

-1. For the first use, an **ODBC driver** dialog will open. Select **Windows** from the left menu. Then select **Connect** to open the **Navigator** window.

-1. Wait for the **Select Database and Table** dialog to open. This can take a few seconds.

-1. Select **hivesampletable**, and then select **Next**.

-1. In the **Import Data** dialog, you can change or specify the query. To do so, select **Properties**. This can take a few seconds.

- By the Ranger policies you defined, hiveuser1 has select permission on all the columns. So this query works with hiveuser1's credentials, but this query doesn't work with hiveuser2's credentials.

-1. Select **OK** to close the Connection Properties dialog.

-1. Select **OK** to close the **Import Data** dialog.

-1. Reenter the password for hiveuser1, and then click **OK**. It takes a few seconds before data gets imported to Excel. When it's done, you shall see 11 columns of data.

-To test the second policy (read-hivesampletable-devicemake), you created in the last section

-2. Follow the last procedure to import the data. The only change you make is to use hiveuser2's credentials instead of hiveuser1's. This fails because hiveuser2 only has permission to see two columns. You shall get the following error:

-3. Follow the same procedure to import data. This time, use hiveuser2's credentials, and also modify the select statement from:

- to:

- When it's done, you shall see two columns of data imported.

-* For configuring a HDInsight cluster with Enterprise Security Package, see [Configure HDInsight clusters with ESP](./apache-domain-joined-configure-using-azure-adds.md).

-* For managing a HDInsight cluster with ESP, see [Manage HDInsight clusters with ESP](apache-domain-joined-manage.md).

-* For running Hive queries using SSH on HDInsight clusters with ESP, see [Use SSH with HDInsight](../hdinsight-hadoop-linux-use-ssh-unix.md#authentication-domain-joined-hdinsight).

-* For Connecting Hive using Hive JDBC, see [Connect to Apache Hive on Azure HDInsight using the Hive JDBC driver](../hadoop/apache-hadoop-connect-hive-jdbc-driver.md)

-* For connecting Excel to Hadoop using Hive ODBC, see [Connect Excel to Apache Hadoop with the Microsoft Hive ODBC drive](../hadoop/apache-hadoop-connect-excel-hive-odbc-driver.md)

-* For connecting Excel to Hadoop using Power Query, see [Connect Excel to Apache Hadoop by using Power Query](../hadoop/apache-hadoop-connect-excel-power-query.md)

-> * Create domain users

-> * Create Ranger policies

-> * Create topics in a Kafka cluster

-> * Test Ranger policies

-A [HDInsight Kafka cluster with Enterprise Security Package](./apache-domain-joined-configure-using-azure-adds.md).

-1. From a browser, connect to the Ranger Admin user interface using the URL `https://ClusterName.azurehdinsight.net/Ranger/`. Remember to change `ClusterName` to the name of your Kafka cluster. Ranger credentials are not the same as Hadoop cluster credentials. To prevent browsers from using cached Hadoop credentials, use a new InPrivate browser window to connect to the Ranger Admin UI.

-2. Sign in using your Microsoft Entra admin credentials. The Microsoft Entra admin credentials aren't the same as HDInsight cluster credentials or Linux HDInsight node SSH credentials.

- :::image type="content" source="./media/apache-domain-joined-run-kafka/apache-ranger-admin-login.png" alt-text="HDInsight Apache Ranger Admin UI" border="true":::

-Visit [Create a HDInsight cluster with Enterprise Security Package](./apache-domain-joined-configure-using-azure-adds.md), to learn how to create the **sales_user** and **marketing_user** domain users. In a production scenario, domain users come from your Active Directory tenant.

-## Create Ranger policy

-2. Select **\<ClusterName>_kafka** under **Kafka**. One pre-configured policy may be listed.

-3. Select **Add New Policy** and enter the following values:

- * ΓÇÖ*ΓÇÖ indicates zero or more occurrences of characters.

- * ΓÇÖ?ΓÇÿ indicates single character.

- :::image type="content" source="./media/apache-domain-joined-run-kafka/apache-ranger-admin-create-policy.png" alt-text="Apache Ranger Admin UI Create Policy1" border="true":::

- Wait a few moments for Ranger to sync with Microsoft Entra ID if a domain user is not automatically populated for **Select User**.

-4. Select **Add** to save the policy.

-5. Select **Add New Policy** and then enter the following values:

- :::image type="content" source="./media/apache-domain-joined-run-kafka/apache-ranger-admin-create-policy-2.png" alt-text="Apache Ranger Admin UI Create Policy2" border="true":::

-6. Select **Add** to save the policy.

-1. Use the following command to open an SSH connection to the cluster:

- Replace `DOMAINADMIN` with the admin user for your cluster configured during [cluster creation](./apache-domain-joined-configure-using-azure-adds.md#create-an-hdinsight-cluster-with-esp), and replace `CLUSTERNAME` with the name of your cluster. If prompted, enter the password for the admin user account. For more information on using `SSH` with HDInsight, see [Use SSH with HDInsight](../../hdinsight/hdinsight-hadoop-linux-use-ssh-unix.md).

-2. Use the following commands to save the cluster name to a variable and install a JSON parsing utility `jq`. When prompted, enter the Kafka cluster name.

-3. Use the following commands to get the Kafka broker hosts. When prompted, enter the password for the cluster admin account.

- Before proceeding, you may need to set up your development environment if you have not already done so. You will need components such as the Java JDK, Apache Maven, and an SSH client with scp. For more information, see [setup instructions](https://github.com/Azure-Samples/hdinsight-kafka-java-get-started/tree/master/DomainJoined-Producer-Consumer).

-1. Follow Steps 2 and 3 under **Build and deploy the example** in [Tutorial: Use the Apache Kafka Producer and Consumer APIs](../kafk#build-and-deploy-the-example)

- > [!NOTE]

- > For this tutorial, please use the kafka-producer-consumer.jar under "DomainJoined-Producer-Consumer" project (not the one under Producer-Consumer project, which is for non domain joined scenarios).

-Based on the Ranger policies configured, **sales_user** can produce/consume topic `salesevents` but not topic `marketingspend`. Conversely, **marketing_user** can produce/consume topic `marketingspend` but not topic `salesevents`.

-2. Use the broker names from the previous section to set the following environment variable:

-3. Follow Step 3 under **Build and deploy the example** in [Tutorial: Use the Apache Kafka Producer and Consumer APIs](../kafk#build-and-deploy-the-example) to ensure that the `kafka-producer-consumer.jar` is also available to **sales_user**.

- > [!NOTE]

- > For this tutorial, please use the kafka-producer-consumer.jar under "DomainJoined-Producer-Consumer" project (not the one under Producer-Consumer project, which is for non domain joined scenarios).

-4. Verify that **sales_user1** can produce to topic `salesevents` by executing the following command:

-5. Execute the following command to consume from topic `salesevents`:

- Verify that you're able to read the messages.

-6. Verify that the **sales_user1** can't produce to topic `marketingspend` by executing the following in the same ssh window:

-7. Notice that **marketing_user1** can't consume from topic `salesevents`.

- Repeat steps 1-3 above, but this time as **marketing_user1**.

- Execute the following command to consume from topic `salesevents`:

-8. View the audit access events from the Ranger UI.

- :::image type="content" source="./media/apache-domain-joined-run-kafka/apache-ranger-admin-audit.png" alt-text="Ranger UI policy audit access events " border="true":::

-

-2. Set environment variables:

-3. Produce messages to topic `salesevents`:

-4. Consume messages from topic `salesevents`:

-## Produce and consume topics for long running session in ESP Kafka

-Kerberos ticket cache has an expiration limitation. For long running session, we'd better to use keytab instead of renewing ticket cache manually.

-To use keytab in long running session without `kinit`:

-1. Create a new keytab for your domain user

-2. Create `/home/sshuser/kafka_client_jaas.conf` and it should have the following lines:

-3. Replace `java.security.auth.login.config` with `/home/sshuser/kafka_client_jaas.conf` and produce or consume topic using console or API

-If you're not going to continue to use this application, delete the Kafka cluster that you created with the following steps:

-1. In the **Search** box at the top, type **HDInsight**.

-1. Select **HDInsight clusters** under **Services**.

-1. In the list of HDInsight clusters that appears, click the **...** next to the cluster that you created for this tutorial.

-1. Click **Delete**. Click **Yes**.

-If kafka-producer-consumer.jar does not work in a domain joined cluster, please make sure you are using the kafka-producer-consumer.jar under "DomainJoined-Producer-Consumer" project (not the one under Producer-Consumer project, which is for non domain joined scenarios).

-| Spark | [Conda version regression in a recent HDInsight release](#conda-version-regression-in-a-recent-hdinsight-release)|

-### Conda version regression in a recent HDInsight release

-**Issue published date**: October 13, 2023

-In the latest Azure HDInsight release, the conda version was mistakenly downgraded to 4.2.9. This regression is fixed in an upcoming release, but currently it can affect Spark job execution and result in script action failures. Conda 4.3.30 is the expected version in 5.0 and 5.1 clusters, so follow the steps to mitigate the issue.

-#### Recommended steps

-1. Use Secure Shell (SSH) to connect to any virtual machine (VM) in the cluster.

-2. Switch to the root user: `sudo su`.

-3. Check the conda version: `/usr/bin/anaconda/bin/conda info`.

-4. If the version is 4.2.9, run the following [script action](/azure/hdinsight/hdinsight-hadoop-customize-cluster-linux#script-action-to-a-running-cluster) on all nodes to upgrade the cluster to conda version 4.3.30:

- `https://hdiconfigactions2.blob.core.windows.net/hdi-sre-workspace/conda_update_4_3_30_patch.sh`

-#### Resources

-|Not applicable|Not applicable|Not applicable|Not applicable|Not applicable|

-description: This article describes how to configure Ranger policies for Spark SQL with Enterprise security package.

-# Configure Apache Ranger policies for Spark SQL in HDInsight with Enterprise security package

-This article describes how to configure Ranger policies for Spark SQL with Enterprise security package in HDInsight.

-In this tutorial, you'll learn how to,

-## Prerequisites

-An Apache Spark cluster in HDInsight version 5.1 with [Enterprise security package](../domain-joined/apache-domain-joined-configure-using-azure-adds.md).

-## Connect to Apache Ranger Admin UI

-1. From a browser, connect to the Ranger Admin user interface using the URL `https://ClusterName.azurehdinsight.net/Ranger/`.

- Remember to change `ClusterName` to the name of your Spark cluster.

-

-1. Sign in using your Microsoft Entra admin credentials. The Microsoft Entra admin credentials aren't the same as HDInsight cluster credentials or Linux HDInsight node SSH credentials.

- :::image type="content" source="./media/ranger-policies-for-spark/ranger-spark.png" alt-text="Screenshot shows the create alert notification dialog box." lightbox="./media/ranger-policies-for-spark/ranger-spark.png":::

-## Create Domain users

-See [Create an HDInsight cluster with ESP](../domain-joined/apache-domain-joined-configure-using-azure-adds.md#create-an-hdinsight-cluster-with-esp), for information on how to create **sparkuser** domain users. In a production scenario, domain users come from your Active Directory tenant.

-## Create Ranger policy

-In this section, you create two Ranger policies;

-### Create Ranger Access policies

-1. Open Ranger Admin UI.

-1. Select **hive_and_spark**, under **Hadoop SQL**.

- :::image type="content" source="./media/ranger-policies-for-spark/ranger-spark.png" alt-text="Screenshot shows select hive and spark." lightbox="./media/ranger-policies-for-spark/ranger-spark.png":::

-1. Select **Add New Policy** under **Access** tab, and then enter the following values:

- :::image type="content" source="./media/ranger-policies-for-spark/add-new-policy-screenshot.png" alt-text="Screenshot shows select hive." lightbox="./media/ranger-policies-for-spark/add-new-policy-screenshot.png":::

- | Property | Value |

- |||

- | Policy Name | read-hivesampletable-all |

- | Hive Database | default |

- | table | hivesampletable |

- | Hive Column | * |

- | Select User | sparkuser |

- | Permissions | select |

- :::image type="content" source="./media/ranger-policies-for-spark/sample-policy-details.png" alt-text="Screenshot shows sample policy details." lightbox="./media/ranger-policies-for-spark/sample-policy-details.png":::

- Wait a few moments for Ranger to sync with Microsoft Entra ID if a domain user is not automatically populated for Select User.

-1. Select **Add** to save the policy.

-1. Open Zeppelin notebook and run the following command to verify the policy.

-

- Result before policy was saved:

-

- :::image type="content" source="./media/ranger-policies-for-spark/result-before-access-policy.png" alt-text="Screenshot shows result before access policy." lightbox="./media/ranger-policies-for-spark/result-before-access-policy.png":::

- Result after policy is applied:

- :::image type="content" source="./media/ranger-policies-for-spark/result-after-access-policy.png" alt-text="Screenshot shows result after access policy." lightbox="./media/ranger-policies-for-spark/result-after-access-policy.png":::

-#### Create Ranger masking policy

-

-The following example explains how to create a policy to mask a column.

-1. Create another policy under **Masking** tab with the following properties using Ranger Admin UI

- :::image type="content" source="./media/ranger-policies-for-spark/add-new-masking-policy-screenshot.png" alt-text="Screenshot shows add new masking policy screenshot." lightbox="./media/ranger-policies-for-spark/add-new-masking-policy-screenshot.png":::

-

- |Property |Value |

- |||

- |Policy Name| mask-hivesampletable |

- |Hive Database|default|

- |Hive table| hivesampletable|

- |Hive column|devicemake|

- |Select User|sparkuser|

- |Permissions|select|

- |Masking options|hash|

-

- :::image type="content" source="./media/ranger-policies-for-spark/masking-policy-details.png" alt-text="Screenshot shows masking policy details." lightbox="./media/ranger-policies-for-spark/masking-policy-details.png":::

-

-1. Select **Save** to save the policy.

-1. Open Zeppelin notebook and run the following command to verify the policy.

- ```

- :::image type="content" source="./media/ranger-policies-for-spark/open-zipline-notebook.png" alt-text="Screenshot shows open zeppelin notebook." lightbox="./media/ranger-policies-for-spark/open-zipline-notebook.png":::

-

-> [!NOTE]

-> By default, the policies for hive and spark-sql will be common in Ranger.

-

-## Guideline for setting up Apache Ranger for Spark-sql

-

-**Scenario 1**: Using new Ranger database while creating HDInsight 5.1 Spark cluster.

-

-When the cluster is created, the relevant Ranger repo containing the Hive and Spark Ranger policies are created under the name <hive_and_spark> in the Hadoop SQL service on the Ranger DB.

-

-

-You can edit the policies and these policies gets applied to both Hive and Spark.

-

-Points to consider:

-1. In case you have two metastore databases with the same name used for both hive (for example, DB1) and spark (for example, DB1) catalogs.

- - If spark uses spark catalog (metastore.catalog.default=spark), the policy applies to the DB1 of the spark catalog.

- - If spark uses hive catalog (metastore.catalog.default=hive), the policies get applied to the DB1 of the hive catalog.

-

- There is no way of differentiating between DB1 of hive and spark catalog from the perspective of Ranger.

-

-

- In such cases, it is recommended to either use ΓÇÿhiveΓÇÖ catalog for both Hive and Spark or maintain different database, table and column names for both Hive and Spark catalogs so that the policies are not applied to databases across catalogs.

-

-1. In case you use ΓÇÿhiveΓÇÖ catalog for both Hive and Spark.

- LetΓÇÖs say you create a table **table1** through Hive with current ΓÇÿxyzΓÇÖ user. It creates an HDFS file called **table1.db** whose owner is ΓÇÿxyzΓÇÖ user.

-

- - Now consider, the user ΓÇÿabcΓÇÖ is used while launching the Spark Sql session. In this session of user ΓÇÿabcΓÇÖ, if you try to write anything to **table1**, it is bound to fail since the table owner is ΓÇÿxyzΓÇÖ.

- - In such case, it is recommended to use the same user in Hive and Spark SQL for updating the table and that user should have sufficient privileges to perform update operations.

-**Scenario 2**: Using existing Ranger database (with existing policies) while creating HDInsight 5.1 Spark cluster.

- - In this case when the HDI 5.1 cluster is created using existing Ranger database then, new Ranger repo gets created again on this database with the name of the new cluster in this format - <hive_and_spark>.

- :::image type="content" source="./media/ranger-policies-for-spark/new-repo-old-ranger-database.png" alt-text="Screenshot shows new repo old ranger database." lightbox="./media/ranger-policies-for-spark/new-repo-old-ranger-database.png":::

- LetΓÇÖs say you have the policies defined in the Ranger repo already under the name <oldclustername_hive> on the existing Ranger database inside Hadoop SQL service and you want to share the same policies in the new HDInsight 5.1 Spark cluster. To achieve this, follow the steps given below:

-

-> [!NOTE]

-> Config updates can be performed by the user with Ambari admin privileges.

-1. Open Ambari UI from your new HDInsight 5.1 cluster.

-1. Go to Spark 3 service -> Configs.

-1. Open ΓÇ£ranger-spark-securityΓÇ¥ security config.

-

- Or Open ΓÇ£ranger-spark-securityΓÇ¥ security config in /etc/spark3/conf using SSH.

-

- :::image type="content" source="./media/ranger-policies-for-spark/ambari-config-ranger-security.png" alt-text="Screenshot shows Ambari config ranger security." lightbox="./media/ranger-policies-for-spark/ambari-config-ranger-security.png":::

-

-1. Edit two configurations ΓÇ£ranger.plugin.spark.service.nameΓÇ£ and ΓÇ£ranger.plugin.spark.policy.cache.dir" to point to old policy repo ΓÇ£oldclustername_hiveΓÇ¥ and ΓÇ£SaveΓÇ¥ the configurations.

- Ambari:

-

- :::image type="content" source="./media/ranger-policies-for-spark/config-update-service-name-ambari.png" alt-text="Screenshot shows config update service name Ambari." lightbox="./media/ranger-policies-for-spark/config-update-service-name-ambari.png":::

-

- XML file:

- :::image type="content" source="./media/ranger-policies-for-spark/config-update-xml.png" alt-text="Screenshot shows config update xml." lightbox="./media/ranger-policies-for-spark/config-update-xml.png":::

-

-

-1. Restart Ranger and Spark services from Ambari.

- The policies get applied on databases in the spark catalog. If you want to access the databases under hive catalog, go to Ambari -> SPARK3 -> Configs -> Change ΓÇ£metastore.catalog.defaultΓÇ¥ from spark to hive.

-

- :::image type="content" source="./media/ranger-policies-for-spark/change-metastore-config.png" alt-text="Screenshot shows change metastore config." lightbox="./media/ranger-policies-for-spark/change-metastore-config.png":::

-### Known issues

-

-

-

-

-**What is the behavior if the query is includes a search parameter with status 'Supported'?**

-Cascade 500 is certified for Azure IoT Plug and Play and enables you to easily onboard the device into your end-to-end solutions. The Cascade gateway lets you wirelessly connect to various condition monitoring sensors that are in close proximity to the gateway device. You can use the gateway device to onboard these sensors into IoT Central.

-To create a new device template, select **+ New**, and follow the steps. You can create a custom device template from scratch, or you can choose a device template from the Azure device catalog.

-Select **+ New** to create a new device template and follow the creation process. You can create a custom device template from scratch or you can choose a device template from the Azure Device Catalog.

-1. Create a custom device template or choose a device template from the Azure IoT device catalog.

-By creating device templates, you and the application operators can configure and manage devices. You can build a custom template, import an existing template file, or import a template from the Azure IoT device catalog. After you create and customize a device template, use it to connect real devices to your application.

-1. Search for and then select the **RuuviTag Multisensor** device template in the Azure IoT device catalog.

-description: This article discusses the basic concepts for new users of Azure IoT Hub

-# IoT concepts and Azure IoT Hub

-Several messaging patterns are supported, including device-to-cloud telemetry, uploading files from devices, and request-reply methods to control your devices from the cloud. IoT Hub also supports monitoring to help you track device creation, device connections, and device failures.

-IoT Hub scales to millions of simultaneously connected devices and millions of events per second to support your IoT workloads. For more information about scaling your IoT Hub, see [IoT Hub scaling](iot-hub-scaling.md). To learn more about the tiers of service offered by IoT Hub, check out the [pricing page](https://azure.microsoft.com/pricing/details/iot-hub/).

-[IoT Central](../iot-central/core/overview-iot-central.md) applications use multiple IoT hubs as part of their scalable and resilient infrastructure.

-Each Azure subscription has default quota limits in place to prevent service abuse. These limits could impact the scope of your IoT solution. The current limit on a per-subscription basis is 50 IoT hubs per subscription. You can request quota increases by contacting support. For more information, see [IoT Hub quotas and throttling](iot-hub-devguide-quotas-throttling.md). For more information on quota limits, see one of the following articles:

-The SAS token method provides authentication for each call made by the device to IoT Hub by associating the symmetric key to each call. X.509 authentication allows authentication of an IoT device at the physical layer as part of the Transport Layer Security (TLS) standard connection establishment. The choice between the two methods is primarily dictated by how secure the device authentication needs to be, and availability of secure storage on the device (to store the private key securely).

-After selecting your authentication method, the internet connection between the IoT device and IoT Hub is secured using the Transport Layer Security (TLS) standard. Azure IoT supports TLS 1.2, TLS 1.1, and TLS 1.0, in that order. Support for TLS 1.0 is provided for backward compatibility only. Check TLS support in IoT Hub to see how to configure your hub to use TLS 1.2, which provides the most security.

-Typically, IoT devices send telemetry from the sensors to back-end services in the cloud. However, other types of communication are possible, such as a back-end service sending commands to your devices. Some examples of different types of communication include the following:

-Examples of telemetry received from a device can include sensor data such as speed or temperature, an error message such as missed event, or an information message to indicate the device is in good health. IoT devices send events to an application to gain insights. Applications may require specific subsets of events for processing or storage at different endpoints.

-To learn more about the differences between device twins and Plug and Play, see [Plug and Play](../iot/concepts-digital-twin.md#device-twins-and-digital-twins).

-A built-in endpoint collects data from your device by default. The data is collected using a request-response pattern over dedicated IoT device endpoints, is available for a maximum duration of seven days, and can be used to take actions on a device. Here is the data accepted by the device endpoint:

-For more information about IoT Hub endpoints, see [IoT Hub Dev Guide Endpoints](

-iot-hub-devguide-endpoints.md#list-of-built-in-iot-hub-endpoints)

-Data can also be routed to different services for further processing. As the IoT solution scales out, the number of devices, volume of events, variety of events, and different services also varies. A flexible, scalable, consistent, and reliable method to route events is necessary to serve this pattern. Once a message route has been created, data stops flowing to the built-in-endpoint unless a fallback route has been configured. For a tutorial showing multiple uses of message routing, see the [Routing Tutorial](tutorial-routing.md).

-IoT Hub supports setting up custom endpoints for various existing Azure services like Storage containers, Event Hubs, Service Bus queues, Service Bus topics, and Cosmos DB. Once the endpoint has been set up, you can route your IoT data to any of these endpoints to perform downstream data operations.

-IoT Hub also integrates with Event Grid, which enables you to fan out data to multiple subscribers. Event Grid is a fully managed event service that enables you to easily manage events across many different Azure services and applications. Made for performance and scale, it simplifies building event-driven applications and serverless architectures. The differences between message routing and using Event Grid are explained in the [Message Routing and Event Grid Comparison](iot-hub-event-grid-routing-comparison.md)

-description: Encryption of Azure IoT Hub data at rest using customer-managed keys

-# Encryption of Azure Iot Hub data at rest using customer-managed keys (preview)

-IoT Hub supports encryption of data at rest using customer-managed keys (CMK), also known as Bring your own key (BYOK). Azure IoT Hub provides encryption of data at rest and in-transit as it's written in our datacenters; the data is encrypted when read and decrypted when written.

->[!NOTE]

->The customer-managed keys feature is in private preview, and is not currently accepting new customers.

-By default, IoT Hub uses Microsoft-managed keys to encrypt the data. With CMK, you can get another layer of encryption on top of default encryption and can choose to encrypt data at rest with a key encryption key, managed through your [Azure Key Vault](https://azure.microsoft.com/services/key-vault/). This gives you the flexibility to create, rotate, disable, and revoke access controls. If BYOK is configured for your IoT Hub, we also provide double encryption, which offers a second layer of protection, while still allowing you to control the encryption key through your Azure Key Vault.

-This capability requires the creation of a new IoT Hub (basic or standard tier). To try this capability, contact us through [Microsoft support](https://azure.microsoft.com/support/create-ticket/). Share your company name and subscription ID when contacting Microsoft support.

-## Next steps

-* [What is IoT Hub?](./about-iot-hub.md)

-* [Learn more about Azure Key Vault](../key-vault/general/overview.md)

-description: This article describes how to use device twins to synchronize state and configuration data between IoT Hub and your devices

-*Device twins* are JSON documents that store device state information including metadata, configurations, and conditions. Azure IoT Hub maintains a device twin for each device that you connect to IoT Hub.

-* The structure of the device twin: *tags*, *desired* and *reported properties*.

-* The operations that device apps and back ends can perform on device twins.

-* Store device-specific metadata in the cloud. For example, the deployment location of a vending machine.

-Refer to [Device-to-cloud communication guidance](iot-hub-devguide-d2c-guidance.md) for guidance on using reported properties, device-to-cloud messages, or file upload.

-Refer to [Cloud-to-device communication guidance](iot-hub-devguide-c2d-guidance.md) for guidance on using desired properties, direct methods, or cloud-to-device messages.

-The lifecycle of a device twin is linked to the corresponding [device identity](iot-hub-devguide-identity-registry.md). Device twins are implicitly created and deleted when a device identity is created or deleted in IoT Hub.

-* **Tags**. A section of the JSON document that the solution back end can read from and write to. Tags are not visible to device apps.

-* **Device identity properties**. The root of the device twin JSON document contains the read-only properties from the corresponding device identity stored in the [identity registry](iot-hub-devguide-identity-registry.md). Properties `connectionStateUpdatedTime` and `generationId` will not be included.

-

-In the root object are the device identity properties, and container objects for `tags` and both `reported` and `desired` properties. The `properties` container contains some read-only elements (`$metadata` and `$version`) described in the [Device twin metadata](iot-hub-devguide-device-twins.md#device-twin-metadata) and [Optimistic concurrency](iot-hub-devguide-device-twins.md#optimistic-concurrency) sections.

-1. The solution back end sets the desired property with the desired configuration value. Here is the portion of the document with the desired property set:

-* **Receive twin notifications**. This operation allows the solution back end to be notified when the twin is modified. To do so, your IoT solution needs to create a route and to set the Data Source equal to *twinChangeEvents*. By default, no such route exists, so no twin notifications are sent. If the rate of change is too high, or for other reasons such as internal failures, the IoT Hub might send only one notification that contains all changes. Therefore, if your application needs reliable auditing and logging of all intermediate states, you should use device-to-cloud messages. To learn more about the properties and body returned in the twin notification message, see [Non-telemetry event schemas](iot-hub-non-telemetry-event-schema.md).

-* **Retrieve device twin**. This operation returns the device twin document (including desired and reported system properties) for the currently connected device. (Tags are not visible to device apps.)

- * Integers can have a minimum value of -4503599627370496 and a maximum value of 4503599627370495.

- * String values are UTF-8 encoded and can have a maximum length of 4 KB.

-IoT Hub enforces an 8 KB size limit on the value of `tags`, and a 32 KB size limit each on the value of `properties/desired` and `properties/reported`. These totals are exclusive of read-only elements like `$version` and `$metadata/$lastUpdated`.

-IoT Hub does not preserve desired properties update notifications for disconnected devices. It follows that a device that is connecting must retrieve the full desired properties document, in addition to subscribing for update notifications. Given the possibility of races between update notifications and full retrieval, the following flow must be ensured:

-## Additional reference material

-Other reference topics in the IoT Hub developer guide include:

-* The [IoT Hub endpoints](iot-hub-devguide-endpoints.md) article describes the various endpoints that each IoT hub exposes for run-time and management operations.

-* The [Throttling and quotas](iot-hub-devguide-quotas-throttling.md) article describes the quotas that apply to the IoT Hub service and the throttling behavior to expect when you use the service.

-* The [Azure IoT device and service SDKs](iot-hub-devguide-sdks.md) article lists the various language SDKs you can use when you develop both device and service apps that interact with IoT Hub.

-* The [IoT Hub query language for device twins, jobs, and message routing](iot-hub-devguide-query-language.md) article describes the IoT Hub query language you can use to retrieve information from IoT Hub about your device twins and jobs.

-* The [IoT Hub MQTT support](../iot/iot-mqtt-connect-to-iot-hub.md) article provides more information about IoT Hub support for the MQTT protocol.

-## SDK and hardware compatibility

-For more information about device SDK compatibility with specific hardware devices, see the [Azure Certified Device catalog](https://devicecatalog.azure.com/) or individual repository.

-description: How to upgrade from classic IP filter and what are the benefits

-# IoT Hub classic IP filter and how to upgrade

-The upgraded IP filter for IoT Hub protects the built-in endpoint and is secure by default. While we strive to never make breaking changes, the enhanced security model of the upgraded IP filter is incompatible with classic IP filter, so we announce its retirement. To learn more about the new upgraded IP filter, see [What's new](#whats-new) and [IoT hub IP filters](iot-hub-ip-filtering.md).

-To avoid service disruption, you must perform the guided upgrade before the migration deadline, at which point the upgrade will be performed automatically. To learn more about the migration timeline, see [Azure update](https://aka.ms/ipfilterv2azupdate).

-## How to upgrade

-1. Visit Azure portal

-2. Navigate to your IoT hub.

-3. Select **Networking** from the left-side menu.

-4. You should see a banner prompting you to upgrade your IP Filter to the new model. Select **Yes** to continue.

- :::image type="content" source="media/iot-hub-ip-filter-classic/ip-filter-upgrade-banner.png" alt-text="Image showing the banner prompt to upgrade from classic IP filter":::

-5. Since the new IP Filter blocks all IP by default, the upgrade removes your individual deny rules but gives you a chance to review them before saving. Carefully review the rules to make sure they work for you.

-6. Follow prompts to finish upgrading.

-## What's new

-### Secure by default

-Classic IP filter implicitly allows all IP addresses to connect to the IoT Hub by default, which doesn't align well with the most common network security scenarios. Typically, you would want only trusted IP addresses to be able to connect to your IoT hub and reject everything else. To achieve this goal with classic IP filter, it's a multi-step process. For example, if you want to only accept traffic from `192.168.100.0/22`, you must

-1. Configure a single *allow* rule for `192.168.100.0/22`.

-1. Configure a different *block* rule for `0.0.0.0/0` (the "block all" rule)

-1. Make sure the rules are ordered correctly, with the allow rule ordered above the block rule.

-In practice, this multi-step process causes confusion. Users didn't configure the "block all" rule or didn't order the rules correctly, resulting in unintended exposure.

-The new IP filter blocks all IP addresses by default. Only the IP ranges that you explicitly add are allowed to connect to IoT Hub. In the above example, steps 2 and 3 aren't needed anymore. This new behavior simplifies configuration and abides by the [secure by default principle](https://wikipedia.org/wiki/Secure_by_default).

-### Protect the built-in Event Hub compatible endpoint

-Classic IP filter cannot be applied to the built-in endpoint. This limitation means that, event with a block all rule (block `0.0.0.0/0`) configured, the built-in endpoint is still accessible from any IP address.

-The new IP filter provides an option to apply rules to the built-in endpoint, which reduces exposure to network security threats.

-> [!NOTE]

-> This option isn't available to free (F1) IoT hubs. To apply IP filter rules to the built-in endpoint, use a paid IoT hub.

-### API impact

-The upgraded IP filter is available in IoT Hub resource API from `2020-08-31` (as well as `2020-08-31-preview`) and onwards. Classic IP filter is still available in all API versions, but will be removed in a future API version near the migration deadline. To learn more about the migration timeline, see [Azure update](https://aka.ms/ipfilterv2azupdate).

-## Tip: try the changes before they apply

-Since the new IP filter blocks all IP address by default, individual block rules are no longer compatible. So, the guided upgrade process removes these individual block rules.

-To try to the change in with classic IP filter:

-1. Visit the **Networking** tab in your IoT hub

-1. Note down your existing IP filter (classic) configuration, in case you want to roll back

-1. Next to rules with **Block**, Select the trash icon to remove them

-1. Add another rule at the bottom with `0.0.0.0/0`, and choose **Block**

-1. Select **Save**

-This configuration mimics how the new IP filter behaves after upgrading from classic. One exception is the built-in endpoint protection, which is not possible to try using classic IP filter. However, that feature is optional, so you don't have to use it if you think it might break something.

-## Tip: check diagnostic logs for all IP connections to your IoT hub

-To ensure a smooth transition, check your diagnostic logs under the Connections category. Look for the `maskedIpAddress` property to see if the ranges are as you expect. Remember: the new IP filter will block all IP addresses that haven't been explicitly added.

-## IoT Hub classic IP filter documentation (retired)

-> [!IMPORTANT]

-> Below is the original documentation for classic IP filter, which is being retired.

-Security is an important aspect of any IoT solution based on Azure IoT Hub. Sometimes you need to explicitly specify the IP addresses from which devices can connect as part of your security configuration. The *IP filter* feature enables you to configure rules for rejecting or accepting traffic from specific IPv4 addresses.

-### When to use

-There are two specific use-cases when it is useful to block the IoT Hub endpoints for certain IP addresses:

-* Your IoT hub should receive traffic only from a specified range of IP addresses and reject everything else. For example, you are using your IoT hub with [Azure Express Route](../expressroute/expressroute-faqs.md#supported-services) to create private connections between an IoT hub and your on-premises infrastructure.

-* You need to reject traffic from IP addresses that have been identified as suspicious by the IoT hub administrator.

-### How filter rules are applied

-The IP filter rules are applied at the IoT Hub service level. Therefore, the IP filter rules apply to all connections from devices and back-end apps using any supported protocol. However, clients reading directly from the [built-in Event Hub compatible endpoint](iot-hub-devguide-messages-read-builtin.md) (not via the IoT Hub connection string) are not bound to the IP filter rules.

-Any connection attempt from an IP address that matches a rejecting IP rule in your IoT hub receives an unauthorized 401 status code and description. The response message does not mention the IP rule. Rejecting IP addresses can prevent other Azure services such as Azure Stream Analytics, Azure Virtual Machines, or the Device Explorer in Azure portal from interacting with the IoT hub.

-> [!NOTE]

-> If you must use Azure Stream Analytics (ASA) to read messages from an IoT hub with IP filter enabled, use the event hub-compatible name and endpoint of your IoT hub to manually add an [Event Hubs stream input](../stream-analytics/stream-analytics-define-inputs.md#stream-data-from-event-hubs) in the ASA.

-### Default setting

-By default, the **IP Filter** grid in the portal for an IoT hub is empty. This default setting means that your hub accepts connections from any IP address. This default setting is equivalent to a rule that accepts the 0.0.0.0/0 IP address range.

-To get to the IP Filter settings page, select **Networking**, **Public access**, then choose **Selected IP Ranges**:

-### Add or edit an IP filter rule

-To add an IP filter rule, select **+ Add IP Filter Rule**.

-After selecting **Add IP Filter Rule**, fill in the fields.

-* Provide a **name** for the IP Filter rule. This must be a unique, case-insensitive, alphanumeric string up to 128 characters long. Only the ASCII 7-bit alphanumeric characters plus `{'-', ':', '/', '\', '.', '+', '%', '_', '#', '*', '?', '!', '(', ')', ',', '=', '@', ';', '''}` are accepted.

-* Provide a single IPv4 address or a block of IP addresses in CIDR notation. For example, in CIDR notation 192.168.100.0/22 represents the 1024 IPv4 addresses from 192.168.100.0 to 192.168.103.255.

-* Select **Allow** or **Block** as the **action** for the IP filter rule.

-After filling in the fields, select **Save** to save the rule. You see an alert notifying you that the update is in progress.

-The **Add** option is disabled when you reach the maximum of 10 IP filter rules.

-To edit an existing rule, select the data you want to change, make the change, then select **Save** to save your edit.

-### Delete an IP filter rule

-To delete an IP filter rule, select the trash can icon on that row and then select **Save**. The rule is removed and the change is saved.

-### Retrieve and update IP filters using Azure CLI

-Your IoT Hub's IP filters can be retrieved and updated through [Azure CLI](/cli/azure/).

-To retrieve current IP filters of your IoT Hub, run:

-```azurecli-interactive

-az resource show -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs

-```

-This will return a JSON object where your existing IP filters are listed under the `properties.ipFilterRules` key:

-```json

-{

-...

- "properties": {

- "ipFilterRules": [

- {

- "action": "Reject",

- "filterName": "MaliciousIP",

- "ipMask": "6.6.6.6/6"

- },

- {

- "action": "Allow",

- "filterName": "GoodIP",

- "ipMask": "131.107.160.200"

- },

- ...

- ],

- },

-...

-}

-```

-To add a new IP filter for your IoT Hub, run:

-```azurecli-interactive

-az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --add properties.ipFilterRules "{\"action\":\"Reject\",\"filterName\":\"MaliciousIP\",\"ipMask\":\"6.6.6.6/6\"}"

-```

-To remove an existing IP filter in your IoT Hub, run:

-```azurecli-interactive

-az resource update -n <iothubName> -g <resourceGroupName> --resource-type Microsoft.Devices/IotHubs --add properties.ipFilterRules <ipFilterIndexToRemove>

-```

-Note that `<ipFilterIndexToRemove>` must correspond to the ordering of IP filters in your IoT Hub's `properties.ipFilterRules`.

-### Retrieve and update IP filters using Azure PowerShell

-Your IoT Hub's IP filters can be retrieved and set through [Azure PowerShell](/powershell/azure/).

-```powershell

-# Get your IoT Hub resource using its name and its resource group name

-$iothubResource = Get-AzResource -ResourceGroupName <resourceGroupNmae> -ResourceName <iotHubName> -ExpandProperties

-# Access existing IP filter rules

-$iothubResource.Properties.ipFilterRules |% { Write-host $_ }

-# Construct a new IP filter

-$filter = @{'filterName'='MaliciousIP'; 'action'='Reject'; 'ipMask'='6.6.6.6/6'}

-# Add your new IP filter rule

-$iothubResource.Properties.ipFilterRules += $filter

-# Remove an existing IP filter rule using its name, e.g., 'GoodIP'

-$iothubResource.Properties.ipFilterRules = @($iothubResource.Properties.ipFilterRules | Where 'filterName' -ne 'GoodIP')

-# Update your IoT Hub resource with your updated IP filters

-$iothubResource | Set-AzResource -Force

-```

-### Update IP filter rules using REST

-You may also retrieve and modify your IoT Hub's IP filter using Azure resource Provider's REST endpoint. See `properties.ipFilterRules` in [createorupdate method](/rest/api/iothub/iothubresource/createorupdate).

-### IP filter rule evaluation

-IP filter rules are applied in order and the first rule that matches the IP address determines the accept or reject action.

-For example, if you want to accept addresses in the range 192.168.100.0/22 and reject everything else, the first rule in the grid should accept the address range 192.168.100.0/22. The next rule should reject all addresses by using the range 0.0.0.0/0.

-You can change the order of your IP filter rules in the grid by clicking the three vertical dots at the start of a row and using drag and drop.

-To save your new IP filter rule order, click **Save**.

-## Next steps

-To further explore the capabilities of IoT Hub, see:

-* [Use IP filters](iot-hub-ip-filtering.md)

-* Complete one of the [Send telemetry](../iot-develop/quickstart-send-telemetry-iot-hub.md?toc=/azure/iot-hub/toc.json&bc=/azure/iot-hub/breadcrumb/toc.json) quickstarts in the development language of your choice. Alternatively, you can use any device app that sends temperature telemetry; for example, the [Raspberry Pi online simulator](iot-hub-raspberry-pi-web-simulator-get-started.md) or one of the [Embedded device](../iot-develop/quickstart-devkit-mxchip-az3166.md) quickstarts. These articles cover the following requirements:

-* A simulated device that sends telemetry messages to your IoT hub. Use the [Raspberry Pi online simulator](iot-hub-raspberry-pi-web-simulator-get-started.md) to get a simulated device that sends temperature data to IoT Hub.

- * Codeless: [Raspberry Pi online simulator](iot-hub-raspberry-pi-web-simulator-get-started.md)

-description: Learn how to setup and connect Raspberry Pi to Azure IoT Hub for Raspberry Pi to send data to the Azure cloud platform

-# Connect Raspberry Pi to Azure IoT Hub (C)

-In this article, you learn the basics of working with Raspberry Pi that's running Raspberry Pi OS. You then learn how to connect your devices to the cloud by using [Azure IoT Hub](about-iot-hub.md). For Windows 10 IoT Core samples, go to the [Windows Dev Center](https://www.windowsondevices.com/).

-Don't have a kit yet? Try [Raspberry Pi online simulator](iot-hub-raspberry-pi-web-simulator-get-started.md). Or buy a new kit [here](https://azure.microsoft.com/develop/iot/starter-kits).

-## What you do

-* Create an IoT hub.

-* Register a device for Pi in your IoT hub.

-* Setup Raspberry Pi.

-* Run a sample application on Pi to send sensor data to your IoT hub.

-Connect Raspberry Pi to an IoT hub that you create. Then you run a sample application on Pi to collect temperature and humidity data from a BME280 sensor. Finally, you send the sensor data to your IoT hub.

-## What you learn

-* How to create an Azure IoT hub and get your new device connection string.

-* How to connect Pi with a BME280 sensor.

-* How to collect sensor data by running a sample application on Pi.

-* How to send sensor data to your IoT hub.

-## What you need

-

-* The Raspberry Pi 2 or Raspberry Pi 3 board.

-* An active Azure subscription. If you don't have an Azure account, [create a free Azure trial account](https://azure.microsoft.com/free/) in just a few minutes.

-* A monitor, a USB keyboard, and mouse that connect to Pi.

-* A Mac or a PC that is running Windows or Linux.

-* An Internet connection.

-* A 16 GB or above microSD card.

-* A USB-SD adapter or microSD card to burn the operating system image onto the microSD card.

-* A 5-volt 2-amp power supply with the 6-foot micro USB cable.

-The following items are optional:

-* An assembled Adafruit BME280 temperature, pressure, and humidity sensor.

-* A breadboard.

-* 6 F/M jumper wires.

-* A diffused 10-mm LED.

-> [!NOTE]

-> These items are optional because the code sample supports simulated sensor data.

->

-## Create an IoT hub

-## Register a new device in the IoT hub

-## Set up Raspberry Pi

-Now set up the Raspberry Pi.

-### Install the Raspberry Pi OS

-Prepare the microSD card for installation of the Raspberry Pi OS image.

-1. Download Raspberry Pi OS.

- 1. [Download Raspberry Pi OS with Desktop](https://www.raspberrypi.org/software/) (the .zip file).

- 2. Extract the image to a folder on your computer.

-2. Install Raspberry Pi OS to the microSD card.

- 1. [Download and install the Etcher SD card burner utility](https://etcher.io/).

- 2. Run Etcher and select the Raspberry Pi OS image that you extracted in step 1.

- 3. Select the microSD card drive. Note that Etcher may have already selected the correct drive.

- 4. Click Flash to install Raspberry Pi OS to the microSD card.

- 5. Remove the microSD card from your computer when installation is complete. It's safe to remove the microSD card directly because Etcher automatically ejects or unmounts the microSD card upon completion.

- 6. Insert the microSD card into Pi.

-### Enable SSH and SPI

-1. Connect Pi to the monitor, keyboard and mouse, start Pi and then sign in to Raspberry Pi OS by using `pi` as the user name and `raspberry` as the password.

-

-2. Click the Raspberry icon > **Preferences** > **Raspberry Pi Configuration**.

- 

-3. On the **Interfaces** tab, set **SPI** and **SSH** to **Enable**, and then click **OK**. If you don't have physical sensors and want to use simulated sensor data, this step is optional.

- 

-> [!NOTE]

-> To enable SSH and SPI, you can find more reference documents on [raspberrypi.org](https://www.raspberrypi.org/documentation/remote-access/ssh/) and [RASPI-CONFIG](https://www.raspberrypi.org/documentation/configuration/raspi-config.md).

->

-### Connect the sensor to Pi

-Use the breadboard and jumper wires to connect an LED and a BME280 to Pi as follows. If you donΓÇÖt have the sensor, [skip this section](#connect-pi-to-the-network).

-

-The BME280 sensor can collect temperature and humidity data. And the LED will blink if there is a communication between device and the cloud.

-For sensor pins, use the following wiring:

-| Start (Sensor & LED) | End (Board) | Cable Color |

-| -- | - | : |

-| LED VDD (Pin 5G) | GPIO 4 (Pin 7) | White cable |

-| LED GND (Pin 6G) | GND (Pin 6) | Black cable |

-| VDD (Pin 18F) | 3.3V PWR (Pin 17) | White cable |

-| GND (Pin 20F) | GND (Pin 20) | Black cable |

-| SCK (Pin 21F) | SPI0 SCLK (Pin 23) | Orange cable |

-| SDO (Pin 22F) | SPI0 MISO (Pin 21) | Yellow cable |

-| SDI (Pin 23F) | SPI0 MOSI (Pin 19) | Green cable |

-| CS (Pin 24F) | SPI0 CS (Pin 24) | Blue cable |

-Click to view [Raspberry Pi 2 & 3 Pin mappings](/windows/iot-core/learn-about-hardware/pinmappings/pinmappingsrpi) for your reference.

-After you've successfully connected BME280 to your Raspberry Pi, it should be like below image.

-

-### Connect Pi to the network

-Turn on Pi by using the micro USB cable and the power supply. Use the Ethernet cable to connect Pi to your wired network or follow the [instructions from the Raspberry Pi Foundation](https://www.raspberrypi.org/documentation/configuration/wireless/) to connect Pi to your wireless network. After your Pi has been successfully connected to the network, you need to take a note of the [IP address of your Pi](https://www.raspberrypi.org/documentation/remote-access/ip-address.md).

-

-## Run a sample application on Pi

-### Sign into your Raspberry Pi

-1. Use one of the following SSH clients from your host computer to connect to your Raspberry Pi.

-

- **Windows Users**

- 1. Download and install [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) for Windows.

- 1. Copy the IP address of your Pi into the Host name (or IP address) section and select SSH as the connection type.

-

- 

- **Mac and Ubuntu Users**

- Use the built-in SSH client on Ubuntu or macOS. You might need to run `ssh pi@<ip address of pi>` to connect Pi via SSH.

- > [!NOTE]

- > The default username is `pi` , and the password is `raspberry`.

-### Configure the sample application

-1. Clone the sample application by running the following command:

- ```bash

- git clone https://github.com/Azure-Samples/iot-hub-c-raspberrypi-client-app.git

- ```

-2. A setup script is provided with the sample to prepare the development environment, and build the sample. Run setup script:

- ```bash

- cd ./iot-hub-c-raspberrypi-client-app

- sudo chmod u+x setup.sh

- sudo ./setup.sh

- ```

- > [!NOTE]

- > If you **don't have a physical BME280**, you can use '--simulated-data' as command line parameter to simulate temperature&humidity data. `sudo ./setup.sh --simulated-data`

- >

-### Build and run the sample application

-1. The setup script should have already built the sample. However, if you make changes and need to rebuild the sample application, run the following command:

- ```bash

- cmake . && make

- ```

-

- 

-1. Run the sample application by running the following command:

- ```bash

- sudo ./app '<DEVICE CONNECTION STRING>'

- ```

- > [!NOTE]

- > Make sure you copy-paste the device connection string into the single quotes.

- >

-You should see the following output that shows the sensor data and the messages that are sent to your IoT hub.

-

-## Read the messages received by your hub

-One way to monitor messages received by your IoT hub from your device is to use the Azure IoT Hub extension for Visual Studio Code. To learn more, see [Use the Azure IoT Hub extension for Visual Studio Code to send and receive messages between your device and IoT Hub](iot-hub-vscode-iot-toolkit-cloud-device-messaging.md).

-For more ways to process data sent by your device, continue on to the next section.

-## Clean up resources

-You can use the resources created in this topic with other tutorials and quickstarts in this document set. If you plan to continue on to work with other quickstarts or with the tutorials, do not clean up the resources created in this topic. If you do not plan to continue, use the following steps to delete all resources created by this topic in the Azure portal.

-1. From the left-hand menu in the Azure portal, select **All resources** and then select the IoT Hub you created.

-1. At the top of the IoT Hub overview pane, click **Delete**.

-1. Enter your hub name and click **Delete** again to confirm permanently deleting the IoT hub.

-## Next steps

-YouΓÇÖve run a sample application to collect sensor data and send it to your IoT hub.

-description: Learn how to set up and connect Raspberry Pi to Azure IoT Hub for Raspberry Pi to send data to the Azure cloud platform in this tutorial.

-# Connect Raspberry Pi to Azure IoT Hub (Node.js)

-In this article, you learn the basics of working with Raspberry Pi that's running Raspberry Pi OS. You then learn how to seamlessly connect your devices to the cloud by using [Azure IoT Hub](about-iot-hub.md). For Windows 10 IoT Core samples, go to the [Windows Dev Center](https://www.windowsondevices.com/).

-Don't have a kit yet? Try [Raspberry Pi online simulator](iot-hub-raspberry-pi-web-simulator-get-started.md). Or buy a new kit [here](https://azure.microsoft.com/develop/iot/starter-kits).

-## What you do

-* Create an IoT hub.

-* Register a device for Pi in your IoT hub.

-* Set up Raspberry Pi.

-* Run a sample application on Pi to send sensor data to your IoT hub.

-## What you learn

-* How to create an Azure IoT hub and get your new device connection string.

-* How to connect Pi with a BME280 sensor.

-* How to collect sensor data by running a sample application on Pi.

-* How to send sensor data to your IoT hub.

-## What you need

-

-* A Raspberry Pi 2 or Raspberry Pi 3 board.

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

-* A monitor, a USB keyboard, and mouse that connects to Pi.

-* A Mac or PC that is running Windows or Linux.

-* An internet connection.

-* A 16 GB or above microSD card.

-* A USB-SD adapter or microSD card to burn the operating system image onto the microSD card.

-* A 5-volt 2-amp power supply with the 6-foot micro USB cable.

-The following items are optional:

-* An assembled Adafruit BME280 temperature, pressure, and humidity sensor.

-* A breadboard.

-* 6 F/M jumper wires.

-* A diffused 10-mm LED.

-> [!NOTE]

-> If you don't have the optional items, you can use simulated sensor data.

-## Create an IoT hub

-## Register a new device in the IoT hub

-## Set up Raspberry Pi

-### Install the Raspberry Pi OS

-Prepare the microSD card for installation of the Raspberry Pi OS image.

-1. Download Raspberry Pi OS with desktop.

- a. [Raspberry Pi OS with desktop](https://www.raspberrypi.org/software/) (the .zip file).

- b. Extract the Raspberry Pi OS with desktop image to a folder on your computer.

-2. Install Raspberry Pi OS with desktop to the microSD card.

- a. [Download and install the Etcher SD card burner utility](https://etcher.io/).

- b. Run Etcher and select the Raspberry Pi OS with desktop image that you extracted in step 1.

- c. Select the microSD card drive. Etcher may have already selected the correct drive.

- d. Select Flash to install Raspberry Pi OS with desktop to the microSD card.

- e. Remove the microSD card from your computer when installation is complete. It's safe to remove the microSD card directly because Etcher automatically ejects or unmounts the microSD card upon completion.

- f. Insert the microSD card into Pi.

-### Enable SSH and I2C

-1. Connect Pi to the monitor, keyboard, and mouse.

-2. Start Pi and then sign into Raspberry Pi OS by using `pi` as the user name and `raspberry` as the password.

-3. Select the Raspberry icon > **Preferences** > **Raspberry Pi Configuration**.

- 

-4. On the **Interfaces** tab, set **SSH** and **I2C** to **Enable**, and then select **OK**.

-

- | Interface | Description |

- | | -- |

- | *SSH* | Secure Shell (SSH) is used to remote into the Raspberry Pi with a remote command-line. This is the preferred method for issuing the commands to your Raspberry Pi remotely in this document. |

- | *I2C* | Inter-integrated Circuit (I2C) is a communications protocol used to interface with hardware such as sensors. This interface is required for interfacing with physical sensors in this article.|

- If you don't have physical sensors and want to use simulated sensor data from your Raspberry Pi device, you can leave **I2C** disabled.

- 

-> [!NOTE]

-> To enable SSH and I2C, you can find more reference documents on [raspberrypi.org](https://www.raspberrypi.org/documentation/remote-access/ssh/) and [Adafruit.com](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c).

-### Connect the sensor to Pi

-Use the breadboard and jumper wires to connect an LED and a BME280 to Pi as follows. If you don't have the sensor, [skip this section](#connect-pi-to-the-network).

-

-The BME280 sensor can collect temperature and humidity data. The LED blinks when the device sends a message to the cloud.

-For sensor pins, use the following wiring:

-| Start (Sensor & LED) | End (Board) | Cable Color |

-| -- | - | : |

-| VDD (Pin 5G) | 3.3 V PWR (Pin 1) | White cable |

-| GND (Pin 7G) | GND (Pin 6) | Brown cable |

-| SDI (Pin 10G) | I2C1 SDA (Pin 3) | Red cable |

-| SCK (Pin 8G) | I2C1 SCL (Pin 5) | Orange cable |

-| LED VDD (Pin 18F) | GPIO 24 (Pin 18) | White cable |

-| LED GND (Pin 17F) | GND (Pin 20) | Black cable |

-For more information, see [Raspberry Pi 2 & 3 pin mappings](/windows/iot-core/learn-about-hardware/pinmappings/pinmappingsrpi).

-After you've successfully connected BME280 to your Raspberry Pi, it should be like below image.

-

-### Connect Pi to the network

-Turn on Pi by using the micro USB cable and the power supply. Use the Ethernet cable to connect Pi to your wired network or follow the [instructions from the Raspberry Pi Foundation](https://www.raspberrypi.org/documentation/configuration/wireless/) to connect Pi to your wireless network. After your Pi has been successfully connected to the network, you need to take a note of the [IP address of your Pi](https://www.raspberrypi.org/documentation/remote-access/ip-address.md).

-> [!NOTE]

-> Make sure that Pi is connected to the same network as your computer. For example, if your computer is connected to a wireless network while Pi is connected to a wired network, you might not see the IP address in the devdisco output.

-## Run a sample application on Pi

-### Clone sample application and install the prerequisite packages

-1. Connect to your Raspberry Pi with one of the following SSH clients from your host computer:

- **Windows Users**

- a. Download and install [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) for Windows.

- b. Copy the IP address of your Pi into the Host name (or IP address) section and select SSH as the connection type.

- 

- **Mac and Ubuntu Users**

- Use the built-in SSH client on Ubuntu or macOS. You might need to run `ssh pi@<ip address of pi>` to connect Pi via SSH.

- > [!NOTE]

- > The default username is `pi` and the password is `raspberry`.

-2. Install Node.js and npm to your Pi.

- First check your Node.js version.

- ```bash

- node -v

- ```

- If the version is lower than 10.x, or if Node.js isn't on your Pi, install the latest version.

- ```bash

- curl -sSL https://deb.nodesource.com/setup_16.x | sudo -E bash

- sudo apt-get -y install nodejs

- ```

-3. Clone the sample application.

- ```bash

- git clone https://github.com/Azure-Samples/azure-iot-samples-node.git

- ```

-4. Install all packages for the sample. The installation includes Azure IoT device SDK, BME280 Sensor library, and Wiring Pi library.

- ```bash

- cd azure-iot-samples-node/iot-hub/Tutorials/RaspberryPiApp

- npm install

- ```

- > [!NOTE]

- >It might take several minutes to finish this installation process depending on your network connection.

-### Configure the sample application

-1. Open the config file by running the following commands:

- ```bash

- nano config.json

- ```

- 

- There are two items in this file you can configure. The first one is `interval`, which defines the time interval (in milliseconds) between messages sent to the cloud. The second one is `simulatedData`, which is a Boolean value for whether to use simulated sensor data or not.

- If you **don't have the sensor**, set the `simulatedData` value to `true` to make the sample application create and use simulated sensor data.

- *Note: The i2c address used in this tutorial is 0x77 by default. Depending on your configuration it might also be 0x76: if you encounter an i2c error, try to change the value to 118 and see if that works better. To see what address is used by your sensor, run `sudo i2cdetect -y 1` in a shell on the raspberry pi*

-2. Save and exit by typing Control-O > Enter > Control-X.

-### Run the sample application

-Run the sample application by running the following command:

- ```bash

- sudo node index.js '<YOUR AZURE IOT HUB DEVICE CONNECTION STRING>'

- ```

- > [!NOTE]

- > Make sure you copy-paste the device connection string into the single quotes.

-You should see the following output that shows the sensor data and the messages that are sent to your IoT hub.

-

-## Read the messages received by your hub

-One way to monitor messages received by your IoT hub from your device is to use the Azure IoT Hub extension for Visual Studio Code. To learn more, see [Use the Azure IoT Hub extension for Visual Studio Code to send and receive messages between your device and IoT Hub](iot-hub-vscode-iot-toolkit-cloud-device-messaging.md).

-For more ways to process data sent by your device, continue on to the next section.

-## Clean up resources

-You can use the resources created in this article with other tutorials and quickstarts in this document set. If you plan to continue on to work with other quickstarts or with the tutorials, don't clean up the resources created in this article. If you don't plan to continue, use the following steps to delete all resources created by this article in the Azure portal.

-1. From the left-hand menu in the Azure portal, select **All resources** and then select the IoT Hub you created.

-1. At the top of the IoT Hub overview pane, select **Delete**.

-1. Enter your hub name and select **Delete** again to confirm permanently deleting the IoT hub.

-## Next steps

-In this article, you ran a sample application to collect sensor data and send it to your IoT hub.

-description: Connect Raspberry Pi web simulator to Azure IoT Hub for Raspberry Pi to send data to the Azure cloud.

-# Connect Raspberry Pi online simulator to Azure IoT Hub (Node.js)

-In this article, you learn the basics of working with Raspberry Pi online simulator. You then learn how to seamlessly connect the Pi simulator to the cloud by using [Azure IoT Hub](about-iot-hub.md).

-[:::image type="content" source="media/iot-hub-raspberry-pi-web-simulator/6-button-default.png" alt-text="Start Raspberry Pi simulator":::](https://azure-samples.github.io/raspberry-pi-web-simulator/#getstarted)

-If you have physical devices, visit [Connect Raspberry Pi to Azure IoT Hub](iot-hub-raspberry-pi-kit-node-get-started.md) to get started.

-## What you do

-* Learn the basics of Raspberry Pi online simulator.

-* Create an IoT hub.

-* Register a device for Pi in your IoT hub.

-* Run a sample application on Pi to send simulated sensor data to your IoT hub.

-You first connect the simulated Raspberry Pi to an IoT hub that you create. You then run a sample application with the simulated Pi to generate sensor data. Finally, you send the sensor data to your IoT hub.

-## What you learn

-* How to create an Azure IoT hub and get your new device connection string. If you don't have an Azure account, [create a free Azure trial account](https://azure.microsoft.com/free/) in just a few minutes.

-* How to work with Raspberry Pi online simulator.

-* How to send sensor data to your IoT hub.

-## Overview of Raspberry Pi web simulator

-Select the following button to start Raspberry Pi online simulator.

-> [!div class="button"]

-> <a href="https://azure-samples.github.io/raspberry-pi-web-simulator/#GetStarted" target="_blank">Start Raspberry Pi Simulator</a>

-There are three areas in the web simulator.

-1. Assembly area - A graphic depiction of the Pi simulator, and any simulated devices and connections.

- By default, the assembly area simulates connections from the Pi to two devices:

- * A BME280 humidity sensor connected to I2C.1

- * An LED connected to GPIO 4

- The assembly area is locked in this preview version, so you currently can't customize the assembly.

-2. Coding area - An online code editor for you to code with Raspberry Pi. The default sample application helps to collect sensor data from the simulated BME280 sensor and sends that data to your IoT hub. The application is fully compatible with real Pi devices.

-3. Integrated console window - A window that shows the output of your code. At the top of this window, there are three buttons.

- * **Run** - Run the application in the coding area.

- * **Reset** - Reset the coding area to the default sample application.

- * **Collapse/Expand** - On the right side, there's a button for you to collapse or expand the console window.

-> [!NOTE]

-> The Raspberry Pi web simulator is currently available in a preview version. We'd like to hear your voice in the [Gitter Chatroom](https://gitter.im/Microsoft/raspberry-pi-web-simulator). The source code is public on [GitHub](https://github.com/Azure-Samples/raspberry-pi-web-simulator).

-

-## Create an IoT hub

-## Register a new device in the IoT hub

-## Run a sample application on Pi web simulator

-1. In the coding area, make sure you're working with the default sample application. Replace the placeholder in line 15 with the Azure IoT hub device connection string.

-

- 

-2. Select **Run** or type `npm start` in the integrated console window to run the application.

-You should see the following output that shows the sensor data and the messages that are sent to your IoT hub

-

-## Read the messages received by your hub

-One way to monitor messages received by your IoT hub from the simulated device is to use the Azure IoT Hub extension for Visual Studio Code. To learn more, see [Use the Azure IoT Hub extension for Visual Studio Code to send and receive messages between your device and IoT Hub](iot-hub-vscode-iot-toolkit-cloud-device-messaging.md).

-For more ways to process data sent by your device, continue on to the next section.

-## Next steps

-You've run a sample application to collect sensor data and send it to your IoT hub.

-### Azure Certified Device program

-Azure Certified [Device](#device) is a free program that enables you to differentiate, certify, and promote your IoT devices built to run on Azure.

-[Learn more](../certification/overview.md)

-Casing rules: Always capitalize as *Azure Certified Device*.

-Applies to: Iot Hub, IoT Central

-In the context of IoT, a device is typically a small-scale, standalone computing device that may collect data or control other devices. For example, a device might be an environmental monitoring device, or a controller for the watering and ventilation systems in a greenhouse. The device catalog provides a list of certified devices.

-There's a wide variety of devices available from different manufacturers to build your solution. For a list of devices certified to work with Azure IoT Hub, see the [Azure Certified for IoT device catalog](https://devicecatalog.azure.com). For prototyping a microprocessor device, you can use a device such as a [Raspberry Pi](https://www.raspberrypi.org/). The Raspberry Pi lets you attach many different types of sensor. For prototyping a microcontroller device, you can use devices such as the [ESPRESSIF ESP32](../iot-develop/quickstart-devkit-espressif-esp32-freertos-iot-hub.md), [STMicroelectronics B-U585I-IOT02A Discovery kit](../iot-develop/quickstart-devkit-stm-b-u585i-iot-hub.md), [STMicroelectronics B-L4S5I-IOT01A Discovery kit](../iot-develop/quickstart-devkit-stm-b-l4s5i-iot-hub.md), or [NXP MIMXRT1060-EVK Evaluation kit](../iot-develop/quickstart-devkit-nxp-mimxrt1060-evk-iot-hub.md). These boards typically have built-in sensors, such as temperature and accelerometer sensors.

-* [Azure Certified Device Catalog](https://devicecatalog.azure.com/)

-You can choose a device to use from the [Azure Certified for IoT device catalog](https://devicecatalog.azure.com). You can implement your own embedded code using the open-source [device SDKs](./iot-sdks.md). The device SDKs support multiple operating systems, such as Linux, Windows, and real-time operating systems. There are SDKs for multiple programming languages, such as [C](https://github.com/Azure/azure-iot-sdk-c), [Node.js](https://github.com/Azure/azure-iot-sdk-node), [Java](https://github.com/Azure/azure-iot-sdk-java), [.NET](https://github.com/Azure/azure-iot-sdk-csharp), and [Python](https://github.com/Azure/azure-iot-sdk-python).

-## Device certification

-The [IoT Plug and Play device certification program](../certification/program-requirements-pnp.md) verifies that a device meets the IoT Plug and Play certification requirements. You can add a certified device to the public [Certified for Azure IoT device catalog](https://aka.ms/devicecatalog) where it's discoverable by other solution builders.

-These steps will enable you to manually replicate contents of the HSM to another region. The HSM name (and the service endpoint URI) will be different, so you may have to change your application configuration to make use of these keys from a different location.

-This article provides a list of IPv6 configuration tasks with the portion of the Azure Resource Manager VM template that applies to. Use the template described in this article to deploy a dual stack (IPv4 + IPv6) application with Basic Load Balancer that includes a dual stack virtual network with IPv4 and IPv6 subnets, a Basic Load Balancer with dual (IPv4 + IPv6) front-end configurations, VMs with NICs that have a dual IP configuration, network security group, and public IPs.

-### IPv6 Back-end address pool for Load Balancer

-## Create back-end servers

-* Create a front-end IP with [New-AzLoadBalancerFrontendIpConfig](/powershell/module/az.network/new-azloadbalancerfrontendipconfig) for the frontend IP pool. This IP receives the incoming traffic on the load balancer

-* Create a back-end address pool with [New-AzLoadBalancerBackendAddressPoolConfig](/powershell/module/az.network/new-azloadbalancerbackendaddresspoolconfig) for traffic sent from the frontend of the load balancer

-* Create a front-end IP with [New-AzLoadBalancerFrontendIpConfig](/powershell/module/az.network/new-azloadbalancerfrontendipconfig) for the frontend IP pool. This IP receives the incoming traffic on the load balancer

-* Create a back-end address pool with [New-AzLoadBalancerBackendAddressPoolConfig](/powershell/module/az.network/new-azloadbalancerbackendaddresspoolconfig) for traffic sent from the frontend of the load balancer. This pool is where your backend virtual machines are deployed

-This article shows you how to deploy a dual stack (IPv4 + IPv6) application with Basic Load Balancer using Azure CLI that includes a dual stack virtual network with a dual stack subnet, a Basic Load Balancer with dual (IPv4 + IPv6) front-end configurations, VMs with NICs that have a dual IP configuration, dual network security group rules, and dual public IPs.

-In this section, you configure dual frontend IP (IPv4 and IPv6) and the back-end address pool for the load balancer and then create a Basic Load Balancer.

-### Configure IPv6 back-end address pool

-Create a IPv6 back-end address pools with [az network lb address-pool create](/cli/azure/network/lb/address-pool#az-network-lb-address-pool-create). The following example creates back-end address pool named *dsLbBackEndPool_v6* to include VMs with IPv6 NIC configurations:

-In this article, you created a Basic Load Balancer with a dual frontend IP configuration (IPv4 and IPv6). You also created a two virtual machines that included NICs with dual IP configurations (IPV4 + IPv6) that were added to the back-end pool of the load balancer. To learn more about IPv6 support in Azure virtual networks, see [What is IPv6 for Azure Virtual Network?](../../virtual-network/ip-services/ipv6-overview.md)

-This article shows you how to deploy a dual stack (IPv4 + IPv6) application with Basic Load Balancer using Azure PowerShell that includes a dual stack virtual network and subnet, a Basic Load Balancer with dual (IPv4 + IPv6) front-end configurations, VMs with NICs that have a dual IP configuration, network security group, and public IPs.

-In this section, you configure dual frontend IP (IPv4 and IPv6) and the back-end address pool for the load balancer and then create a Basic Load Balancer.

-### Create front-end IP

-Create a front-end IP with [New-AzLoadBalancerFrontendIpConfig](/powershell/module/az.network/new-azloadbalancerfrontendipconfig). The following example creates IPv4 and IPv6 frontend IP configurations named *dsLbFrontEnd_v4* and *dsLbFrontEnd_v6*:

-### Configure back-end address pool

-Create a back-end address pool with [New-AzLoadBalancerBackendAddressPoolConfig](/powershell/module/az.network/new-azloadbalancerbackendaddresspoolconfig). The VMs attach to this back-end pool in the remaining steps. The following example creates back-end address pools named *dsLbBackEndPool_v4* and *dsLbBackEndPool_v6* to include VMs with both IPV4 and IPv6 NIC configurations:

-In this article, you created a Basic Load Balancer with a dual frontend IP configuration (IPv4 and IPv6). You also created a two virtual machines that included NICs with dual IP configurations (IPV4 + IPv6) that were added to the back-end pool of the load balancer. To learn more about IPv6 support in Azure virtual networks, see [What is IPv6 for Azure Virtual Network?](../../virtual-network/ip-services/ipv6-overview.md)

-| **Description** | A public load balancer maps the public IP and port of incoming traffic to the private IP and port of the VM. Load balancer maps traffic the other way around for the response traffic from the VM. You can distribute specific types of traffic across multiple VMs or services by applying load-balancing rules. For example, you can spread the load of web request traffic across multiple web servers.| An internal load balancer distributes traffic to resources that are inside a virtual network. Azure restricts access to the frontend IP addresses of a virtual network that are load balanced. Front-end IP addresses and virtual networks are never directly exposed to an internet endpoint, meaning an internal load balancer can't accept incoming traffic from the internet. Internal line-of-business applications run in Azure and are accessed from within Azure or from on-premises resources. |

-By creating a load balancer rule, you can distribute inbound traffic flows from a load balancer's frontend to its backend pools. Azure Load Balancer uses a five-tuple hashing algorithm for the distribution of inbound flows (not bytes). Load balancer rewrites the headers of TCP/UDP headers flows when directing traffic to the backend pool instances (load balancer doesn't rewrite HTTP/HTTPS headers). When the load balancer's health probe indicates a healthy back-end endpoint, backend instances are available to receive new traffic flows.

-Load balancer operates on layer 4 and doesn't provide application layer gateway functionality. Protocol handshakes always occur directly between the client and the back-end pool instance. Because the load balancer doesn't interact with the TCP payload nor does it provide TLS offload, you can build comprehensive encrypted scenarios. Using load balancer gains large scale-out for TLS applications by ending the TLS connection on the VM itself. For example, your TLS session keying capacity is only limited by the type and number of VMs you add to the back-end pool.

-A response to an inbound flow is always a response from a virtual machine. When the flow arrives on the virtual machine, the original source IP address is also preserved. Every endpoint is answered by a VM. For example, a TCP handshake occurs between the client and the selected back-end VM. A response to a request to a front end is a response generated by a back-end VM. When you successfully validate connectivity to a front end, you're validating the connectivity throughout to at least one back-end virtual machine.

-Individual inbound NAT rules can't be added to a Virtual Machine Scale Set. However, you can add a set of inbound NAT rules with a defined front-end port range and back-end port for all instances in the Virtual Machine Scale Set.

-The new inbound NAT rule can't have an overlapping front-end port range with existing inbound NAT rules. To view existing inbound NAT rules that are set up, use [az network lb inbound-nat-rule show](/cli/azure/network/lb/inbound-nat-rule#az-network-lb-inbound-nat-rule-show) as follows:

-This article provides a list of IPv6 configuration tasks with the portion of the Azure Resource Manager VM template that applies to. Use the template described in this article to deploy a dual stack (IPv4 + IPv6) application using Standard Load Balancer in Azure that includes a dual stack virtual network with IPv4 and IPv6 subnets, a Standard Load Balancer with dual (IPv4 + IPv6) front-end configurations, VMs with NICs that have a dual IP configuration, network security group, and public IPs.

-### IPv6 Back-end address pool for Load Balancer

-This article shows you how to deploy a dual stack (IPv4 + IPv6) application in Azure that includes a dual stack virtual network and subnet, a Standard Internal Load Balancer with dual (IPv4 + IPv6) front-end configurations, VMs with NICs that have a dual IP configuration, network security group, and public IPs.

-The procedure to create an IPv6-capable Internal Load Balancer is nearly identical to the process for creating an Internet-facing IPv6 Load Balancer described [here](virtual-network-ipv4-ipv6-dual-stack-standard-load-balancer-powershell.md). The only differences for creating an internal load balancer are in the front-end configuration as illustrated in the PowerShell example below:

-The changes that make the above an internal load balancer front-end configuration are:

-In this section, you configure dual frontend IP (IPv4 and IPv6) and the back-end address pool for the load balancer and then create a Standard Load Balancer.

-### Create front-end IP

-Create a front-end IP with [New-AzLoadBalancerFrontendIpConfig](/powershell/module/az.network/new-azloadbalancerfrontendipconfig). The following example creates IPv4 and IPv6 frontend IP configurations named *dsLbFrontEnd_v4* and *dsLbFrontEnd_v6*:

-### Configure back-end address pool

-Create a back-end address pool with [New-AzLoadBalancerBackendAddressPoolConfig](/powershell/module/az.network/new-azloadbalancerbackendaddresspoolconfig). The VMs attach to this back-end pool in the remaining steps. The following example creates back-end address pools named *dsLbBackEndPool_v4* and *dsLbBackEndPool_v6* to include VMs with both IPV4 and IPv6 NIC configurations:

-In this article, you created a Standard Load Balancer with a dual frontend IP configuration (IPv4 and IPv6). You also created a two virtual machines that included NICs with dual IP configurations (IPV4 + IPv6) that were added to the back-end pool of the load balancer. To learn more about IPv6 support in Azure virtual networks, see [What is IPv6 for Azure Virtual Network?](../virtual-network/ip-services/ipv6-overview.md)

-The HA ports load-balancing rules are configured when you set the front-end and back-end ports to **0** and the protocol to **All**. The internal load balancer resource then balances all TCP and UDP flows, regardless of port number

-This configuration doesn't allow any other load-balancing rule configuration on the current load balancer resource. It also allows no other internal load balancer resource configuration for the given set of back-end instances.

-However, you can configure a public Standard Load Balancer for the back-end instances in addition to this HA ports rule.

-* **Front-end IP configuration**: Contains public IP addresses for incoming network traffic.

-* **Back-end address pool**: Contains network interfaces (NICs) for the virtual machines to receive network traffic from the load balancer.

-* **Load balancing rules**: Contains rules that map a public port on the load balancer to a port in the back-end address pool.

-* **Inbound NAT rules**: Contains network address translation (NAT) rules that map a public port on the load balancer to a port for a specific virtual machine in the back-end address pool.

-* **Probes**: Contains health probes that are used to check the availability of virtual machine instances in the back-end address pool.

-## Create public IP addresses for the front-end pool

-2. Create a public IP address for the front-end IP pool:

-## Create front-end and back-end pools

-* The front-end IP pool that receives the incoming network traffic on the load balancer.

-* The back-end IP pool where the front-end pool sends the load-balanced network traffic.

-2. Create a front-end IP pool, and associate it with the public IP that you created in the previous step and the load balancer.

-* A load balancer rule to balance all incoming traffic on port 80 to port 80 on the addresses in the back-end pool.

- The following example creates a TCP probe that checks for connectivity to the back-end TCP port 80 every 15 seconds. After two consecutive failures, it marks the back-end resource as unavailable.

-3. Create inbound NAT rules that allow RDP connections to the back-end resources:

-4. Create load balancer rules that send traffic to different back-end ports, depending on the front end that received the request.

-## Create the back-end VM resources, and attach each NIC

-* Load balancing rules - contains rules mapping a public port on the load balancer to port in the back-end address pool.

-* Inbound NAT rules - contains rules mapping a public port on the load balancer to a port for a specific virtual machine in the back-end address pool.

-* Probes - contains health probes used to check availability of virtual machines instances in the back-end address pool.

-## Create a virtual network and a public IP address for the front-end IP pool

-2. Create Azure Public IP address (PIP) resources for the front-end IP address pool. Be sure to change the value for `-DomainNameLabel` before running the following commands. The value must be unique within the Azure region.

-## Create a Front-End IP configurations and a Back-End Address Pool

-1. Create front-end address configuration that uses the Public IP addresses you created.

-2. Create back-end address pools.

-* a load balancer rule to balance all incoming traffic on port 80 to port 80 on the addresses in the back-end pool.

-## Create NICs for the back-end VMs

-> To test connectivity for both an IPv4 and an IPv6 frontend of a Load Balancer, an ICMP ping can be sent to the frontend of the Load Balancer. Note that the IP addresses shown in the diagram are examples of values that you might see. Since the IPv6 addresses are assigned dynamically, the addresses you receive will differ and can vary by region. Also, it is common for the public IPv6 address on the load balancer to start with a different prefix than the private IPv6 addresses in the back-end pool.

-* Attaching a secondary NIC that refers to an IPv6 subnet to a back-end pool is **not supported** for Basic Load Balancer.

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

-A packet matching your deployment's front end and rule is generated periodically. It traverses the region from the source to the host where a VM in the back-end pool is located. The load balancer infrastructure performs the same load balancing and translation operations as it does for all other traffic. This probe is in-band on your load-balanced endpoint. After the probe arrives on the compute host, where a healthy VM in the back-end pool is located, the compute host generates a response to the probing service. Your VM doesnΓÇÖt see this traffic.

-The bytes and packet counters metric describes the volume of bytes and packets that are sent or received by your service on a per-front-end basis.

- * Apply a filter on a specific front-end IP, front-end port, back-end IP, or back-end port.

-After the scale set has been created, the back-end port can't be modified for a load-balancing rule used by a health probe of the load balancer. To change the port, remove the health probe by updating the virtual machine scale set and updating the port. Then configure the health probe again.

-When you use the Virtual Machine Scale Set in the back-end pool of the load balancer, the default inbound NAT rules are created automatically.

-When you use the Virtual Machine Scale Set in the back-end pool of the load balancer, the default load-balancing rule is created automatically.

-To create an outbound rule for a back-end pool that's already referenced by a load-balancing rule, select **No** under **Create implicit outbound rules** in the Azure portal when the inbound load-balancing rule is created.

-## Cause 1: You have session persistence configured

-## Cause 2: You have a proxy configured

-## Cause 1: A load balancer backend pool VM isn't listening on the data port

-## Cause 2: A network security group is blocking the port on the load balancer backend pool VM 

-## Cause 3: Access of the internal load balancer from the same VM and network interface

-## Cause 4: Access of the internal load balancer frontend from the participating load balancer backend pool VM

-A side effect is that if an outbound flow from a VM in the back-end pool attempts a flow to front end of the internal load balancer in its pool _and_ is mapped back to itself, the two legs of the flow don't match. Because they don't match, the flow fails. The flow succeeds if the flow didn't map back to the same VM in the back-end pool that created the flow to the front end.

-When the flow maps back to itself, the outbound flow appears to originate from the VM to the front end, and the corresponding inbound flow appears to originate from the VM to itself. From the guest operating system's point of view, the inbound and outbound parts of the same flow don't match inside the virtual machine. The TCP stack won't recognize these halves of the same flow as being part of the same flow. The source and destination don't match. When the flow maps to any other VM in the back-end pool, the halves of the flow do match and the VM can respond to the flow.