+>[!NOTE]

+>As users go through their regular sign-in, Conditional Access policies that govern security info registration apply before the user is prompted to set up Authenticator. For example, if a Conditional Access policy requires security info updates can only occur on an internal network, then users won't be prompted to set up Authenticator unless they are on the internal network.

+

+ Title: Microsoft identity platform authentication protocols

+description: An overview of the authentication protocols supported by the Microsoft identity platform

+# Microsoft identity platform authentication protocols

+The Microsoft identity platform supports several of the most widely used authentication and authorization protocols. The topics in this section describe the supported protocols and their implementation in Microsoft identity platform. The topics included a review of supported claim types, an introduction to the use of federation metadata, detailed OAuth 2.0. and SAML 2.0 protocol reference documentation, and a troubleshooting section.

+## Authentication protocols articles and reference

+* [Important Information About Signing Key Rollover in Microsoft identity platform](active-directory-signing-key-rollover.md) ΓÇô Learn about Microsoft identity platformΓÇÖs signing key rollover cadence, changes you can make to update the key automatically, and discussion for how to update the most common application scenarios.

+* [Supported Token and Claim Types](id-tokens.md) - Learn about the claims in the tokens that the Microsoft identity platform issues.

+* [OAuth 2.0 in Microsoft identity platform](v2-oauth2-auth-code-flow.md) - Learn about the implementation of OAuth 2.0 in Microsoft identity platform.

+* [OpenID Connect 1.0](v2-protocols-oidc.md) - Learn how to use OAuth 2.0, an authorization protocol, for authentication.

+* [Service to Service Calls with Client Credentials](v2-oauth2-client-creds-grant-flow.md) - Learn how to use OAuth 2.0 client credentials grant flow for service to service calls.

+* [Service to Service Calls with On-Behalf-Of Flow](v2-oauth2-on-behalf-of-flow.md) - Learn how to use OAuth 2.0 On-Behalf-Of flow for service to service calls.

+* [SAML Protocol Reference](active-directory-saml-protocol-reference.md) - Learn about the Single Sign-On and Single Sign-out SAML profiles of Microsoft identity platform.

+## See also

+* [Microsoft identity platform overview](v2-overview.md)

+* [Active Directory Code Samples](sample-v2-code.md)

+ Title: Microsoft identity platform certificate credentials

+description: This article discusses the registration and use of certificate credentials for application authentication.

+# Microsoft identity platform application authentication certificate credentials

+The Microsoft identity platform allows an application to use its own credentials for authentication anywhere a client secret could be used, for example, in the OAuth 2.0 [client credentials grant](v2-oauth2-client-creds-grant-flow.md) flow and the [on-behalf-of](v2-oauth2-on-behalf-of-flow.md) (OBO) flow.

+One form of credential that an application can use for authentication is a [JSON Web Token](./security-tokens.md#json-web-tokens-and-claims) (JWT) assertion signed with a certificate that the application owns. This is described in the [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) specification for the `private_key_jwt` client authentication option.

+If you're interested in using a JWT issued by another identity provider as a credential for your application, please see [workload identity federation](workload-identity-federation.md) for how to set up a federation policy.

+## Assertion format

+To compute the assertion, you can use one of the many JWT libraries in the language of your choice - [MSAL supports this using `.WithCertificate()`](msal-net-client-assertions.md). The information is carried by the token in its **Header**, **Claims**, and **Signature**.

+### Header

+| Parameter | Remark |

+| | |

+| `alg` | Should be **RS256** |

+| `typ` | Should be **JWT** |

+| `x5t` | Base64url-encoded SHA-1 thumbprint of the X.509 certificate's DER encoding. For example, given an X.509 certificate hash of `84E05C1D98BCE3A5421D225B140B36E86A3D5534` (Hex), the `x5t` claim would be `hOBcHZi846VCHSJbFAs26Go9VTQ` (Base64url). |

+### Claims (payload)

+Claim type | Value | Description

+- | - | -

+`aud` | `https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token` | The "aud" (audience) claim identifies the recipients that the JWT is intended for (here Azure AD) See [RFC 7519, Section 4.1.3](https://tools.ietf.org/html/rfc7519#section-4.1.3). In this case, that recipient is the login server (login.microsoftonline.com).

+`exp` | 1601519414 | The "exp" (expiration time) claim identifies the expiration time on or after which the JWT **must not** be accepted for processing. See [RFC 7519, Section 4.1.4](https://tools.ietf.org/html/rfc7519#section-4.1.4). This allows the assertion to be used until then, so keep it short - 5-10 minutes after `nbf` at most. Azure AD does not place restrictions on the `exp` time currently.

+`iss` | {ClientID} | The "iss" (issuer) claim identifies the principal that issued the JWT, in this case your client application. Use the GUID application ID.

+`jti` | (a Guid) | The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value **must** be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" value is a case-sensitive string. [RFC 7519, Section 4.1.7](https://tools.ietf.org/html/rfc7519#section-4.1.7)

+`nbf` | 1601519114 | The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. [RFC 7519, Section 4.1.5](https://tools.ietf.org/html/rfc7519#section-4.1.5). Using the current time is appropriate.

+`sub` | {ClientID} | The "sub" (subject) claim identifies the subject of the JWT, in this case also your application. Use the same value as `iss`.

+`iat` | 1601519114 | The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. [RFC 7519, Section 4.1.5](https://tools.ietf.org/html/rfc7519#section-4.1.5).

+### Signature

+The signature is computed by applying the certificate as described in the [JSON Web Token RFC7519 specification](https://tools.ietf.org/html/rfc7519).

+## Example of a decoded JWT assertion

+```JSON

+{

+ "alg": "RS256",

+ "typ": "JWT",

+ "x5t": "gx8tGysyjcRqKjFPnd7RFwvwZI0"

+}

+.

+{

+ "aud": "https: //login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/token",

+ "exp": 1484593341,

+ "iss": "97e0a5b7-d745-40b6-94fe-5f77d35c6e05",

+ "jti": "22b3bb26-e046-42df-9c96-65dbd72c1c81",

+ "nbf": 1484592741,

+ "sub": "97e0a5b7-d745-40b6-94fe-5f77d35c6e05"

+}

+.

+"Gh95kHCOEGq5E_ArMBbDXhwKR577scxYaoJ1P{a lot of characters here}KKJDEg"

+```

+## Example of an encoded JWT assertion

+The following string is an example of encoded assertion. If you look carefully, you notice three sections separated by dots (`.`):

+* The first section encodes the *header*

+* The second section encodes the *claims* (payload)

+* The last section is the *signature* computed with the certificates from the content of the first two sections

+```

+"eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJhdWQiOiJodHRwczpcL1wvbG9naW4ubWljcm9zb2Z0b25saW5lLmNvbVwvam1wcmlldXJob3RtYWlsLm9ubWljcm9zb2Z0LmNvbVwvb2F1dGgyXC90b2tlbiIsImV4cCI6MTQ4NDU5MzM0MSwiaXNzIjoiOTdlMGE1YjctZDc0NS00MGI2LTk0ZmUtNWY3N2QzNWM2ZTA1IiwianRpIjoiMjJiM2JiMjYtZTA0Ni00MmRmLTljOTYtNjVkYmQ3MmMxYzgxIiwibmJmIjoxNDg0NTkyNzQxLCJzdWIiOiI5N2UwYTViNy1kNzQ1LTQwYjYtOTRmZS01Zjc3ZDM1YzZlMDUifQ.

+Gh95kHCOEGq5E_ArMBbDXhwKR577scxYaoJ1P{a lot of characters here}KKJDEg"

+```

+## Register your certificate with Microsoft identity platform

+You can associate the certificate credential with the client application in the Microsoft identity platform through the Azure portal using any of the following methods:

+### Uploading the certificate file

+In the **App registrations** tab for the client application:

+1. Select **Certificates & secrets** > **Certificates**.

+2. Click on **Upload certificate** and select the certificate file to upload.

+3. Click **Add**.

+ Once the certificate is uploaded, the thumbprint, start date, and expiration values are displayed.

+### Updating the application manifest

+After acquiring a certificate, compute these values:

+- `$base64Thumbprint` - Base64-encoded value of the certificate hash

+- `$base64Value` - Base64-encoded value of the certificate raw data

+Provide a GUID to identify the key in the application manifest (`$keyId`).

+In the Azure app registration for the client application:

+1. Select **Manifest** to open the application manifest.

+2. Replace the *keyCredentials* property with your new certificate information using the following schema.

+ ```JSON

+ "keyCredentials": [

+ {

+ "customKeyIdentifier": "$base64Thumbprint",

+ "keyId": "$keyid",

+ "type": "AsymmetricX509Cert",

+ "usage": "Verify",

+ "value": "$base64Value"

+ }

+ ]

+ ```

+3. Save the edits to the application manifest and then upload the manifest to Microsoft identity platform.

+ The `keyCredentials` property is multi-valued, so you may upload multiple certificates for richer key management.

+

+## Using a client assertion

+Client assertions can be used anywhere a client secret would be used. For example, in the [authorization code flow](v2-oauth2-auth-code-flow.md), you can pass in a `client_secret` to prove that the request is coming from your app. You can replace this with `client_assertion` and `client_assertion_type` parameters.

+| Parameter | Value | Description|

+|--|-||

+|`client_assertion_type`|`urn:ietf:params:oauth:client-assertion-type:jwt-bearer`| This is a fixed value, indicating that you are using a certificate credential. |

+|`client_assertion`| `JWT` |This is the JWT created above. |

+## Next steps

+The [MSAL.NET library handles this scenario](msal-net-client-assertions.md) in a single line of code.

+The [.NET Core daemon console application using Microsoft identity platform](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2) code sample on GitHub shows how an application uses its own credentials for authentication. It also shows how you can [create a self-signed certificate](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/tree/master/1-Call-MSGraph#optional-use-the-automation-script) using the `New-SelfSignedCertificate` PowerShell cmdlet. You can also use the [app creation scripts](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/blob/master/1-Call-MSGraph/AppCreationScripts-withCert/AppCreationScripts.md) in the sample repo to create certificates, compute the thumbprint, and so on.

+ Title: Configure app multi-instancing

+description: Learn about multi-instancing, which is needed for configuring multiple instances of the same application within a tenant.

+# Configure app multi-instancing

+App multi-instancing refers to the need for the configuration of multiple instances of the same application within a tenant. For example, the organization has multiple accounts, each of which needs a separate service principal to handle instance-specific claims mapping and roles assignment. Or the customer has multiple instances of an application, which doesn't need special claims mapping, but does need separate service principals for separate signing keys.

+## Sign-in approaches

+A user can sign-in to an application one of the following ways:

+- Through the application directly, which is known as service provider (SP) initiated single sign-on (SSO).

+- Go directly to the identity provider (IDP), known as IDP initiated SSO.

+Depending on which approach is used within your organization, follow the appropriate instructions described in this article.

+## SP initiated SSO

+In the SAML request of SP initiated SSO, the `issuer` specified is usually the app ID URI. Utilizing App ID URI doesn't allow the customer to distinguish which instance of an application is being targeted when using SP initiated SSO.

+### Configure SP initiated SSO

+Update the SAML single sign-on service URL configured within the service provider for each instance to include the service principal guid as part of the URL. For example, the general SSO sign-in URL for SAML is `https://login.microsoftonline.com/<tenantid>/saml2`, the URL can be updated to target a specific service principal, such as `https://login.microsoftonline.com/<tenantid>/saml2/<issuer>`.

+Only service principal identifiers in GUID format are accepted for the issuer value. The service principal identifiers override the issuer in the SAML request and response, and the rest of the flow is completed as usual. There's one exception: if the application requires the request to be signed, the request is rejected even if the signature was valid. The rejection is done to avoid any security risks with functionally overriding values in a signed request.

+## IDP initiated SSO

+The IDP initiated SSO feature exposes the following settings for each application:

+- An **audience override** option exposed for configuration by using claims mapping or the portal. The intended use case is applications that require the same audience for multiple instances. This setting is ignored if no custom signing key is configured for the application.

+- An **issuer with application id** flag to indicate the issuer should be unique for each application instead of unique for each tenant. This setting is ignored if no custom signing key is configured for the application.

+### Configure IDP initiated SSO

+1. Open any SSO enabled enterprise app and navigate to the SAML single sign-on blade.

+1. Select **Edit** on the **User Attributes & Claims** panel.

+1. Select **Edit** to open the advanced options blade.

+1. Configure both options according to your preferences and then select **Save**.

+## Next steps

+- To learn more about how to configure this policy see [Customize app SAML token claims](active-directory-saml-claims-customization.md)

+ Title: Configure the role claim

+# Configure the role claim

+You can customize the role claim in the access token that is received after an application is authorized. Use this feature if your application expects custom roles in the token. You can create as many roles as you need.

+> This article explains how to create, update, or delete application roles on the service principal using APIs. To use the new user interface for App Roles, see [Add app roles to your application and receive them in the token](howto-add-app-roles-in-azure-ad-apps.md).

+ :::image type="content" source="media/enterprise-app-role-management/record-objectid.png" alt-text="Screenshot that shows how to locate and record the object identifier for the application.":::

+ You can only add new roles after msiam_access for the patch operation. Also, you can add as many roles as your organization needs. The value of these roles is sent as the claim value in the SAML response. To generate the GUID values for the ID of new roles use the web tools, such as the [Online GUID / UUID Generator](https://www.guidgenerator.com/). The appRoles property should represent what was in the request body of the query.

+ :::image type="content" source="media/enterprise-app-role-management/attributes-summary.png" alt-text="Screenshot that shows a display of the list of attributes and claims defined for the application.":::

+ :::image type="content" source="media/enterprise-app-role-management/assign-role.png" alt-text="Screenshot that shows how to assign a role to a user of an application.":::

+ Title: Add app roles and get them from a token

+description: Learn how to add app roles to an application registered in Azure Active Directory. Assign users and groups to these roles, and receive them in the 'roles' claim in the token.

+# Add app roles to your application and receive them in the token

+Role-based access control (RBAC) is a popular mechanism to enforce authorization in applications. RBAC allows administrators to grant permissions to roles rather than to specific users or groups. The administrator can then assign roles to different users and groups to control who has access to what content and functionality.

+By using RBAC with application role and role claims, developers can securely enforce authorization in their apps with less effort.

+Another approach is to use Azure Active Directory (Azure AD) groups and group claims as shown in the [active-directory-aspnetcore-webapp-openidconnect-v2](https://aka.ms/groupssample) code sample on GitHub. Azure AD groups and application roles aren't mutually exclusive; they can be used together to provide even finer-grained access control.

+## Declare roles for an application

+You define app roles by using the [Azure portal](https://portal.azure.com) during the [app registration process](quickstart-register-app.md). App roles are defined on an application registration representing a service, app or API. When a user signs in to the application, Azure AD emits a `roles` claim for each role that the user or service principal has been granted. This can be used to implement claim-based authorization. App roles can be assigned [to a user or a group of users](../manage-apps/add-application-portal-assign-users.md). App roles can also be assigned to the service principal for another application, or [to the service principal for a managed identity](../managed-identities-azure-resources/how-to-assign-app-role-managed-identity-powershell.md).

+Currently, if you add a service principal to a group, and then assign an app role to that group, Azure AD doesn't add the `roles` claim to tokens it issues.

+App roles are declared using App roles UI in the Azure portal:

+The number of roles you add counts toward application manifest limits enforced by Azure AD. For information about these limits, see the [Manifest limits](./reference-app-manifest.md#manifest-limits) section of [Azure Active Directory app manifest reference](reference-app-manifest.md).

+### App roles UI

+To create an app role by using the Azure portal's user interface:

+1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

+1. If you have access to multiple tenants, use the **Directories + subscriptions** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to switch to the tenant that contains the app registration to which you want to add an app role.

+1. Search for and select **Azure Active Directory**.

+1. Under **Manage**, select **App registrations**, and then select the application you want to define app roles in.

+1. Select **App roles**, and then select **Create app role**.

+ :::image type="content" source="media/howto-add-app-roles-in-apps/app-roles-overview-pane.png" alt-text="An app registration's app roles pane in the Azure portal":::

+1. In the **Create app role** pane, enter the settings for the role. The table following the image describes each setting and their parameters.

+ :::image type="content" source="media/howto-add-app-roles-in-apps/app-roles-create-context-pane.png" alt-text="An app registration's app roles create context pane in the Azure portal":::

+ | Field | Description | Example |

+ | - | -- | -- |

+ | **Display name** | Display name for the app role that appears in the admin consent and app assignment experiences. This value may contain spaces. | `Survey Writer` |

+ | **Allowed member types** | Specifies whether this app role can be assigned to users, applications, or both.<br/><br/>When available to `applications`, app roles appear as application permissions in an app registration's **Manage** section > **API permissions > Add a permission > My APIs > Choose an API > Application permissions**. | `Users/Groups` |

+ | **Value** | Specifies the value of the roles claim that the application should expect in the token. The value should exactly match the string referenced in the application's code. The value can't contain spaces. | `Survey.Create` |

+ | **Description** | A more detailed description of the app role displayed during admin app assignment and consent experiences. | `Writers can create surveys.` |

+ | **Do you want to enable this app role?** | Specifies whether the app role is enabled. To delete an app role, deselect this checkbox and apply the change before attempting the delete operation. | _Checked_ |

+1. Select **Apply** to save your changes.

+## Assign users and groups to roles

+Once you've added app roles in your application, you can assign users and groups to the roles. Assignment of users and groups to roles can be done through the portal's UI, or programmatically using [Microsoft Graph](/graph/api/user-post-approleassignments). When the users assigned to the various app roles sign in to the application, their tokens will have their assigned roles in the `roles` claim.

+To assign users and groups to roles by using the Azure portal:

+1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

+1. In **Azure Active Directory**, select **Enterprise applications** in the left-hand navigation menu.

+1. Select **All applications** to view a list of all your applications. If your application doesn't appear in the list, use the filters at the top of the **All applications** list to restrict the list, or scroll down the list to locate your application.

+1. Select the application in which you want to assign users or security group to roles.

+1. Under **Manage**, select **Users and groups**.

+1. Select **Add user** to open the **Add Assignment** pane.

+1. Select the **Users and groups** selector from the **Add Assignment** pane. A list of users and security groups is displayed. You can search for a certain user or group and select multiple users and groups that appear in the list.

+1. Once you've selected users and groups, select the **Select** button to proceed.

+1. Select **Select a role** in the **Add assignment** pane. All the roles that you've defined for the application are displayed.

+1. Choose a role and select the **Select** button.

+1. Select the **Assign** button to finish the assignment of users and groups to the app.

+Confirm that the users and groups you added appear in the **Users and groups** list.

+## Assign app roles to applications

+Once you've added app roles in your application, you can assign an app role to a client app by using the Azure portal or programmatically by using [Microsoft Graph](/graph/api/user-post-approleassignments).

+When you assign app roles to an application, you create _application permissions_. Application permissions are typically used by daemon apps or back-end services that need to authenticate and make authorized API call as themselves, without the interaction of a user.

+To assign app roles to an application by using the Azure portal:

+1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.

+1. In **Azure Active Directory**, select **App registrations** in the left-hand navigation menu.

+1. Select **All applications** to view a list of all your applications. If your application doesn't appear in the list, use the filters at the top of the **All applications** list to restrict the list, or scroll down the list to locate your application.

+1. Select the application to which you want to assign an app role.

+1. Select **API permissions** > **Add a permission**.

+1. Select the **My APIs** tab, and then select the app for which you defined app roles.

+1. Select **Application permissions**.

+1. Select the role(s) you want to assign.

+1. Select the **Add permissions** button complete addition of the role(s).

+The newly added roles should appear in your app registration's **API permissions** pane.

+### Grant admin consent

+Because these are _application permissions_, not delegated permissions, an admin must grant consent to use the app roles assigned to the application.

+1. In the app registration's **API permissions** pane, select **Grant admin consent for \<tenant name\>**.

+1. Select **Yes** when prompted to grant consent for the requested permissions.

+The **Status** column should reflect that consent has been **Granted for \<tenant name\>**.

+<a name="use-app-roles-in-your-web-api"></a>

+## Usage scenario of app roles

+If you're implementing app role business logic that signs in the users in your application scenario, first define the app roles in **App registrations**. Then, an admin assigns them to users and groups in the **Enterprise applications** pane. These assigned app roles are included with any token that's issued for your application, either access tokens when your app is the API being called by an app or ID tokens when your app is signing in a user.

+If you're implementing app role business logic in an app-calling-API scenario, you have two app registrations. One app registration is for the app, and a second app registration is for the API. In this case, define the app roles and assign them to the user or group in the app registration of the API. When the user authenticates with the app and requests an access token to call the API, a roles claim is included in the token. Your next step is to add code to your web API to check for those roles when the API is called.

+To learn how to add authorization to your web API, see [Protected web API: Verify scopes and app roles](scenario-protected-web-api-verification-scope-app-roles.md).

+## App roles vs. groups

+Though you can use app roles or groups for authorization, key differences between them can influence which you decide to use for your scenario.

+| App roles | Groups |

+| | - |

+| They're specific to an application and are defined in the app registration. They move with the application. | They aren't specific to an app, but to an Azure AD tenant. |

+| App roles are removed when their app registration is removed. | Groups remain intact even if the app is removed. |

+| Provided in the `roles` claim. | Provided in `groups` claim. |

+Developers can use app roles to control whether a user can sign in to an app or an app can obtain an access token for a web API. To extend this security control to groups, developers and admins can also assign security groups to app roles.

+App roles are preferred by developers when they want to describe and control the parameters of authorization in their app themselves. For example, an app using groups for authorization will break in the next tenant as both the group ID and name could be different. An app using app roles remains safe. In fact, assigning groups to app roles is popular with SaaS apps for the same reasons as it allows the SaaS app to be provisioned in multiple tenants.

+## Next steps

+Learn more about app roles with the following resources.

+- Code samples on GitHub

+ - [Add authorization using app roles & roles claims to an ASP\.NET Core web app](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/blob/master/5-WebApp-AuthZ/5-1-Roles/README.md)

+- Reference documentation

+ - [Azure AD app manifest](./reference-app-manifest.md)

+- Video: [Implement authorization in your applications with Microsoft identity platform](https://www.youtube.com/watch?v=LRoc-na27l0) (1:01:15)

+[AAD-Sign-In]: ./media/devhowto-multi-tenant-overview/sign-in-with-microsoft-light.png

+A common pattern in web apps is to use an iframe to embed one app inside another: the top-level frame handles authenticating the user and the application hosted in the iframe can trust that the user is signed in, fetching tokens silently using the implicit flow. However, there are a couple of caveats to this assumption irrespective of whether third-party cookies are enabled or blocked in the browser.

+ Title: How the Microsoft identity platform uses the SAML protocol

+description: This article provides an overview of the single sign-on and Single Sign-Out SAML profiles in Azure Active Directory.

+# How the Microsoft identity platform uses the SAML protocol

+The Microsoft identity platform uses the SAML 2.0 and other protocols to enable applications to provide a single sign-on (SSO) experience to their users. The [SSO](single-sign-on-saml-protocol.md) and [Single Sign-Out](single-sign-out-saml-protocol.md) SAML profiles of Azure Active Directory (Azure AD) explain how SAML assertions, protocols, and bindings are used in the identity provider service.

+The SAML protocol requires the identity provider (Microsoft identity platform) and the service provider (the application) to exchange information about themselves.

+When an application is registered with Azure AD, the app developer registers federation-related information with Azure AD. This information includes the **Redirect URI** and **Metadata URI** of the application.

+The Microsoft identity platform uses the cloud service's **Metadata URI** to retrieve the signing key and the logout URI. This way the Microsoft identity platform can send the response to the correct URL. In the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>;

+- Open the app in **Azure Active Directory** and select **App registrations**

+- Under **Manage**, select **Authentication**. From there you can update the Logout URL.

+Azure AD exposes tenant-specific and common (tenant-independent) SSO and single sign-out endpoints. These URLs represent addressable locations, and aren't only identifiers. You can then go to the endpoint to read the metadata.

+- The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The *\<TenantDomainName>* placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the `contoso.com` tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml

+- The tenant-independent endpoint is located at

+ `https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml`. In this endpoint address, *common* appears instead of a tenant domain name or ID.

+## Next steps

+For information about the federation metadata documents that Azure AD publishes, see [Federation Metadata](../azuread-dev/azure-ad-federation-metadata.md).

+

+

+

+

+`displayName,accountEnabled,operatingSystem,operatingSystemVersion,joinType (trustType),registeredOwners,userNames,mdmDisplayName,isCompliant,registrationTime,approximateLastSignInDateTime,deviceId,isManaged,objectId,profileType,systemLabels,model`

+2. Browse to **Azure Active Directory** > **Groups**, and then select **General** settings.

+ 

+ > [!NOTE]

+ > In November 2023, the setting **Restrict users access to My Groups** will change to **Restrict users ability to see and edit security groups in My Groups.** If the setting is currently set to ΓÇÿYes,ΓÇÖ end users will be able to access My Groups in November 2023, but will not be able to see security groups.

+3. Set **Owners can manage group membership requests in the Access Panel** to **Yes**.

+4. Set **Restrict user ability to access groups features in the Access Panel** to **No**.

+5. Set **Users can create security groups in Azure portals, API or PowerShell** to **Yes** or **No**.

+6. Set **Users can create Microsoft 365 groups in Azure portals, API or PowerShell** to **Yes** or **No**.

+ :::image type="content" source="media/how-to-customize-branding-customers/microsoft-branding.png" alt-text="Screenshot of the Azure AD default Microsoft branding." lightbox="media/how-to-customize-branding-customers/microsoft-branding.png":::

+ :::image type="content" source="media/how-to-customize-branding-customers/microsoft-branding.png" alt-text="Screenshot of the Azure AD default Microsoft branding." lightbox="media/how-to-customize-branding-customers/microsoft-branding.png":::

+In the [previous article](./how-to-single-page-app-vanillajs-prepare-app.md), you created a vanilla JavaScript (JS) single-page application (SPA) and a server to host it. This article shows you how to configure the application to authenticate and authorize users to access protected resources.

+In this tutorial;

+ - Find the `Enter_the_Application_Id_Here` value and replace it with the **Application ID (clientId)** of the app you registered in the Microsoft Entra admin center.

+> [Sign in and sign out of the vanilla JS SPA](./how-to-single-page-app-vanillajs-sign-in-sign-out.md)

+# Tutorial: Prepare a vanilla JavaScript single-page app for authentication in a customer tenant

+In the [previous article](./how-to-single-page-app-vanillajs-prepare-tenant.md), you registered an application and configured user flows in your Azure Active Directory (AD) for customers tenant. This article shows you how to create a vanilla JavaScript (JS) single-page app (SPA) and configure it to sign in and sign out users with your customer tenant.

+In this tutorial;

+> * Create a vanilla JavaScript project in Visual Studio Code

+* Completion of the prerequisites and steps in [Prepare your customer tenant to authenticate a vanilla JavaScript single-page app](how-to-single-page-app-vanillajs-prepare-tenant.md).

+* Although any integrated development environment (IDE) that supports vanilla JS applications can be used, **Visual Studio Code** is recommended for this guide. It can be downloaded from the [Downloads](https://visualstudio.microsoft.com/downloads) page.

+## Create a new vanilla JS project and install dependencies

+#Customer intent: As a developer, I want to learn how to configure a vanilla JavaScript single-page app (SPA) to sign in and sign out users with my Azure Active Directory (AD) for customers tenant.

+# Tutorial: Prepare your customer tenant to authenticate a vanilla JavaScript single-page app

+This tutorial series demonstrates how to build a vanilla JavaScript single-page application (SPA) and prepare it for authentication using the Microsoft Entra admin center. You'll use the [Microsoft Authentication Library for JavaScript](/javascript/api/overview/msal-overview) library to authenticate your app with your Azure Active Directory (Azure AD) for customers tenant. Finally, you'll run the application and test the sign-in and sign-out experiences.

+> * Register a SPA in the Microsoft Entra admin center, and record its identifiers

+> * Grant permissions to the SPA to access the Microsoft Graph API

+> * Associate your SPA with the user flow

+# Tutorial: Add sign-in and sign-out to a vanilla JavaScript single-page app for a customer tenant

+In this tutorial;

+> * Add code to the *https://docsupdatetracker.net/index.html* file to create the user interface

+ padding: .5rem 1rem !important;

+ Title: Tutorial - Handle authentication flows in a React single-page app

+description: Learn how to configure authentication for a React single-page app (SPA) with your Azure Active Directory (AD) for customers tenant.

+#Customer intent: As a developer, I want to learn how to configure a React single-page app (SPA) to sign in and sign out users with my Azure Active Directory (AD) for customers tenant.

+# Tutorial: Handle authentication flows in a React single-page app

+In the [previous article](./how-to-single-page-application-react-prepare-app.md), you created a React single-page app (SPA) and prepared it for authentication with your Azure Active Directory (Azure AD) for customers tenant. In this article, you'll learn how to handle authentication flows in your app by adding components.

+In this tutorial;

+> [!div class="checklist"]

+> * Add a *DataDisplay* component to the app

+> * Add a *ProfileContent* component to the app

+> * Add a *PageLayout* component to the app

+## Prerequisites

+* Completion of the prerequisites and steps in [Prepare an single-page app for authentication](./how-to-single-page-application-react-prepare-app.md).

+## Add components to the application

+Functional components are the building blocks of React apps, and are used to build the sign-in and sign-out experiences in your React SPA.

+### Add the DataDisplay component

+1. Open *src/components/DataDisplay.jsx* and add the following code snippet

+ ```jsx

+ import { Table } from 'react-bootstrap';

+ import { createClaimsTable } from '../utils/claimUtils';

+

+ import '../styles/App.css';

+

+ export const IdTokenData = (props) => {

+ const tokenClaims = createClaimsTable(props.idTokenClaims);

+

+ const tableRow = Object.keys(tokenClaims).map((key, index) => {

+ return (

+ <tr key={key}>

+ {tokenClaims[key].map((claimItem) => (

+ <td key={claimItem}>{claimItem}</td>

+ ))}

+ </tr>

+ );

+ });

+ return (

+ <>

+ <div className="data-area-div">

+ <p>

+ See below the claims in your <strong> ID token </strong>. For more information, visit:{' '}

+ <span>

+ <a href="https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#claims-in-an-id-token">

+ docs.microsoft.com

+ </a>

+ </span>

+ </p>

+ <div className="data-area-div">

+ <Table responsive striped bordered hover>

+ <thead>

+ <tr>

+ <th>Claim</th>

+ <th>Value</th>

+ <th>Description</th>

+ </tr>

+ </thead>

+ <tbody>{tableRow}</tbody>

+ </Table>

+ </div>

+ </div>

+ </>

+ );

+ };

+ ```

+1. Save the file.

+### Add the NavigationBar component

+1. Open *src/components/NavigationBar.jsx* and add the following code snippet

+ ```jsx

+ import { AuthenticatedTemplate, UnauthenticatedTemplate, useMsal } from '@azure/msal-react';

+ import { Navbar, Button } from 'react-bootstrap';

+ import { loginRequest } from '../authConfig';

+

+ export const NavigationBar = () => {

+ const { instance } = useMsal();

+

+ const handleLoginRedirect = () => {

+ instance.loginRedirect(loginRequest).catch((error) => console.log(error));

+ };

+

+ const handleLogoutRedirect = () => {

+ instance.logoutRedirect().catch((error) => console.log(error));

+ };

+

+ /**

+ * Most applications will need to conditionally render certain components based on whether a user is signed in or not.

+ * msal-react provides 2 easy ways to do this. AuthenticatedTemplate and UnauthenticatedTemplate components will

+ * only render their children if a user is authenticated or unauthenticated, respectively.

+ */

+ return (

+ <>

+ <Navbar bg="primary" variant="dark" className="navbarStyle">

+ <a className="navbar-brand" href="/">

+ Microsoft identity platform

+ </a>

+ <AuthenticatedTemplate>

+ <div className="collapse navbar-collapse justify-content-end">

+ <Button variant="warning" onClick={handleLogoutRedirect}>

+ Sign out

+ </Button>

+ </div>

+ </AuthenticatedTemplate>

+ <UnauthenticatedTemplate>

+ <div className="collapse navbar-collapse justify-content-end">

+ <Button onClick={handleLoginRedirect}>Sign in</Button>

+ </div>

+ </UnauthenticatedTemplate>

+ </Navbar>

+ </>

+ );

+ };

+ ```

+1. Save the file.

+### Add the PageLayout component

+1. Open *src/components/PageLayout.jsx* and add the following code snippet

+ ```jsx

+ import { AuthenticatedTemplate } from '@azure/msal-react';

+

+ import { NavigationBar } from './NavigationBar.jsx';

+

+ export const PageLayout = (props) => {

+ /**

+ * Most applications will need to conditionally render certain components based on whether a user is signed in or not.

+ * msal-react provides 2 easy ways to do this. AuthenticatedTemplate and UnauthenticatedTemplate components will

+ * only render their children if a user is authenticated or unauthenticated, respectively.

+ */

+ return (

+ <>

+ <NavigationBar />

+ <br />

+ <h5>

+ <center>Welcome to the Microsoft Authentication Library For React Tutorial</center>

+ </h5>

+ <br />

+ {props.children}

+ <br />

+ <AuthenticatedTemplate>

+ <footer>

+ <center>

+ How did we do?

+ <a

+ href="https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR_ivMYEeUKlEq8CxnMPgdNZUNDlUTTk2NVNYQkZSSjdaTk5KT1o4V1VVNS4u"

+ rel="noopener noreferrer"

+ target="_blank"

+ >

+ {' '}

+ Share your experience!

+ </a>

+ </center>

+ </footer>

+ </AuthenticatedTemplate>

+ </>

+ );

+ }

+ ```

+1. Save the file.

+## Next steps

+> [!div class="nextstepaction"]

+> [Sign in and sign out of the React SPA](./how-to-single-page-application-react-sign-in-out.md)

+In this tutorial;

+1. Create additional folders and files to achieve the following folder structure:

+ ```text

+ reactspalocal

+ Γö£ΓöÇΓöÇΓöÇ public

+ Γöé ΓööΓöÇΓöÇΓöÇ https://docsupdatetracker.net/index.html

+ ΓööΓöÇΓöÇΓöÇsrc

+ Γö£ΓöÇΓöÇΓöÇ components

+ Γöé ΓööΓöÇΓöÇΓöÇ DataDisplay.jsx

+ Γöé ΓööΓöÇΓöÇΓöÇ NavigationBar.jsx

+ Γöé ΓööΓöÇΓöÇΓöÇ PageLayout.jsx

+ ΓööΓöÇΓöÇΓöÇstyles

+ Γöé ΓööΓöÇΓöÇΓöÇ App.css

+ Γöé ΓööΓöÇΓöÇΓöÇ index.css

+ ΓööΓöÇΓöÇΓöÇ utils

+ Γöé ΓööΓöÇΓöÇΓöÇ claimUtils.js

+ ΓööΓöÇΓöÇ App.jsx

+ ΓööΓöÇΓöÇ authConfig.js

+ ΓööΓöÇΓöÇ index.js

+ ```

+## Install app dependencies

+Identity related **npm** packages must be installed in the project to enable user authentication. For project styling, **Bootstrap** is used.

+1. If necessary, navigate to *reactspalocal* and enter the following commands into the terminal to install the `msal` and `bootstrap` packages.

+1. In the *src* folder, open *authConfig.js* and add the following code snippet:

+1. Replace the following values with the values from the Azure admin center:

+> [Configure SPA for authentication](./how-to-single-page-application-react-configure-authentication.md)

+This tutorial series demonstrates how to build a React single-page application (SPA) and prepare it for authentication using the Microsoft Entra admin center. You'll use the [Microsoft Authentication Library for JavaScript](/javascript/api/overview/msal-overview) library to authenticate your app with your Azure Active Directory (Azure AD) for customers tenant. Finally, you'll run the application and test the sign-in and sign-out experiences.

+In this tutorial;

+> * Register a SPA in the Microsoft Entra admin center, and record its identifiers

+> * Create a sign-in and sign-out user flow in the Microsoft Entra admin center

+> * Associate your SPA with the user flow

+In the [previous article](./how-to-single-page-application-react-configure-authentication.md), you created a React single-page app (SPA) in Visual Studio Code and configured it for authentication. This tutorial shows you how to add sign-in and sign-out functionality to the app.

+In this tutorial;

+## Change filename and add function to render authenticated information

+1. Replace the existing code with the following snippet:

+ import { MsalProvider, AuthenticatedTemplate, useMsal, UnauthenticatedTemplate } from '@azure/msal-react';

+ import { Container, Button } from 'react-bootstrap';

+ import { PageLayout } from './components/PageLayout';

+ import { IdTokenData } from './components/DataDisplay';

+ import { loginRequest } from './authConfig';

+

+ import './styles/App.css';

+

+ * Most applications will need to conditionally render certain components based on whether a user is signed in or not.

+ * msal-react provides 2 easy ways to do this. AuthenticatedTemplate and UnauthenticatedTemplate components will

+ * only render their children if a user is authenticated or unauthenticated, respectively. For more, visit:

+ * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/getting-started.md

+ */

+ /**

+ * useMsal is hook that returns the PublicClientApplication instance,

+ * that tells you what msal is currently doing. For more, visit:

+ * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/hooks.md

+ */

+ const { instance } = useMsal();

+ const activeAccount = instance.getActiveAccount();

+

+ const handleRedirect = () => {

+ instance

+ .loginRedirect({

+ ...loginRequest,

+ prompt: 'create',

+ })

+ .catch((error) => console.log(error));

+ };

+ {activeAccount ? (

+ <Container>

+ <IdTokenData idTokenClaims={activeAccount.idTokenClaims} />

+ </Container>

+ ) : null}

+ <Button className="signInButton" onClick={handleRedirect} variant="primary">

+ Sign up

+ </Button>

+

+

+ /**

+ * msal-react is built on the React context API and all parts of your app that require authentication must be

+ * wrapped in the MsalProvider component. You will first need to initialize an instance of PublicClientApplication

+ * then pass this to MsalProvider as a prop. All components underneath MsalProvider will have access to the

+ * PublicClientApplication instance via context as well as all hooks and components provided by msal-react. For more, visit:

+ * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/getting-started.md

+ */

+ const App = ({ instance }) => {

+ <MsalProvider instance={instance}>

+ <PageLayout>

+ </PageLayout>

+ </MsalProvider>

+ };

+

+ export default App;

+To test your application, sign out and sign in again with the user you assigned the roles. Inspect the security token to make sure that it contains the user's role.

+To test your application, sign out, and then sign in again with the user you added to the security group. Inspect the security token to make sure that it contains the user's group membership.

+| Add 50,000 users to at least two groups | Not currently available |

+The backup authentication system automatically provides incremental resilience to tens of thousands of supported non-Microsoft applications based on their authentication patterns. See the appendix for a list of the most [common non-Microsoft applications and their coverage status](#appendix). For an in depth explanation of which authentication patterns are supported, see the article [Understanding Application Support for the backup authentication system](backup-authentication-system-apps.md) article.

+- Native applications using the OAuth 2.0 protocol to access resource applications, such as popular non-Microsoft e-mail and IM clients like: Apple Mail, Aqua Mail, Gmail, Samsung Email, and Spark.

+ Title: Introduction to identity

+description: Learn the fundamental concepts of identity and access management (IAM). Learn about identities, resources, authentication, authorization, permissions, identity providers, and more.

+# Identity and access management (IAM) fundamental concepts

+This article provides fundamental concepts and terminology to help you understand identity and access management (IAM).

+## What is identity and access management (IAM)?

+Identity and access management ensures that the right people, machines, and software components get access to the right resources at the right time. First, the person, machine, or software component proves they're who or what they claim to be. Then, the person, machine, or software component is allowed or denied access to or use of certain resources.

+Here are some fundamental concepts to help you understand identity and access management:

+## Identity

+A digital identity is a collection of unique identifiers or attributes that represent a human, software component, machine, asset, or resource in a computer system. An identifier can be:

+- An email address

+- Sign-in credentials (username/password)

+- Bank account number

+- Government issued ID

+- MAC address or IP address

+Identities are used to authenticate and authorize access to resources, communicate with other humans, conduct transactions, and other purposes.

+At a high level, there are three types of identities:

+- **Human identities** represent people such as employees (internal workers and front line workers) and external users (customers, consultants, vendors, and partners).

+- **Workload identities** represent software workloads such as an application, service, script, or container.

+- **Device identities** represent devices such as desktop computers, mobile phones, IoT sensors, and IoT managed devices. Device identities are distinct from human identities.

+## Authentication

+Authentication is the process of challenging a person, software component, or hardware device for credentials in order to verify their identity, or prove they're who or what they claim to be. Authentication typically requires the use of credentials (like username and password, fingerprints, certificates, or one-time passcodes). Authentication is sometimes shortened to *AuthN*.

+Multi-factor authentication (MFA) is a security measure that requires users to provide more than one piece of evidence to verify their identities, such as:

+- Something they know, for example a password.

+- Something they have, like a badge or [security token](/azure/active-directory/develop/security-tokens).

+- Something they are, like a biometric (fingerprint or face).

+Single sign-on (SSO) allows users to authenticate their identity once and then later silently authenticate when accessing various resources that rely on the same identity. Once authenticated, the IAM system acts as the source of identity truth for the other resources available to the user. It removes the need for signing on to multiple, separate target systems.

+## Authorization

+Authorization validates that the user, machine, or software component has been granted access to certain resources. Authorization is sometimes shortened to *AuthZ*.

+## Authentication vs. authorization

+The terms authentication and authorization are sometimes used interchangeably, because they often seem like a single experience to users. They're actually two separate processes:

+- Authentication proves the identity of a user, machine, or software component

+- Authorization grants or denies the user, machine, or software component access to certain resources

+Here's a quick overview of authentication and authorization:

+| Authentication | Authorization |

+| - | -- |

+| Can be thought of as a gatekeeper, allowing access only to those who provide valid credentials. | Can be thought of as a guard, ensuring that only those with the proper clearance can enter certain areas. |

+| Verifies whether a user, machine, or software is who or what they claim to be.| Determines if the user, machine, or software is allowed to access a particular resource. |

+| Challenges the user, machine, or software for verifiable credentials (for example, passwords, biometric identifiers, or certificates).| Determines what level of access a user, machine, or software has.|

+| Done before authorization. | Done after successful authentication. |

+| Information is transferred in an ID token. | Information is transferred in an access token. |

+| Often uses the OpenID Connect (OIDC) (which is built on the OAuth 2.0 protocol) or SAML protocols. | Often uses the OAuth 2.0 protocol. |

+For more detailed information, read [Authentication vs. authorization](/azure/active-directory/develop/authentication-vs-authorization).

+### Example

+Suppose you want to spend the night in a hotel. You can think of authentication and authorization as the security system for the hotel building. Users are people who want to stay at the hotel, resources are the rooms or areas that people want to use. Hotel staff is another type of user.

+If you're staying at the hotel, you first go to reception to start the "authentication process". You show an identification card and credit card and the receptionist matches your ID against the online reservation. After the receptionist has verified who you are, the receptionist grants you permission to access the room you've been assigned. You're given a keycard and can go now to your room.

+The doors to the hotel rooms and other areas have keycard sensors. Swiping the keycard in front of a sensor is the "authorization process". The keycard only lets you open the doors to rooms you're permitted to access, such as your hotel room and the hotel exercise room. If you swipe your keycard to enter any other hotel guest room, your access is denied. Individual [permissions](/azure/active-directory/fundamentals/users-default-permissions?context=/azure/active-directory/roles/context/ugr-context), such as accessing the exercise room and a specific guest room, are collected into [roles](/azure/active-directory/roles/concept-understand-roles) which can be granted to individual users. When you're staying at the hotel, you're granted the Hotel Patron role. Hotel room service staff would be granted the Hotel Room Service role. This role permits access to all hotel guest rooms (but only between 11am and 4pm), the laundry room, and the supply closets on each floor.

+## Identity provider

+An identity provider creates, maintains, and manages identity information while offering authentication, authorization, and auditing services.

+With modern authentication, all services, including all authentication services, are supplied by a central identity provider. Information that's used to authenticate the user with the server is stored and managed centrally by the identity provider.

+With a central identity provider, organizations can establish authentication and authorization policies, monitor user behavior, identify suspicious activities, and reduce malicious attacks.

+[Microsoft Azure Active Directory](/azure/active-directory/) is an example of a cloud-based identity provider. Other examples include Twitter, Google, Amazon, LinkedIn, and GitHub.

+## Next steps

+- Read [Introduction to identity and access management](introduction-identity-access-management.md) to learn more.

+- Learn about [Single sign-on (SSO)](/azure/active-directory/manage-apps/what-is-single-sign-on).

+- Learn about [Multi-factor authentication (MFA)](/azure/active-directory/authentication/concept-mfa-howitworks).

+In addition, the recommended actions:

+* Protect all users with a user risk policy

+* Protect all users with a sign-in risk policy

+Also won't give you credits when configured using Conditional Access Policies, yet, for the same reason as above. For now, these actions give credits only when configured through Identity Protection policies.

+ Title: What is identity and access management (IAM)?

+description: Learn what identity and access management (IAM) is, why it's important, and how it works. Learn about authentication and authorization, single sign-on (SSO), and multi-factor authentication (MFA). Learn about SAML, Open ID Connect (OIDC), and OAuth 2.0 and other authentication and authorization standards, tokens, and more.

+# What is identity and access management (IAM)?

+In this article, you learn some of the fundamental concepts of Identity and Access Management (IAM), why it's important, and how it works.

+Identity and access management ensures that the right people, machines, and software components get access to the right resources at the right time. First, the person, machine, or software component proves they're who or what they claim to be. Then, the person, machine, or software component is allowed or denied access to or use of certain resources.

+To learn about the basic terms and concepts, see [Identity fundamentals](identity-fundamentals.md).

+## What does IAM do?

+IAM systems typically provide the following core functionality:

+- **Identity management** - The process of creating, storing, and managing identity information. Identity providers (IdP) are software solutions that are used to track and manage user identities, as well as the permissions and access levels associated with those identities.

+- **Identity federation** - You can allow users who already have passwords elsewhere (for example, in your enterprise network or with an internet or social identity provider) to get access to your system.

+- **Provisioning and deprovisioning of users** - The process of creating and managing user accounts, which includes specifying which users have access to which resources, and assigning permissions and access levels.

+- **Authentication of users** - Authenticate a user, machine, or software component by confirming that they're who or what they say they are. You can add multi-factor authentication (MFA) for individual users for extra security or single sign-on (SSO) to allow users to authenticate their identity with one portal instead of many different resources.

+- **Authorization of users** - Authorization ensures a user is granted the exact level and type of access to a tool that they're entitled to. Users can also be portioned into groups or roles so large cohorts of users can be granted the same privileges.

+- **Access control** - The process of determining who or what has access to which resources. This includes defining user roles and permissions, as well as setting up authentication and authorization mechanisms. Access controls regulate access to systems and data.

+- **Reports and monitoring** - Generate reports after actions taken on the platform (like sign-in time, systems accessed, and type of authentication) to ensure compliance and assess security risks. Gain insights into the security and usage patterns of your environment.

+## How IAM works

+This section provides an overview of the authentication and authorization process and the more common standards.

+### Authenticating, authorizing, and accessing resources

+Let's say you have an application that signs in a user and then accesses a protected resource.

+1. The user (resource owner) initiates an authentication request with the identity provider/authorization server from the client application.

+1. If the credentials are valid, the identity provider/authorization server first sends an ID token containing information about the user back to the client application.

+1. The identity provider/authorization server also obtains end-user consent and grants the client application authorization to access the protected resource. Authorization is provided in an access token, which is also sent back to the client application.

+1. The access token is attached to subsequent requests made to the protected resource server from the client application.

+1. The identity provider/authorization server validates the access token. If successful the request for protected resources is granted, and a response is sent back to the client application.

+For more information, read [Authentication and authorization](/azure/active-directory/develop/authentication-vs-authorization#authentication-and-authorization-using-the-microsoft-identity-platform).

+### Authentication and authorization standards

+These are the most well-known and commonly used authentication and authorization standards:

+#### OAuth 2.0

+OAuth is an open-standards identity management protocol that provides secure access for websites, mobile apps, and Internet of Things and other devices. It uses tokens that are encrypted in transit and eliminates the need to share credentials. OAuth 2.0, the latest release of OAuth, is a popular framework used by major social media platforms and consumer services, from Facebook and LinkedIn to Google, PayPal, and Netflix. To learn more, read about [OAuth 2.0 protocol](/azure/active-directory/develop/active-directory-v2-protocols).

+#### OpenID Connect (OIDC)

+With the release of the OpenID Connect (which uses public-key encryption), OpenID became a widely adopted authentication layer for OAuth. Like SAML, OpenID Connect (OIDC) is widely used for single sign-on (SSO), but OIDC uses REST/JSON instead of XML. OIDC was designed to work with both native and mobile apps by using REST/JSON protocols. The primary use case for SAML, however, is web-based apps. To learn more, read about [OpenID Connect protocol](/azure/active-directory/develop/active-directory-v2-protocols).

+#### JSON web tokens (JWTs)

+JWTs are an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWTs can be verified and trusted because theyΓÇÖre digitally signed. They can be used to pass the identity of authenticated users between the identity provider and the service requesting the authentication. They also can be authenticated and encrypted. To learn more, read [JSON Web Tokens](/azure/active-directory/develop/active-directory-v2-protocols#tokens).

+#### Security Assertion Markup Language (SAML)

+SAML is an open standard utilized for exchanging authentication and authorization information between, in this case, an IAM solution and another application. This method uses XML to transmit data and is typically the method used by identity and access management platforms to grant users the ability to sign in to applications that have been integrated with IAM solutions. To learn more, read [SAML protocol](/azure/active-directory/develop/active-directory-saml-protocol-reference).

+#### System for Cross-Domain Identity Management (SCIM)

+Created to simplify the process of managing user identities, SCIM provisioning allows organizations to efficiently operate in the cloud and easily add or remove users, benefitting budgets, reducing risk, and streamlining workflows. SCIM also facilitates communication between cloud-based applications. To learn more, read [Develop and plan provisioning for a SCIM endpoint](/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups?toc=/azure/active-directory/develop/toc.json&bc=/azure/active-directory/develop/breadcrumb/toc.json).

+#### Web Services Federation (WS-Fed)

+WS-Fed was developed by Microsoft and used extensively in their applications, this standard defines the way security tokens can be transported between different entities to exchange identity and authorization information. To learn more, read Web Services Federation Protocol.

+## Next steps

+To learn more, see:

+- [Single sign-on (SSO)](/azure/active-directory/manage-apps/what-is-single-sign-on)

+- [Multi-factor authentication (MFA)](/azure/active-directory/authentication/concept-mfa-howitworks)

+- [Authentication vs authorization](/azure/active-directory/develop/authentication-vs-authorization)

+- [OAuth 2.0 and OpenID Connect](/azure/active-directory/develop/active-directory-v2-protocols)

+- [App types and authentication flows](/azure/active-directory/develop/authentication-flows-app-scenarios)

+- [Security tokens](/azure/active-directory/develop/security-tokens)

+|[My Groups experience](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|May 2023|

+|[My Apps browser extension](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|May 2023|

+## Choose the right sync client

+To determine if cloud sync is right for your organization, use the link below. It will take you to a tool that will help you evaluate your synchronization needs. For more information, evaluate your options using the [Wizard to evaluate sync options](https://aka.ms/EvaluateSyncOptions)

+ 

+You can begin the process of connecting your Markit environment to Azure AD provisioning by reaching out to the [Markit support team](mailto:support@markit.eu) or directly with your Markit account manager. You're provided a document that contains your **Tenant URL**, along with a **Secret Token**. Markit account managers can assist you with setting up this integration and are available to answer any questions about its configuration or use.

+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users in Markit Procurement Service based on user assignments in Azure AD.

+1. Uncheck **Create** checkbox. Markit recommends unchecking the create option. By unchecking create options, users are created on demand during first time user login.

+ 

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. Determine what data to [map between Azure AD and Zoom](../app-provisioning/customize-application-attributes.md).

+1. Navigate to **Manage** in the top-right corner of the page.

+1. Navigate to your created Azure AD app.

+ > If you don't have an Azure AD app already created, then have a [JWT type Azure AD app](https://developers.zoom.us/docs/platform/build/jwt-app/) created.

+1. Select **App Credentials** in the left navigation pane.

+1. Copy and save the **JWT Token**. This value will be entered in the **Secret Token** field in the Provisioning tab of your Zoom application in the Azure portal. If you need a new non-expiring token, you will need to reconfigure the expiration time which will auto generate a new token.

+ 

+1. In the applications list, select **Zoom**.

+ 

+1. Select the **Provisioning** tab.

+1. Set the **Provisioning Mode** to **Automatic**.

+1. Under the **Admin Credentials** section, select desired **Authentication Method**.

+ * If the Authentication Method is **OAuth2 Authorization Code Grant**, enter `https://api.zoom.us/scim` in **Tenant URL**, click on **Authorize**, make sure that you enter your Zoom account's Admin credentials. Click **Test Connection** to ensure Azure AD can connect to Zoom. If the connection fails, ensure your Zoom account has Admin permissions and try again.

+ 

+ * If the Authentication Method is **Bearer Authentication**, enter `https://api.zoom.us/scim` in **Tenant URL**. Input the **JWT Token** value retrieved earlier in **Secret Token**. Click **Test Connection** to ensure Azure AD can connect to Zoom. If the connection fails, ensure your Zoom account has Admin permissions and try again.

+ 

+ > [!NOTE]

+ > You will have two options for your Authentication Method: **Bearer Authentication** and **OAuth2 Authorization Code Grant**. Make sure that you select OAuth2 Authorization Code Grant.

+1. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+ 

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Zoom**.

+1. Review the user attributes that are synchronized from Azure AD to Zoom in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Zoom for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the Zoom API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+1. To configure scoping filters, refer to the following instructions provided in the [Screenshot of the Scoping filter tutorial.](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Zoom, change the **Provisioning Status** to **On** in the **Settings** section.

+ 

+1. Define the users and/or groups that you would like to provision to Zoom by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you are ready to provision, click **Save**.

+ 

+* 10/20/2020 - Added support for two new roles **Licensed** and **on-premises** to replace existing roles **Pro** and **Corp**. Support for roles **Pro** and **Corp** will be removed in the future.

+* 05/30/2023 - Added support for new authentication method i.e. **OAuth 2.0**.

+#### Install the aks-preview Azure CLI extension

+* Install or update the aks-preview Azure CLI extension using the [`az extension add`][az-extension-add] or the [`az extension update`][az-extension-update] command.

+ ```azurecli

+ # Install the aks-preview extension

+ az extension add --name aks-preview

+ # Update to the latest version of the aks-preview extension

+ az extension update --name aks-preview

+ ```

+#### Register the AKSWindows2022Gen2Preview feature flag

+1. Register the AKSWindows2022Gen2Preview feature flag using the [`az feature register`][az-feature-register] command.

+ ```azurecli-interactive

+ az feature register --namespace "Microsoft.ContainerService" --name "AKSWindows2022Gen2Preview"

+ ```

+ It takes a few minutes for the status to show *Registered*.

+2. Verify the registration using the [`az feature show`][az-feature-show] command.

+ ```azurecli-interactive

+ az feature show --namespace "Microsoft.ContainerService" --name "AKSWindows2022Gen2Preview"

+ ```

+3. When the status reflects *Registered*, refresh the registration of the `Microsoft.ContainerService` resource provider using the [`az provider register`][az-provider-register] command.

+ ```azurecli-interactive

+ az provider register --namespace "Microsoft.ContainerService"

+ ```

+#### Add a Windows node pool with a generation 2 VM

+* Add a node pool with generation 2 VMs on Windows using the [`az aks nodepool add`][az-aks-nodepool-add] command.

+ ```azurecli

+ # Sample command

+ az aks nodepool add --resource-group myResourceGroup --cluster-name myAKSCluster --name gen2np

+ --kubernetes-version 1.23.5 --node-vm-size Standard_D32_v4 --os-type Windows --os-sku Windows2022

+ # Default command

+ az aks nodepool add --resource-group myResourceGroup --cluster-name myAKSCluster --name gen2np --os-type Windows --kubernetes-version 1.23.5

+ ```

+* Determine whether you're on generation 1 or generation 2 using the [`az aks nodepool show`][az-aks-nodepool-show] command, and check that the `nodeImageVersion` contains `gen2`.

+ ```azurecli

+ az aks nodepool show

+ ```

+* Check available generation 2 VM sizes using the [`az vm list`][az-vm-list] command.

+ ```azurecli

+ az vm list -skus -l $region

+ ```

+[az-feature-show]: /cli/azure/feature#az_feature_show

+[az-aks-nodepool-add]: /cli/azure/aks/nodepool#az_aks_nodepool_add

+[az-aks-nodepool-show]: /cli/azure/aks/nodepool#az_aks_nodepool_show

+[az-vm-list]: /cli/azure/vm#az_vm_list

+ FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)

+For an overview of options to secure the developer portal, see [Secure access to the API Management developer portal](secure-developer-portal-access.md).

+For an overview of options to secure the developer portal, see [Secure access to the API Management developer portal](secure-developer-portal-access.md).

+For a conceptual overview of API authorization, see [Authentication and authorization to APIs in API Management](authentication-authorization-overview.md).

+For a conceptual overview of API authorization, see [Authentication and authorization to APIs in API Management](authentication-authorization-overview.md).

+ Title: API authentication and authorization - Overview

+description: Learn about authentication and authorization features in Azure API Management to secure access to APIs, including options for OAuth 2.0 authorization.

+# Authentication and authorization to APIs in Azure API Management

+This article is an introduction to a rich, flexible set of features in API Management that help you secure users' access to managed APIs.

+API authentication and authorization in API Management involve securing the end-to-end communication of client apps to the API Management gateway and through to backend APIs. In many customer environments, OAuth 2.0 is the preferred API authorization protocol. API Management supports OAuth 2.0 authorization between the client and the API Management gateway, between the gateway and the backend API, or both independently.

+API Management supports other client-side and service-side authentication and authorization mechanisms that supplement OAuth 2.0 or that are useful when OAuth 2.0 authorization for APIs isn't possible. How you choose from among these options depends on the maturity of your organization's API environment, your security and compliance requirements, and your organization's approach to [mitigating common API threats](mitigate-owasp-api-threats.md).

+> [!IMPORTANT]

+> Securing users' access to APIs is one of many considerations for securing your API Management environment. For more information, see [Azure security baseline for API Management](/security/benchmark/azure/baselines/api-management-security-baseline?toc=%2Fazure%2Fapi-management%2F&bc=%2Fazure%2Fapi-management%2Fbreadcrumb%2Ftoc.json).

+> [!NOTE]

+> Other API Management components have separate mechanisms to secure and restrict user access:

+> * For managing the API Management instance through the Azure control plane, API Management relies on Azure AD and Azure [role-based access control (RBAC)](api-management-role-based-access-control.md).

+> * The API Management developer portal supports [several options](secure-developer-portal-access.md) to facilitate secure user sign-up and sign-in.

+## Authentication versus authorization

+Here's a brief explanation of authentication and authorization in the context of access to APIs:

+* **Authentication** - The process of verifying the identity of a user or app that accesses the API. Authentication may be done through credentials such as username and password, a certificate, or through single sign-on (SSO) or other methods.

+* **Authorization** - The process of determining whether a user or app has permission to access a particular API, often through a token-based protocol such as OAuth 2.0.

+> [!NOTE]

+> To supplement authentication and authorization, access to APIs should also be secured using TLS to protect the credentials or tokens that are used for authentication or authorization.

+## OAuth 2.0 concepts

+[OAuth 2.0](https://oauth.net/2) is a standard authorization framework that is widely used to secure access to resources such as web APIs. OAuth 2.0 restricts actions of what a client app can perform on resources on behalf of the user, without ever sharing the user's credentials. While OAuth 2.0 isn't an authentication protocol, it's often used with OpenID Connect (OIDC), which extends OAuth 2.0 by providing user authentication and SSO functionality.

+### OAuth flow

+What happens when a client app calls an API with a request that is secured using TLS and OAuth 2.0? The following is an abbreviated example flow:

+* Based on token validation criteria, access to resources of the [backend](backends.md) API is then granted.

+Depending on the type of client app and scenarios, different *authorization flows* are needed to request and manage tokens. For example, the authorization code flow and grant type are commonly used in apps that call web APIs. Learn more about [OAuth flows and application scenarios in Azure AD](../active-directory/develop/authentication-flows-app-scenarios.md).

+## OAuth 2.0 authorization scenarios in API Management

+### Scenario 1 - Client app authorizes directly to backend

+A common authorization scenario is when the calling application requests access to the backend API directly and presents an OAuth 2.0 token in an authorization header to the gateway. Azure API Management then acts as a "transparent" proxy between the caller and backend API, and passes the token through unchanged to the backend. The scope of the access token is between the calling application and backend API.

+The following image shows an example where Azure AD is the authorization provider. The client app might be a single-page application (SPA).

+Although the access token sent along with the HTTP request is intended for the backend API, API Management still allows for a defense in depth approach. For example, configure policies to [validate the JWT](validate-jwt-policy.md), rejecting requests that arrive without a token, or a token that's not valid for the intended backend API. You can also configure API Management to check other claims of interest extracted from the token.

+Example:

+* [Protect an API in Azure API Management using OAuth 2.0 authorization with Azure Active Directory](api-management-howto-protect-backend-with-aad.md)

+> [!TIP]

+> In the special case when API access is protected using Azure AD, you can configure the [validate-azure-ad-token](validate-azure-ad-token-policy.md) policy for token validation.

+### Scenario 2 - Client app authorizes to API Management

+In this scenario, the API Management service acts on behalf of the API, and the calling application requests access to the API Management instance. The scope of the access token is between the calling application and the API Management gateway. In API Management, configure a policy ([validate-jwt](validate-jwt-policy.md) or [validate-azure-ad-token](validate-azure-ad-token-policy.md)) to validate the token before the gateway passes the request to the backend. A separate mechanism typically secures the connection between the gateway and the backend API.

+In the following example, Azure AD is again the authorization provider, and mutual TLS (mTLS) authentication secures the connection between the gateway and the backend.

+There are different reasons for doing this. For example:

+* **The backend is a legacy API that can't be updated to support OAuth**

+ API Management should first be configured to validate the token (checking the issuer and audience claims at a minimum). After validation, use one of several options available to secure onward connections from API Management, such as mutual TLS (mTLS) authentication. See [Service side options](#service-side-options), later in this article.

+* **The context required by the backend isn't possible to establish from the caller**

+ After API Management has successfully validated the token received from the caller, it then needs to obtain an access token for the backend API using its own context, or context derived from the calling application. This scenario can be accomplished using either:

+ * A custom policy such as [send-request](send-request-policy.md) to obtain an onward access token valid for the backend API from a configured identity provider.

+ * The API Management instance's own identity ΓÇô passing the token from the API Management resource's system-assigned or user-assigned [managed identity](authentication-managed-identity-policy.md) to the backend API.

+* **The organization wants to adopt a standardized authorization approach**

+ Regardless of the authentication and authorization mechanisms on their API backends, organizations may choose to converge on OAuth 2.0 for a standardized authorization approach on the front end. API Management's gateway can enable consistent authorization configuration and a common experience for API consumers as the organization's backends evolve.

+### Scenario 3: API management authorizes to backend

+With [API authorizations](authorizations-overview.md), you configure API Management itself to authorize access to one or more backend or SaaS services, such as LinkedIn, GitHub, or other OAuth 2.0-compatible backends. In this scenario, a user or client app makes a request to the API Management gateway, with gateway access controlled using an identity provider or other [client side options](#client-side-options). Then, through [policy configuration](get-authorization-context-policy.md), the user or client app delegates backend authentication and authorization to API Management.

+In the following example, a subscription key is used between the client and the gateway, and GitHub is the authorization provider for the backend API.

+With an API authorization, API Management acquires and refreshes the tokens for API access in the OAuth 2.0 flow. Authorizations simplify token management in multiple scenarios, such as:

+* A client app might need to authorize to multiple SaaS backends to resolve multiple fields using GraphQL resolvers.

+* Users authenticate to API Management by SSO from their identity provider, but authorize to a backend SaaS provider (such as LinkedIn) using a common organizational account

+Examples:

+* [Create an authorization with the Microsoft Graph API](authorizations-how-to-azure-ad.md)

+* [Create an authorization with the GitHub API](authorizations-how-to-github.md)

+## Other options to secure APIs

+While authorization is preferred, and OAuth 2.0 has become the dominant method of enabling strong authorization for APIs, API Management provides several other mechanisms to secure or restrict access between client and gateway (client side) or between gateway and backend (service side). Depending on the organization's requirements, these may be used to supplement OAuth 2.0. Alternatively, configure them independently if the calling applications or backend APIs are legacy or don't yet support OAuth 2.0.

+### Client side options

+|Mechanism |Description |Considerations |

+||||

+|[mTLS](api-management-howto-mutual-certificates-for-clients.md) | [Validate certificate](validate-client-certificate-policy.md) presented by the connecting client and check certificate properties against a certificate managed in API Management | Certificate may be stored in a key vault. |

+|[Restrict caller IPs](ip-filter-policy.md) | Filter (allow/deny) calls from specific IP addresses or address ranges. | Use to restrict access to certain users or organizations, or to traffic from upstream services. |

+|[Subscription key](api-management-subscriptions.md) | Limit access to one or more APIs based on an API Management [subscription](api-management-howto-create-subscriptions.md) | We recommend using a subscription (API) key *in addition to* another method of authentication or authorization. On its own, a subscription key isn't a strong form of authentication, but use of the subscription key might be useful in certain scenarios, for example, tracking individual customers' API usage or granting access to specific API products. |

+> [!TIP]

+> For defense in depth, deploying a web application firewall upstream of the API Management instance is strongly recommended. For example, use [Azure Application Gateway](/azure/architecture/reference-architectures/apis/protect-apis) or [Azure Front Door](front-door-api-management.md).

+### Service side options

+|Mechanism |Description |Considerations |

+||||

+|[Managed identity authentication](authentication-managed-identity-policy.md) | Authenticate to backend API with a system-assigned or user-assigned [managed identity](api-management-howto-use-managed-service-identity.md). | Recommended for scoped access to a protected backend resource by obtaining a token from Azure AD. |

+|[Certificate authentication](authentication-certificate-policy.md) | Authenticate to backend API using a client certificate. | Certificate may be stored in key vault. |

+|[Basic authentication](authentication-basic-policy.md) | Authenticate to backend API with username and password that are passed through an Authorization header. | Discouraged if better options are available. |

+- We recommend using [named values](api-management-howto-properties.md) to provide credentials, with secrets protected in a key vault.

+|vary-by-query-parameter|Add one or more of these elements to start caching responses per value of specified query parameters. Enter a single or multiple parameters. Use semicolon as a separator. |No|

+For an overview of options to secure the developer portal, see [Secure access to the API Management developer portal](secure-developer-portal-access.md).

+For a conceptual overview of API authorization, see [Authentication and authorization to APIs in API Management](authentication-authorization-overview.md).

+## Validate against an OpenAPI specification

+You can configure API Management [validation policies](api-management-policies.md#validation-policies) to validate requests and responses (or elements of them) against the schema in an OpenAPI specification. For example, use the [validate-content](validate-content-policy.md) policy to validate the size or content of a request or response body.

+* The maximum size of a policy fragment is 32 KB.

+ Title: Secure access to developer portal

+description: Learn about options to secure access to the API Management developer portal, including Azure AD, Azure AD B2C, and basic authentication

+# Secure access to the API Management developer portal

+API Management has a fully customizable, standalone, managed [developer portal](api-management-howto-developer-portal.md), which can be used externally (or internally) to allow developer users to discover and interact with the APIs published through API Management. The developer portal has several options to facilitate secure user sign-up and sign-in.

+## Authentication options

+* **External users** - The preferred option when the developer portal is consumed externally is to enable business-to-consumer access control through Azure Active Directory B2C (Azure AD B2C).

+ * Azure AD B2C provides the option of using Azure AD B2C native accounts: users sign up to Azure AD B2C and use that identity to access the developer portal.

+ * Azure AD B2C is also useful if you want users to access the developer portal using existing social media or federated organizational accounts.

+ * Azure AD B2C provides many features to improve the end user sign-up and sign-in experience, including conditional access and MFA.

+

+ For steps to enable Azure AD B2C authentication in the developer portal, see [How to authorize developer accounts by using Azure Active Directory B2C in Azure API Management](api-management-howto-aad-b2c.md).

+* **Internal users** - The preferred option when the developer portal is consumed internally is to leverage your corporate Azure AD. Azure AD provides a seamless single sign-on (SSO) experience for corporate users who need to access and discover APIs through the developer portal.

+ For steps to enable Azure AD authentication in the developer portal, see [How to authorize developer accounts by using Azure Active Directory in Azure API Management](api-management-howto-aad.md).

+

+* **Basic authentication** - A default option is to use the built-in developer portal [username and password](developer-portal-basic-authentication.md) provider, which allows developers to register directly in API Management and sign in using API Management user accounts. User sign up through this option is protected by a CAPTCHA service.

+## Developer portal test console

+In addition to providing configuration for developer users to sign up for access and sign in, the developer portal includes a test console where the developers can send test requests through API Management to the backend APIs. This test facility also exists for contributing users of API Management who manage the service using the Azure portal.

+If the API exposed through Azure API Management is secured with OAuth 2.0 - that is, a calling application (*bearer*) needs to obtain and pass a valid access token - you can configure API Management to generate a valid token on behalf of an Azure portal or developer portal test console user. For more information, see [How to authorize test console of developer portal by configuring OAuth 2.0 user authorization](api-management-howto-oauth2.md).

+This OAuth 2.0 configuration for API testing is independent of the configuration required for user access to the developer portal. However, the identity provider and user could be the same. For example, an intranet application could require user access to the developer portal using SSO with their corporate identity. That same corporate identity could obtain a token, through the test console, for the backend service being called with the same user context.

+## Scenarios

+Different authentication and authorization options apply to different scenarios. The following sections explore high level configurations for three example scenarios. More steps are required to fully secure and configure APIs exposed through API Management. However, the scenarios intentionally focus on the minimum configurations recommended in each case to provide the required authentication and authorization.

+### Scenario 1 - Intranet API and applications

+* An API Management contributor and backend API developer wants to publish an API that is secured by OAuth 2.0.

+* The API will be consumed by desktop applications whose users sign in using SSO through Azure AD.

+* The desktop application developers also need to discover and test the APIs via the API Management developer portal.

+Key configurations:

+|Configuration |Reference |

+|||

+| Authorize developer users of the API Management developer portal using their corporate identities and Azure AD. | [Authorize developer accounts by using Azure Active Directory in Azure API Management](api-management-howto-aad.md) |

+|Set up the test console in the developer portal to obtain a valid OAuth 2.0 token for the desktop app developers to exercise the backend API. <br/><br/>The same configuration can be used for the test console in the Azure portal, which is accessible to the API Management contributors and backend developers. <br/><br/>The token could be used in combination with an API Management subscription key. | [How to authorize test console of developer portal by configuring OAuth 2.0 user authorization](api-management-howto-oauth2.md)<br/><br/>[Subscriptions in Azure API Management](api-management-subscriptions.md) |

+| Validate the OAuth 2.0 token and claims when an API is called through API Management with an access token. | [Validate JWT policy](validate-jwt-policy.md) |

+Go a step further with this scenario by moving API Management into the network perimeter and controlling ingress through a reverse proxy. For a reference architecture, see [Protect APIs with Application Gateway and API Management](/azure/architecture/reference-architectures/apis/protect-apis).

+

+### Scenario 2 - External API, partner application

+* An API Management contributor and backend API developer wants to undertake a rapid proof-of-concept to expose a legacy API through Azure API Management. The API through API Management will be externally (internet) facing.

+* The API uses client certificate authentication and will be consumed by a new public-facing single-page app (SPA) being developed offshore by a partner.

+* The SPA uses OAuth 2.0 with Open ID Connect (OIDC).

+* Application developers will access the API in a test environment through the developer portal, using a test backend endpoint to accelerate frontend development.

+Key configurations:

+|Configuration |Reference |

+|||

+| Configure frontend developer access to the developer portal using the default username and password authentication.<br/><br/>Developers can also be invited to the developer portal. | [Configure users of the developer portal to authenticate using usernames and passwords](developer-portal-basic-authentication.md)<br/><br/>[How to manage user accounts in Azure API Management](api-management-howto-create-or-invite-developers.md) |

+| Validate the OAuth 2.0 token and claims when the SPA calls API Management with an access token. In this case, the audience is API Management. | [Validate JWT policy](validate-jwt-policy.md) |

+| Set up API Management to use client certificate authentication to the backend. | [Secure backend services using client certificate authentication in Azure API Management](api-management-howto-mutual-certificates.md) |

+Go a step further with this scenario by using the [developer portal with Azure AD authorization](api-management-howto-aad.md) and Azure AD [B2B collaboration](../active-directory/external-identities/what-is-b2b.md) to allow the delivery partners to collaborate more closely. Consider delegating access to API Management through RBAC in a development or test environment and enable SSO into the developer portal using their own corporate credentials.

+### Scenario 3 - External API, SaaS, open to the public

+* An API Management contributor and backend API developer is writing several new APIs that will be available to community developers.

+* The APIs will be publicly available, with full functionality protected behind a paywall and secured using OAuth 2.0. After purchasing a license, the developer will be provided with their own client credentials and subscription key that is valid for production use.

+* External community developers will discover the APIs using the developer portal. Developers will sign up and sign in to the developer portal using their social media accounts.

+* Interested developer portal users with a test subscription key can explore the API functionality in a test context, without needing to purchase a license. The developer portal test console will represent the calling application and generate a default access token to the backend API.

+

+ > [!CAUTION]

+ > Extra care is required when using a client credentials flow with the developer portal test console. See [security considerations](api-management-howto-oauth2.md#security-considerations).

+Key configurations:

+|Configuration |Reference |

+|||

+| Set up products in Azure API Management to represent the combinations of APIs that are exposed to community developers.<br/><br/> Set up subscriptions to enable developers to consume the APIs. | [Tutorial: Create and publish a product](api-management-howto-add-products.md)<br/><br/>[Subscriptions in Azure API Management](api-management-subscriptions.md) |

+| Configure community developer access to the developer portal using Azure AD B2C. Azure AD B2C can then be configured to work with one or more downstream social media identity providers. | [How to authorize developer accounts by using Azure Active Directory B2C in Azure API Management](api-management-howto-aad-b2c.md) |

+| Set up the test console in the developer portal to obtain a valid OAuth 2.0 token to the backend API using the client credentials flow. | [How to authorize test console of developer portal by configuring OAuth 2.0 user authorization](api-management-howto-oauth2.md)<br/><br/>Adjust configuration steps shown in this article to use the [client credentials grant flow](../active-directory/develop/v2-oauth2-client-creds-grant-flow.md) instead of the authorization code grant flow. |

+Go a step further by delegating [user registration or product subscription](api-management-howto-setup-delegation.md) and extend the process with your own logic.

+## Next steps

+* Learn more about [authentication and authorization](../active-directory/develop/authentication-vs-authorization.md) in the Microsoft identity platform.

+* Learn how to [mitigate OWASP API security threats](mitigate-owasp-api-threats.md) using API Management.

+ Title: Reference - Self-hosted gateway Azure Arc settings - Azure API Management

+description: Reference for the required and optional settings to configure when using the Azure Arc extension for Azure API Management self-hosted gateway.

+# Reference: Self-hosted gateway Azure Arc configuration settings

+This article provides a reference for required and optional settings that are used to configure the Azure Arc extension for API Management [self-hosted gateway container](self-hosted-gateway-overview.md).

+## Configuration API integration

+The Configuration API is used by the self-hosted gateway to connect to Azure API Management to get the latest configuration and send metrics, when enabled.

+Here's an overview of all configuration options:

+| Name | Description | Required | Default |

+|-||-|-|

+| `gateway.configuration.uri` | Configuration endpoint in Azure API Management for the self-hosted gateway. Find this value in the Azure portal under **Gateways** > **Deployment**. | Yes | N/A |

+| `gateway.auth.token` | Authentication key to authenticate with to Azure API Management service. Typically starts with `GatewayKey`. | Yes | N/A |

+| `gateway.configuration.backup.enabled` | If enabled will store a backup copy of the latest downloaded configuration on a storage volume | `false` |

+| `gateway.configuration.backup.persistentVolumeClaim.accessMode` | Access mode for the Persistent Volume Claim (PVC) pod | `ReadWriteMany` |

+| `gateway.configuration.backup.persistentVolumeClaim.size` | Size of the Persistent Volume Claim (PVC) to be created | `50Mi` |

+| `gateway.configuration.backup.persistentVolumeClaim.storageClassName` | Storage class name to be used for the Persistent Volume Claim (PVC). When no value is assigned (`null`), the platform default will be used. The specified storage class should support `ReadWriteMany` access mode, learn more about the [supported volume providers and their supported access modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes).| `null` |

+## Cross-instance discovery & synchronization

+| Name | Description | Required | Default |

+|-||-|-|

+| `service.instance.heartbeat.port` | UDP port used for instances of a self-hosted gateway deployment to send heartbeats to other instances. | No | 4291 |

+| `service.instance.synchronization.port` | UDP port used for self-hosted gateway instances to synchronize rate limiting across multiple instances. | No | 4290 |

+## Metrics

+| Name | Description | Required | Default |

+|-||-|-|

+| `telemetry.metrics.cloud` | Indication whether or not to [enable emitting metrics to Azure Monitor](how-to-configure-cloud-metrics-logs.md). | No | `true` |

+| `telemetry.metrics.local` | Enable [local metrics collection](how-to-configure-local-metrics-logs.md) through StatsD. Value is one of the following options: `none`, `statsd`. | No | N/A |

+| `telemetry.metrics.localStatsd.endpoint` | StatsD endpoint. | Yes, if `telemetry.metrics.local` is set to `statsd`; otherwise no. | N/A |

+| `telemetry.metrics.localStatsd.sampling` | StatsD metrics sampling rate. Value must be between 0 and 1, for example, 0.5. | No | N/A |

+| `telemetry.metrics.localStatsd.tagFormat` | StatsD exporter [tagging format](https://github.com/prometheus/statsd_exporter#tagging-extensions). Value is one of the following options: `ibrato`, `dogStatsD`, `influxDB`. | No | N/A |

+| `telemetry.metrics.opentelemetry.enabled` | Indication whether or not to enable [emitting metrics to an OpenTelemetry collector](how-to-deploy-self-hosted-gateway-kubernetes-opentelemetry.md) on Kubernetes. | No | `false` |

+| `telemetry.metrics.opentelemetry.collector.uri` | URI of the OpenTelemetry collector to send metrics to. | Yes, if `observability.opentelemetry.enabled` is set to `true`; otherwise no. | N/A |

+## Logs

+| Name | Description | Required | Default |

+| - | - | - | -|

+| `telemetry.logs.std` |[Enable logging](how-to-configure-local-metrics-logs.md#logs) to a standard stream. Value is one of the following options: `none`, `text`, `json`. | No | `text` |

+| `telemetry.logs.local` | [Enable local logging](how-to-configure-local-metrics-logs.md#logs). Value is one of the following options: `none`, `auto`, `localsyslog`, `rfc5424`, `journal`, `json` | No | `auto` |

+| `telemetry.logs.localConfig.localsyslog.endpoint` | Endpoint for local syslogs | Yes if `telemetry.logs.local` is set to `localsyslog`; otherwise no. | N/A |

+| `telemetry.logs.localConfig.localsyslog.facility` | Specifies local syslog [facility code](https://en.wikipedia.org/wiki/Syslog#Facility), for example, `7`. | No | N/A |

+| `telemetry.logs.localConfig.rfc5424.endpoint` | rfc5424 endpoint. | Yes if `telemetry.logs.local` is set to `rfc5424`; otherwise no. | N/A |

+| `telemetry.logs.localConfig.rfc5424.facility` | Facility code per [rfc5424](https://tools.ietf.org/html/rfc5424), for example, `7` | No | N/A |

+| `telemetry.logs.localConfig.journal.endpoint` | Journal endpoint. |Yes if `telemetry.logs.local` is set to `journal`; otherwise no. | N/A |

+## Traffic routing

+| Name | Description | Required | Default |

+| - | - | - | -|

+| `service.type` | Type of Kubernetes service to use for exposing the gateway. ([docs](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types)) | No | `ClusterIP` |

+| `service.http.port` | Port to use for exposing HTTP traffic. | No | `8080` |

+| `service.http.nodePort` | Port on the node to use for exposing HTTP traffic. This requires `NodePort` as service type. | No | N/A |

+| `service.https.port` | Port to use for exposing HTTPS traffic. | No | `8081` |

+| `service.https.nodePort` | Port on the node to use for exposing HTTPS traffic. This requires `NodePort` as service type. | No | N/A |

+| `service.annotations` | Annotations to add to the Kubernetes service for the gateway. | No | N/A |

+| `ingress.annotations` | Annotations to add to the Kubernetes Ingress for the gateway. ([experimental](https://github.com/Azure/api-management-self-hosted-gateway-ingress)) | No | N/A |

+| `ingress.enabled` | Indication whether or not Kubernetes Ingress should be used. ([experimental](https://github.com/Azure/api-management-self-hosted-gateway-ingress)) | No | `false` |

+| `ingress.tls` | TLS configuration for Kubernetes Ingress. ([experimental](https://github.com/Azure/api-management-self-hosted-gateway-ingress)) | No | N/A |

+| `ingress.hosts` | Configuration of hosts to use for Kubernetes Ingress. ([experimental](https://github.com/Azure/api-management-self-hosted-gateway-ingress)) | No | N/A |

+## Integrations

+The self-hosted gateway integrates with various other technologies. This section provides an overview of the available configuration options you can use.

+### Dapr

+| Name | Description | Required | Default |

+| - | - | - | -|

+| `dapr.enabled` |Indication whether or not Dapr integration should be used. | No | `false` |

+| `dapr.app.id` | Application ID to use for Dapr integration | None |

+| `dapr.config` | Defines which Configuration CRD Dapr should use | `tracing` |

+| `dapr.logging.level` | Level of log verbosity of Dapr sidecar | `info` |

+| `dapr.logging.useJsonOutput` | Indication whether or not logging should be in JSON format | `true` |

+### Azure Monitor

+| Name | Description | Required | Default |

+| - | - | - | -|

+| `monitoring.customResourceId` | Resource ID of the Azure Log Analytics workspace to send logs to. | No | N/A |

+| `monitoring.ingestionKey` | Ingestion key to authenticate with Azure Log Analytics workspace to send logs to. | No | N/A |

+| `monitoring.workspaceId` | Workspace ID of the Azure Log Analytics workspace to send logs to. | No | N/A |

+## Image & workload scheduling

+Kubernetes is a powerful orchestration platform that gives much flexibility in what should be deployed and how it should be scheduled.

+This section provides an overview of the available configuration options you can use to influence the image that is used, how it gets scheduled and configured to self-heal.

+| Name | Description | Required | Default |

+| - | - | - | -|

+| `replicaCount` | Number of instances of the self-hosted gateway to run. | No | `3` |

+| `image.repository` | Image to run. | No | `mcr.microsoft.com/azure-api-management/gateway` |

+| `image.pullPolicy` | Policy to use for pulling container images. | No | `IfNotPresent` |

+| `image.tag` | Container image tag to use. | No | App version of extension is used |

+| `imagePullSecrets` | Kubernetes secret to use for authenticating with container registry when pulling the container image. | No | N/A |

+| `probes.readiness.httpGet.path` | URI path to use for readiness probes of the container | No | `/status-0123456789abcdef` |

+| `probes.readiness.httpGet.port` | Port to use for liveness probes of the container | No | `http` |

+| `probes.liveness.httpGet.path` | URI path to use for liveness probes of the container | No | `/status-0123456789abcdef` |

+| `probes.liveness.httpGet.port` | Port to use for liveness probes of the container | No | `http` |

+| `highAvailability.enabled` | Indication whether or not the gateway should be scheduled highly available in the cluster. | No | `false` |

+| `highAvailability.disruption.maximumUnavailable` | Amount of pods that are allowed to be unavailable due to [voluntary disruptions](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions). | No | `25%` |

+| `highAvailability.podTopologySpread.whenUnsatisfiable` | Indication how pods should be spread across nodes in case the requirement can't be met. Learn more in the [Kubernetes docs](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) | No | `ScheduleAnyway` |

+| `resources` | Capability to define CPU/Memory resources to assign to gateway | No | N/A |

+| `nodeSelector` | Capability to use selectors to identify the node on which the gateway should run. | No | N/A |

+| `affinity` | Affinity for pod scheduling ([docs](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)) | No | N/A |

+| `tolerations` | Tolerations for pod scheduling ([docs](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)) | No | N/A |

+## Next steps

+- Learn more about guidance for [running the self-hosted gateway on Kubernetes in production](how-to-self-hosted-gateway-on-kubernetes-in-production.md)

+- [Deploy self-hosted gateway to Docker](how-to-deploy-self-hosted-gateway-docker.md)

+- [Deploy self-hosted gateway to Kubernetes](how-to-deploy-self-hosted-gateway-kubernetes.md)

+- [Deploy self-hosted gateway to Azure Arc-enabled Kubernetes cluster](how-to-deploy-self-hosted-gateway-azure-arc.md)

+- [Enable Dapr support on self-hosted gateway](self-hosted-gateway-enable-dapr.md)

+- Learn more about configuration options for the [self-hosted gateway container image](self-hosted-gateway-settings-reference.md)

+- Learn more about configuration options for [Azure Arc extension](self-hosted-gateway-arc-reference.md)

+1. Select **Azure Resource Manager** for the **Connection type** and choose your **Azure subscription**. Make sure to **Authorize** your connection.

+ - **Subnet name** (application gateway subnet): The **Subnets** grid will show a subnet named *Default*. Change the name of this subnet to *myAGSubnet*.<br>The application gateway subnet can contain only application gateways. No other resources are allowed. The default IP address range provided is 10.0.0.0/24.

+5. For the **Backend setting**, select **Add new** to add a new Backend setting. The Backend setting will determine the behavior of the routing rule. In the **Add Backend setting** window that opens, enter *contosoSetting* for the **Backend settings name** and *80* for the **Backend port**. Accept the default values for the other settings in the **Add Backend setting** window, then select **Add** to return to the **Add a routing rule** window.

+7. Select **Add a routing rule** and add a similar rule, listener, backend target, and backend setting for Fabrikam.

+1. Add a backend subnet.

+2. Create two new VMs, *contosoVM* and *fabrikamVM*, to be used as backend servers.

+3. Install IIS on the virtual machines to verify that the application gateway was created successfully.

+4. Add the backend servers to the backend pools.

+### Add a backend subnet

+1. On the Azure portal, search for **virtual networks** and select **myVNet*.

+2. Under **Settings**, select **Subnets**.

+3. Select **+ Subnet** and in the **Add subnet** pane, enter *myBackendSubnet* for **Name** and accept *10.0.1.0/24* as the **Subnet address range**.

+4. Accept all other default settings and select **Save**.

+ - **Subnet name** (Application Gateway subnet): The **Subnets** grid will show a subnet named *default*. Change the name of this subnet to *myAGSubnet*.<br>The application gateway subnet can contain only application gateways. No other resources are allowed. The default IP address range provided is 10.0.0.0/24.

+- **Improved performance** ΓÇô The biggest performance hit when doing TLS decryption is the initial handshake. To improve performance, the server doing the decryption caches TLS session IDs and manages TLS session tickets. If this is done at the application gateway, all requests from the same client can use the cached values. If itΓÇÖs done on the backend servers, then each time the clientΓÇÖs requests go to a different server the client must reauthenticate. The use of TLS tickets can help mitigate this issue, but they aren't supported by all clients and can be difficult to configure and manage.

+Application Gateway only communicates with those backend servers that have either allow-listed their certificate with the Application Gateway or whose certificates are signed by well-known CA authorities and the certificate's CN matches the host name in the HTTP backend settings. There are some differences in the end-to-end TLS setup process with respect to the version of Application Gateway used. The following section explains the versions individually.

+> [!TIP]

+> The SNI flag can be configured with PowerShell or by using an ARM template. For more information, see [RequireServerNameIndication](/powershell/module/az.network/set-azapplicationgatewayhttplistener#-requireservernameindication) and [Quickstart: Direct web traffic with Azure Application Gateway - ARM template](quick-create-template.md#review-the-template).

+> [!NOTE]

+> You can set Hotpatch in Windows Server 2022 Datacenter: Azure Edition with Desktop Experience in the Azure portal by getting the VM preview image from [this link](https://ms.portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/microsoftwindowsserver.windowsserverhotpatch-previews/resourceGroupId//resourceGroupLocation//dontDiscardJourney~/false/_provisioningContext~/%7B%22initialValues%22%3A%7B%22subscriptionIds%22%3A%5B%222389fa6a-fd51-4c60-8a9e-95e7e17b76b6%22%2C%221b3510f5-e7cd-457d-a84e-1a0a61013375%22%5D%2C%22resourceGroupNames%22%3A%5B%5D%2C%22locationNames%22%3A%5B%22westus2%22%2C%22centralus%22%2C%22eastus%22%5D%7D%2C%22telemetryId%22%3A%22b73b4782-5eee-41b0-ad74-9a0b98365009%22%2C%22marketplaceItem%22%3A%7B%22categoryIds%22%3A%5B%5D%2C%22id%22%3A%22Microsoft.Portal%22%2C%22itemDisplayName%22%3A%22NoMarketplace%22%2C%22products%22%3A%5B%5D%2C%22version%22%3A%22%22%2C%22productsWithNoPricing%22%3A%5B%5D%2C%22publisherDisplayName%22%3A%22Microsoft.Portal%22%2C%22deploymentName%22%3A%22NoMarketplace%22%2C%22launchingContext%22%3A%7B%22telemetryId%22%3A%22b73b4782-5eee-41b0-ad74-9a0b98365009%22%2C%22source%22%3A%5B%5D%2C%22galleryItemId%22%3A%22%22%7D%2C%22deploymentTemplateFileUris%22%3A%7B%7D%2C%22uiMetadata%22%3Anull%7D%7D). For related information, please refer [this](https://azure.microsoft.com/updates/hotpatch-is-now-available-on-preview-images-of-windows-server-vms-on-azure-with-the-desktop-experience-installation-mode/) Azure update.

+**Applies to:** :heavy_check_mark: Windows VMs :heavy_check_mark: Linux VMs :heavy_check_mark: Windows Registry :heavy_check_mark: Windows Files :heavy_check_mark: Linux Files :heavy_check_mark: Windows Software :heavy_check_mark: Windows Services & Linux Daemons

+- Linux daemons might show a changed state even though no change has occurred. This issue arises because of how the `SvcRunLevels` data in the Azure Monitor [ConfigurationChange](https://learn.microsoft.com/azure/azure-monitor/reference/tables/configurationchange) table is written.

+|Windows Services |250||

+|Linux Daemons | 250||

+| Windows services | 10 minutes to 30 minutes</br> Default: 30 minutes |

+| Linux Daemons | 5 minutes |

+|||

+|Windows Services | 250 |

+|Linux Daemons| 500|

+### Windows services data

+#### Prerequisites

+To enable tracking of Windows Services data, you must upgrade CT extension and use extension more than or equal to 2.11.0.0

+#### [For Windows Azure VMs](#tab/win-az-vm)

+```powershell-interactive

+- az vm extension set --publisher Microsoft.Azure.ChangeTrackingAndInventory --version 2.11.0 --ids /subscriptions/<subscriptionids>/resourceGroups/<resourcegroupname>/providers/Microsoft.Compute/virtualMachines/<vmname> --name ChangeTracking-Windows --enable-auto-upgrade true

+```

+#### [For Linux Azure VMs](#tab/lin-az-vm)

+```powershell-interactive

+ΓÇô az vm extension set --publisher Microsoft.Azure.ChangeTrackingAndInventory --version 2.11.0 --ids /subscriptions/<subscriptionids>/resourceGroups/<resourcegroupname>/providers/Microsoft.Compute/virtualMachines/<vmname> --name ChangeTracking-Linux --enable-auto-upgrade true

+```

+#### [For Arc-enabled Windows VMs](#tab/win-arc-vm)

+```powershell-interactive

+ΓÇô az connectedmachine extension create --name ChangeTracking-Linux --publisher Microsoft.Azure.ChangeTrackingAndInventory --type ChangeTracking-Linux --machine-name <arc-server-name> --resource-group <resource-group-name> --location <arc-server-location> --enable-auto-upgrade true

+```

+#### [For Arc-enabled Linux VMs](#tab/lin-arc-vm)

+```powershell-interactive

+- az connectedmachine extension create --name ChangeTracking-Windows --publisher Microsoft.Azure.ChangeTrackingAndInventory --type ChangeTracking-Windows --machine-name <arc-server-name> --resource-group <resource-group-name> --location <arc-server-location> --enable-auto-upgrade true

+```

+#### Configure frequency

+The default collection frequency for Windows services is 30 minutes. To configure the frequency:

+- under **Edit** Settings, use a slider on the **Windows services** tab.

+|Using Automation Update management |Use [Update management center (preview)](../update-center/overview.md)

+1. Assign the same role to the managed identity to access the Azure resources that match the Run As account. Follow the steps in [Check the role assignment for the Azure Automation Run As account](manage-run-as-account.md#check-role-assignment-for-azure-automation-run-as-account). Use this [script](https://github.com/azureautomation/runbooks/blob/master/Utility/AzRunAs/AssignMIRunAsRoles.ps1) to enable the System assigned identity in an Automation account and assign the same set of permissions present in Azure Automation Run as account to System Assigned identity of the Automation account.

+1. Use [this script](https://github.com/azureautomation/runbooks/blob/master/Utility/AzRunAs/Check-AutomationRunAsAccountRoleAssignments.ps1) to find out which Automation accounts are using a Run As account. If your Azure Automation accounts contain a Run As account, it has the built-in contributor role assigned to it by default. You can use the script to check the Azure Automation Run As accounts and determine if their role assignment is the default one or if it has been changed to a different role definition.

+- Review the [frequently asked questions for migrating to managed identities](automation-managed-identity-faq.md)

+### Known issue

+You may encounter error `AZCM0026: Network Error` accompanied by a message about "no IP addresses found" when connecting a server to Azure Arc using a proxy server. At this time, Microsoft recommends using [agent version 1.30](#version-131june-2023) in networks that require a proxy server. Microsoft has also reverted the agent download URL [aka.ms/AzureConnectedMachineAgent](https://aka.ms/AzureConnectedMachineAgent) to agent version 1.30 to allow existing installation scripts to succeed.

+If you've already installed agent version 1.31 and are seeing the error message above, [uninstall the agent](manage-agent.md#uninstall-from-control-panel) and run your installation script again. You do not need to downgrade to agent 1.30 if your agent is connected to Azure.

+Microsoft will update the release notes when this issue is resolved.

+> [!NOTE]

+> **Scale efficiency:** For the storage queue extension, messages with [visibilityTimeout](/rest/api/storageservices/put-message#uri-parameters) are still counted in _event source length_ by the Storage Queue APIs. This can cause overscaling of your function app. Consider using Service Bus queues que scheduled messages, [limiting scale out](event-driven-scaling.md#limit-scale-out), or not using visibilityTimeout for your solution.

+### Rsyslog default configuration logs all facilities to /var/log/

+On some popular distros (for example Ubuntu 18.04 LTS), rsyslog ships with a default configuration file (`/etc/rsyslog.d/50-default.conf`) which logs events from nearly all facilities to disk at `/var/log/syslog`. Note that for RedHat/CentOS family syslog events will be stored under `/var/log/` but in a different file: `/var/log/messages`.

+AMA doesn't rely on syslog events being logged to `/var/log/`. Instead, it configures rsyslog service to forward events over a socket directly to the azuremonitoragent service process (mdsd).

+If you're sending a high log volume through rsyslog and your system is setup to log events for these facilities, consider modifying the default rsyslog config to avoid logging and storing them under `/var/log/`. The events for this facility would still be forwarded to AMA because rsyslog is using a different configuration for forwarding placed in `/etc/rsyslog.d/10-azuremonitoragent.conf`.

+1. For example, to remove local4 events from being logged at `/var/log/syslog` or `/var/log/messages`, change this line in `/etc/rsyslog.d/50-default.conf` from this:

+ 1. (Optional) If you're creating a metric alert rule that monitors a custom metric with the scope defined as one of the following regions and you want to make sure that the data processing for the alert rule takes place within that region, you can select to process the alert rule in one of these regions:

+ - North Europe

+ - West Europe

+ - Sweden Central

+ - Germany West Central

+

+ We're continually adding more regions for regional data processing.

+Insert a JavaScript telemetry initializer, if needed. For more information on the telemetry initializers for the Application Insights JavaScript SDK, see [Telemetry initializers](https://github.com/microsoft/ApplicationInsights-JS#telemetry-initializers).

+#### [SDK Loader Script](#tab/sdkloaderscript)

+#### [npm package](#tab/npmpackage)

+ ```js

+ import { ApplicationInsights } from '@microsoft/applicationinsights-web'

+ const appInsights = new ApplicationInsights({ config: {

+ connectionString: 'YOUR_CONNECTION_STRING'

+ /* ...Other Configuration Options... */

+ } });

+ appInsights.loadAppInsights();

+ // To insert a telemetry initializer, uncomment the following code.

+ /** var telemetryInitializer = (envelope) => { envelope.data = envelope.data || {}; envelope.data.someField = 'This item passed through my telemetry initializer';

+ };

+ appInsights.addTelemetryInitializer(telemetryInitializer); **/

+ appInsights.trackPageView();

+ ```

+The previous sections provided guidance on methods to automatically and manually configure server-side monitoring. To add client-side monitoring, use the [client-side JavaScript SDK](javascript.md). You can monitor any web page's client-side transactions by adding a [JavaScript SDK Loader Script](./javascript-sdk.md?tabs=sdkloaderscript#get-started) before the closing `</head>` tag of the page's HTML.

+For the template-based ASP.NET MVC app from this article, the file that you need to edit is *_Layout.cshtml*. You can find it under **Views** > **Shared**. To add client-side monitoring, open *_Layout.cshtml* and follow the [SDK Loader Script-based setup instructions](./javascript-sdk.md?tabs=sdkloaderscript#get-started) from the article about client-side JavaScript SDK configuration.

+- **[npm-based setup](./javascript-sdk.md?tabs=npmpackage#get-started)**

+- **[SDK Loader Script-based setup](./javascript-sdk.md?tabs=sdkloaderscript#get-started)**

+# Enable Azure Monitor Application Insights Real User Monitoring

+The Microsoft Azure Monitor Application Insights JavaScript SDK allows you to monitor and analyze the performance of JavaScript web applications. This is commonly referred to as Real User Monitoring or RUM.

+## Get started

+Follow the steps in this section to instrument your application with the Application Insights JavaScript SDK.

+> [!NOTE]

+> If you have a React, React Native, or Angular application, you can [optionally add these plug-ins after you follow the steps to get started](#5-optional-advanced-sdk-configuration).

+### 1. Add the JavaScript code

+Two methods are available to add the code to enable Application Insights via the Application Insights JavaScript SDK:

+| Method | When would I use this method? |

+|:-|:|

+| SDK Loader Script | For most customers, we recommend the SDK Loader Script because you never have to update the SDK and you get the latest updates automatically. Also, you have control over which pages you add the Application Insights JavaScript SDK to. |

+| npm package | You want to bring the SDK into your code and enable IntelliSense. This option is only needed for developers who require more custom events and configuration. |

+#### [SDK Loader Script](#tab/sdkloaderscript)

+### 2. Paste the connection string in your environment

+To paste the connection string in your environment, follow these steps:

+### 5. (Optional) Advanced SDK configuration

+If you want to use the extra features provided by plugins for specific frameworks, see:

+> [!TIP]

+> We collect page views by default. But if you want to also collect clicks by default, consider adding the [Click Analytics plug-in](javascript-feature-extensions.md).

+## Support

+- If you're having trouble with enabling Application Insights, see the dedicated [troubleshooting article](/troubleshoot/azure/azure-monitor/app-insights/javascript-sdk-troubleshooting).

+- For common question about the JavaScript SDK, see the [FAQ](/azure/azure-monitor/faq#can-i-filter-out-or-modify-some-telemetry-).

+- For Azure support issues, open an [Azure support ticket](https://azure.microsoft.com/support/create-ticket/).

+- For a list of open issues related to the Application Insights JavaScript SDK, see the [GitHub Issues Page](https://github.com/microsoft/ApplicationInsights-JS/issues).

+* See the detailed [release notes](https://github.com/microsoft/ApplicationInsights-JS/releases) on GitHub for updates and bug fixes.

+- <a name="FOOTNOTEONE">1</a>: Supports automatic reporting of *unhandled/uncaught* exceptions

+ Title: Data Collection Basics of Azure Monitor Application Insights

+description: This article provides an overview of how to collect telemetry to send to Azure Monitor Application Insights.

+# Data Collection Basics of Azure Monitor Application Insights

+In the following sections, we cover some data collection basics of Azure Monitor Application Insights.

+## Instrumentation Options

+At a basic level, "instrumenting" is simply enabling an application to capture telemetry.

+There are two methods to instrument your application:

+- Automatic instrumentation (auto-instrumentation)

+- Manual instrumentation

+**Auto-instrumentation** enables telemetry collection through configuration without touching the application's code. Although it's more convenient, it tends to be less configurable. It's also not available in all languages. See [Auto-Instrumentation Supported Environments and Languages](codeless-overview.md). When auto-instrumentation is available, it's the easiest way to enable Azure Monitor Application Insights.

+**Manual instrumentation** is coding against the Application Insights or OpenTelemetry API. In the context of a user, it typically refers to installing a language-specific SDK in an application. There are two options for manual instrumentation:

+- [Application Insights SDKs](asp-net-core.md)

+- [Azure Monitor OpenTelemetry Distros](opentelemetry-enable.md).

+While we see OpenTelemetry as our future direction, we have no plans to stop collecting data from older SDKs. We still have a way to go before our Azure OpenTelemetry Distros [reach feature parity with our Application Insights SDKs](../faq.yml#what-s-the-current-release-state-of-features-within-the-azure-monitor-opentelemetry-distro-). In many cases, customers will continue to choose to use Application Insights SDKs for quite some time.

+> [!IMPORTANT]

+> "Manual" doesn't mean you'll be required to write complex code to define spans for distributed traces, although it remains an option. Instrumentation Libraries packaged into our Distros enable you to effortlessly capture telemetry signals across common frameworks and libraries. We're actively working to [instrument the most popular Azure Service SDKs using OpenTelemetry](https://devblogs.microsoft.com/azure-sdk/introducing-experimental-opentelemetry-support-in-the-azure-sdk-for-net/) so these signals are available to customers who use the Azure Monitor OpenTelemetry Distro.

+## Telemetry Types

+Telemetry, the data collected to observe your application, can be broken into three types or "pillars":

+- Distributed Tracing

+- Metrics

+- Logs

+A complete observability story includes all three pillars, and Application Insights further breaks down these pillars into tables based on our [data model](data-model-complete.md). Our Application Insights SDKs or Azure Monitor OpenTelemetry Distros include everything you need to power Application Performance Monitoring on Azure. The package itself is free to install, and you only pay for the data you ingest in Azure Monitor.

+The following sources explain the three pillars:

+- [OpenTelemetry community website](https://opentelemetry.io/docs/concepts/data-collection/)

+- [OpenTelemetry specifications](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md)

+- [Distributed Systems Observability](https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html) by Cindy Sridharan

+## Telemetry Routing

+*The currently available Application Insights SDKs and Azure Monitor OpenTelemetry Distros rely on a direct exporter*.

+Alternatively, sending application telemetry via an agent like OpenTelemetry-Collector can have some benefits including sampling, post-processing, and more. Azure Monitor is developing an agent and ingestion endpoint that supports [Open Telemetry Protocol (OTLP)](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/README.md), providing a path for any OpenTelemetry-supported programming language beyond our [supported languages](platforms.md) to use to Azure Monitor.

+> [!TIP]

+> If you are planning to use OpenTelemetry-Collector for sampling or additional data processing, you may be able to get these same capabilities built-in to Azure Monitor. Customers who have migrated to [Workspace-based Appplication Insights](convert-classic-resource.md) can benefit from [Ingestion-time Transformations](../essentials/data-collection-transformations.md). To enable, follow the details in the [tutorial](../logs/tutorial-workspace-transformations-portal.md), skipping the step that shows how to set up a diagnostic setting since with Workspace-centric Application Insights this is already configured. If youΓÇÖre filtering less than 50% of the overall volume, itΓÇÖs no additional cost. After 50%, there is a cost but much less than the standard per GB charge.

+## OpenTelemetry

+Microsoft is excited to embrace [OpenTelemetry](https://opentelemetry.io/) as the future of telemetry instrumentation. You, our customers, have asked for vendor-neutral instrumentation, and we're pleased to partner with the OpenTelemetry community to create consistent APIs and SDKs across languages.

+Microsoft worked with project stakeholders from two previously popular open-source telemetry projects, [OpenCensus](https://opencensus.io/) and [OpenTracing](https://opentracing.io/). Together, we helped to create a single project, OpenTelemetry. OpenTelemetry includes contributions from all major cloud and Application Performance Management (APM) vendors and lives within the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/). Microsoft is a Platinum Member of the CNCF.

+Some legacy terms in Application Insights are confusing because of the industry convergence on OpenTelemetry. The following table highlights these differences. Eventually, OpenTelemetry terms will replace Application Insights terms.

+Requests | Server Spans

+Dependencies | Other Span Types (Client, Internal, etc.)

+Select your enablement approach:

+- [Auto-instrumentation](codeless-overview.md)

+- Application Insights SDKs

+ - [ASP.NET](./asp-net.md)

+ - [ASP.NET Core](./asp-net-core.md)

+ - [Node.js](./nodejs.md)

+ - [Python](./opencensus-python.md)

+ - [JavaScript: Web](./javascript.md)

+- [Azure Monitor OpenTelemetry Distro](opentelemetry-enable.md)

+Check out the [Azure Monitor Application Insights FAQ](/azure/azure-monitor/faq#application-insights) and [OpenTelemetry FAQ](/azure/azure-monitor/faq#opentelemetry) for more information.

+- To use the SDK Loader Script, see [SDK Loader Script](./javascript-sdk.md?tabs=sdkloaderscript#get-started).

+1. **Webpage code:** Use the JavaScript SDK to collect data from webpages. See [Get started with the JavaScript SDK](./javascript-sdk.md).

+Whenever youΓÇÖre in any usage experience, click the **Open the last run query** icon to take you back to the underlying query.

+You can then modify the underlying query to get the kind of information youΓÇÖre looking for.

+HereΓÇÖs an example of an underlying query about page views. Go ahead and paste it directly into the query editor to test it out.

+```kusto

+// average pageView duration by name

+let timeGrain=5m;

+let dataset=pageViews

+// additional filters can be applied here

+| where timestamp > ago(1d)

+| where client_Type == "Browser" ;

+// calculate average pageView duration for all pageViews

+dataset

+| summarize avg(duration) by bin(timestamp, timeGrain)

+| extend pageView='Overall'

+// render result in a chart

+| render timechart

+```

+- has

+- !has

+- has_cs

+- !has_cs

+| Alert |[Alert rules ](https://aka.ms/azureprometheus-promio-alertrules)let you create an Azure Monitor alert based on the results of a Prometheus Query Language (Prom QL) query. Alerts fired by Azure Managed Prometheus alert rules are processed and trigger notifications in similar way to other Azure Monitor alerts.|

+| Recording |[Recording rules](https://aka.ms/azureprometheus-promio-recrules) allow you to precompute frequently needed or computationally extensive expressions and store their result as a new set of time series. Time series created by recording rules are ingested back to your Azure Monitor workspace as new Prometheus metrics. |

+Azure Managed Prometheus rule groups, recording rules and alert rules can be created and configured using The Azure resource type **Microsoft.AlertsManagement/prometheusRuleGroups**, where the alert rules and recording rules are defined as part of the rule group properties.Prometheus rule groups are defined with a scope of a specific [Azure Monitor workspace](azure-monitor-workspace-overview.md). Prometheus rule groups can be created using Azure Resource Manager (ARM) templates, API, Azure CLI, or PowerShell.

+You should limit rules to a single cluster if your Azure Monitor workspace contains a large amount of data from multiple clusters. In such a case, there's a concern that running a single set of rules on all the data may cause performance or throttling issues. By using the `clusterName` property, you can create multiple rule groups, each configured with the same rules, and therefore limit each group to cover a different cluster.

+- If `clusterName` isn't specified for a specific rule group, the rules in the group query all the data in the workspace from all clusters.

+### Creating Prometheus rule group using Resource Manager template

+You can use a Resource Manager template to create and configure Prometheus rule groups, alert rules, and recording rules. Resource Manager templates enable you to programmatically create and configure rule groups in a consistent and reproducible way across all your environments.

+The basic steps are as follows:

+1. Use the following template as a JSON file that describes how to create the rule group.

+2. Deploy the template using any deployment method, such as [Azure portal](../../azure-resource-manager/templates/deploy-portal.md), [Azure CLI](../../azure-resource-manager/templates/deploy-cli.md), [Azure PowerShell](../../azure-resource-manager/templates/deploy-powershell.md), or [Rest API](../../azure-resource-manager/templates/deploy-rest.md).

+Following is a sample template that creates a Prometheus rule group, including one recording rule and one alert rule. This template creates a resource of type `Microsoft.AlertsManagement/prometheusRuleGroups`. The rules are executed in the order they appear within a group.

+The rule group contains the following properties.

+The `rules` section contains the following properties for recording rules.

+| `record` | True | string | Recording rule name. This name is used for the new time series. |

+| `labels` | True | string | Prometheus rule labels key-value pairs. These labels are added to the recorded time series. |

+The `rules` section contains the following properties for alerting rules.

+| `labels` | False | object | labels key-value pairs | Prometheus alert rule labels. These labels are added to alerts fired by this rule. |

+### Creating Prometheus rule group using Azure CLI

+You can use Azure CLI to create and configure Prometheus rule groups, alert rules, and recording rules. The following code examples use [Azure Cloud Shell](../../cloud-shell/overview.md).

+1. In the [portal](https://portal.azure.com/), select **Cloud Shell**. At the prompt, use the commands that follow.

+2. To create a Prometheus rule group, use the `az alerts-management prometheus-rule-group create` command. You can see detailed documentation on the Prometheus rule group create command in the `az alerts-management prometheus-rule-group create` section of the [Azure CLI commands for creating and managing Prometheus rule groups](/cli/azure/alerts-management/prometheus-rule-group#commands).

+Example: Create a new Prometheus rule group with rules

+```azurecli

+ az alerts-management prometheus-rule-group create -n TestPrometheusRuleGroup -g TestResourceGroup -l westus --enabled --description "test" --interval PT10M --scopes "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.monitor/accounts/testaccount" --rules [{"record":"test","expression":"test","labels":{"team":"prod"}},{"alert":"Billing_Processing_Very_Slow","expression":"test","enabled":"true","severity":2,"for":"PT5M","labels":{"team":"prod"},"annotations":{"annotationName1":"annotationValue1"},"resolveConfiguration":{"autoResolved":"true","timeToResolve":"PT10M"},"actions":[{"actionGroupId":"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testrg/providers/microsoft.insights/actionGroups/test-action-group-name1","actionProperties":{"key11":"value11","key12":"value12"}},{"actionGroupId":"/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/testrg/providers/microsoft.insights/actionGroups/test-action-group-name2","actionProperties":{"key21":"value21","key22":"value22"}}]}]

+```

+### Create a new Prometheus rule group with PowerShell

+To create a Prometheus rule group using PowerShell, use the [new-azprometheusrulegroup](/powershell/module/az.alertsmanagement/new-azprometheusrulegroup) cmdlet.

+Example: Create Prometheus rule group definition with rules.

+```powershell

+$rule1 = New-AzPrometheusRuleObject -Record "job_type:billing_jobs_duration_seconds:99p5m"

+$action = New-AzPrometheusRuleGroupActionObject -ActionGroupId /subscriptions/fffffffff-ffff-ffff-ffff-ffffffffffff/resourceGroups/MyresourceGroup/providers/microsoft.insights/actiongroups/MyActionGroup -ActionProperty @{"key1" = "value1"}

+$Timespan = New-TimeSpan -Minutes 15

+$rule2 = New-AzPrometheusRuleObject -Alert Billing_Processing_Very_Slow -Expression "job_type:billing_jobs_duration_seconds:99p5m > 30" -Enabled $false -Severity 3 -For $Timespan -Label @{"team"="prod"} -Annotation @{"annotation" = "value"} -ResolveConfigurationAutoResolved $true -ResolveConfigurationTimeToResolve $Timespan -Action $action

+$rules = @($rule1, $rule2)

+$scope = "/subscriptions/fffffffff-ffff-ffff-ffff-ffffffffffff/resourcegroups/MyresourceGroup/providers/microsoft.monitor/accounts/MyAccounts"

+New-AzPrometheusRuleGroup -ResourceGroupName MyresourceGroup -RuleGroupName MyRuleGroup -Location eastus -Rule $rules -Scope $scope -Enabled

+```

+## View Prometheus rule groups

+You can view the rule groups and their included rules in the Azure portal by selecting **Rule groups** from the Azure Monitor workspace.

+## Disable and enable rules

+To enable or disable a rule, select the rule in the Azure portal. Select either **Enable** or **Disable** to change its status.

+> [!NOTE]

+> After you disable or re-enable a rule or a rule group, it may take few minutes for the rule group list to reflect the updated status of the rule or the group.

+Data in Azure Monitor is encrypted with Microsoft-managed keys. You can use your own encryption key to protect the data and saved queries in your workspaces. Customer-managed keys in Azure Monitor give you greater flexibility to manage access controls to logs. Once configure, new data for linked workspaces is encrypted with your key stored in [Azure Key Vault](../../key-vault/general/overview.md), or [Azure Key Vault Managed "HSM"](../../key-vault/managed-hsm/overview.md).

+Create or use an existing Azure Key Vault in the region that the cluster is planed, and generate or import a key to be used for logs encryption. The Azure Key Vault must be configured as recoverable, to protect your key and the access to your data in Azure Monitor. You can verify this configuration under properties in your Key Vault, both **Soft delete** and **Purge protection** should be enabled.

+Clusters use managed identity for data encryption with your Key Vault. Configure identity `type` property to `SystemAssigned` when creating your cluster to allow access to your Key Vault for "wrap" and "unwrap" operations.

+There are two permission models in Key Vault to grant access to your cluster and underlay storageΓÇöAzure role-based access control (Azure RBAC), and Vault access policies (legacy).

+1. Assign Azure RBAC you control (recommended)

+

+ To add role assignments, you must have Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleAssignments/delete permissions, such as [User Access Administrator](../../role-based-access-control/built-in-roles.md#user-access-administrator) or [Owner](../../role-based-access-control/built-in-roles.md#owner).

+ Open your Key Vault in Azure portal, **click Access configuration** in **Settings**, and select **Azure role-based access control** option. Then enter **Access control (IAM)** and add **Key Vault Crypto Service Encryption User** role assignment.

+ [<img src="media/customer-managed-keys/grant-key-vault-permissions-rbac-8bit.png" alt="Screenshot of Grant Key Vault RBAC permissions." title="Grant Key Vault RBAC permissions" width="80%"/>](media/customer-managed-keys/grant-key-vault-permissions-rbac-8bit.png#lightbox)

+1. Assign vault access policy (legacy)

+ Open your Key Vault in Azure portal and click **Access Policies**, select **Vault access policy**, then click **+ Add Access Policy** to create a policy with these settings:

+ - Key permissionsΓÇöselect **Get**, **Wrap Key** and **Unwrap Key**.

+ [<img src="media/customer-managed-keys/grant-key-vault-permissions-8bit.png" alt="Screenshot of Grant Key Vault access policy permissions." title="Grant Key Vault access policy permissions" width="80%"/>](media/customer-managed-keys/grant-key-vault-permissions-8bit.png#lightbox)

+ The **Get** permission is required to verify that your Key Vault is configured as recoverable to protect your key and the access to your Azure Monitor data.

+It takes the propagation of the key a while to complete. You can check the update state by sending GET request on the cluster and look at the **KeyVaultProperties** properties. Your recently updated key should return in the response.

+The query language used in Log Analytics is expressive and can contain sensitive information in comments, or in the query syntax. Some organizations require that such information is kept protected under Customer-managed key policy and you need save your queries encrypted with your key. Azure Monitor enables you to store saved queries and log alerts encrypted with your key in your own Storage Account when linked to your workspace.

+> Queries remain encrypted with Microsoft key ("MMK") in the following scenarios regardless Customer-managed key configuration: Workbooks in Azure Monitor, Azure dashboards, Azure Logic App, Azure Notebooks and Automation Runbooks.

+When linking your Storage Account for saved queries, the service stores saved-queries and log alerts queries in your Storage Account. Having control on your Storage Account [encryption-at-rest policy](../../storage/common/customer-managed-keys-overview.md), you can protect saved queries and log alerts with Customer-managed key. You will, however, be responsible for the costs associated with that Storage Account.

+* The saves queries in storage is considered as service artifacts and their format may change.

+* Linking a Storage Account for queries removed existing saves queries from your workspace. Copy saves queries that you need before this configuration. You can view your saved queries using [PowerShell](/powershell/module/az.operationalinsights/get-azoperationalinsightssavedsearch).

+* You can link a single Storage Account to a workspace, which can be used for both saved queries and log alerts queries.

+**Configure BYOS for saved queries**

+Link a Storage Account for queries to keep saved queries in your Storage Account.

+ - Double encryption settings cannot be changed after the cluster has been created.

+ [<img src="media/logs-data-export/export-create-2.png" alt="Screenshot of export rule configuration." title="Export rule configuration" width="80%"/>](media/logs-data-export/export-create-2.png#lightbox)

+| ASimNetworkSessionLogs, ASimWebSessionLogs | |

+* [Siemens Teamcenter baseline architecture](/azure/architecture/example-scenario/manufacturing/teamcenter-baseline)

+The Windows April 2023 updated included a patch for Netlogon protocol changes, which were not enforced at release.

+The upgrades to the Azure NetApp File storage resource have been completed. The enforcement of setting `RequireSeal` value to 2 will occur by default with the June 2023 Azure update. No action is required regarding the June 13 enforcement phase.

+For more information about this update, see [KB5021130: How to manage the Netlogon protocol changes related to CVE-2022-38023](https://support.microsoft.com/topic/kb5021130-how-to-manage-the-netlogon-protocol-changes-related-to-cve-2022-38023-46ea3067-3989-4d40-963c-680fd9e8ee25#timing5021130).

+- For hybrid backups (using MARS, DPM, or MABS), enabling always-on soft delete will disallow server deregistration and deletion of backups via the Azure portal. If you don't want to retain the backed-up data, we recommend you not to enable *always-on soft-delete* for the vault or perform *stop protection with delete data* before the server is decommissioned.

+# Configure Bastion for Kerberos authentication using the Azure portal (Preview)

+ Title: Azure Chaos Studio Preview fault and action library

+description: Understand the available actions you can use with Azure Chaos Studio Preview, including any prerequisites and parameters.

+# Azure Chaos Studio Preview fault and action library

+The faults listed in this article are currently available for use. To understand which resource types are supported, see [Supported resource types and role assignments for Azure Chaos Studio Preview](./chaos-studio-fault-providers.md).

+| Supported OS types | Windows |

+ Title: Create a chaos experiment using a Chaos Mesh fault with Azure CLI

+description: Create an experiment that uses an AKS Chaos Mesh fault by using Azure Chaos Studio Preview with the Azure CLI.

+You can use a chaos experiment to verify that your application is resilient to failures by causing those failures in a controlled environment. In this article, you cause periodic Azure Kubernetes Service (AKS) pod failures on a namespace by using a chaos experiment and Azure Chaos Studio Preview. Running this experiment can help you defend against service unavailability when there are sporadic failures.

+Chaos Studio uses [Chaos Mesh](https://chaos-mesh.org/), a free, open-source chaos engineering platform for Kubernetes, to inject faults into an AKS cluster. Chaos Mesh faults are [service-direct](chaos-studio-tutorial-aks-portal.md) faults that require Chaos Mesh to be installed on the AKS cluster. You can use these same steps to set up and run an experiment for any AKS Chaos Mesh fault.

+- An Azure subscription. [!INCLUDE [quickstarts-free-trial-note](../../includes/quickstarts-free-trial-note.md)]

+- An AKS cluster with Linux node pools. If you don't have an AKS cluster, see the AKS quickstart that uses the [Azure CLI](../aks/learn/quick-kubernetes-deploy-cli.md), [Azure PowerShell](../aks/learn/quick-kubernetes-deploy-powershell.md), or the [Azure portal](../aks/learn/quick-kubernetes-deploy-portal.md).

+## Open Azure Cloud Shell

+Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account.

+To open Cloud Shell, select **Try it** in the upper-right corner of a code block. You can also open Cloud Shell in a separate browser tab by going to [Bash](https://shell.azure.com/bash). Select **Copy** to copy the blocks of code, paste it into Cloud Shell, and select **Enter** to run it.

+> These instructions use a Bash terminal in Cloud Shell. Some commands might not work as described if you run the CLI locally or in a PowerShell terminal.

+Before you can run Chaos Mesh faults in Chaos Studio, you must install Chaos Mesh on your AKS cluster.

+1. Run the following commands in a [Cloud Shell](../cloud-shell/overview.md) window where you have the active subscription set to be the subscription where your AKS cluster is deployed. Replace `$RESOURCE_GROUP` and `$CLUSTER_NAME` with the resource group and name of your cluster resource.

+1. Verify that the Chaos Mesh pods are installed by running the following command:

+You should see output similar to the following example (a chaos-controller-manager and one or more chaos-daemons):

+Chaos Studio can't inject faults against a resource unless that resource is added to Chaos Studio first. To add a resource to Chaos Studio, create a [target and capabilities](chaos-studio-targets-capabilities.md) on the resource. AKS clusters have only one target type (service-direct), but other resources might have up to two target types. One target type is for service-direct faults. Another target type is for agent-based faults. Each type of Chaos Mesh fault is represented as a capability like PodChaos, NetworkChaos, and IOChaos.

+1. Create a target by replacing `$RESOURCE_ID` with the resource ID of the AKS cluster you're adding.

+1. Create the capabilities on the target by replacing `$RESOURCE_ID` with the resource ID of the AKS cluster you're adding. Replace `$CAPABILITY` with the [name of the fault capability you're enabling](chaos-studio-fault-library.md).

+ For example, if you're enabling the `PodChaos` capability:

+ This step must be done for each capability you want to enable on the cluster.

+You've now successfully added your AKS cluster to Chaos Studio.

+Now you can create your experiment. A chaos experiment defines the actions you want to take against target resources. The actions are organized and run in sequential steps. The chaos experiment also defines the actions you want to take against branches, which run in parallel.

+1. Create a Chaos Mesh `jsonSpec`:

+ 1. See the Chaos Mesh documentation for a fault type, [for example, the PodChaos type](https://chaos-mesh.org/docs/simulate-pod-chaos-on-kubernetes/#create-experiments-using-yaml-configuration-files).

+ 1. Formulate the YAML configuration for that fault type by using the Chaos Mesh documentation.

+ 1. Remove any YAML outside of the `spec`, including the spec property name. Remove the indentation of the spec details.

+ 1. Use a [YAML-to-JSON converter like this one](https://www.convertjson.com/yaml-to-json.htm) to convert the Chaos Mesh YAML to JSON and minimize it.

+ 1. Use a [JSON string escape tool like this one](https://www.freeformatter.com/json-escape.html) to escape the JSON spec.

+1. Create your experiment JSON by starting with the following JSON sample. Modify the JSON to correspond to the experiment you want to run by using the [Create Experiment API](/rest/api/chaosstudio/experiments/create-or-update), the [fault library](chaos-studio-fault-library.md), and the `jsonSpec` created in the previous step.

+1. Create the experiment by using the Azure CLI. Replace `$SUBSCRIPTION_ID`, `$RESOURCE_GROUP`, and `$EXPERIMENT_NAME` with the properties for your experiment. Make sure you've saved and uploaded your experiment JSON. Update `experiment.json` with your JSON filename.

+ Each experiment creates a corresponding system-assigned managed identity. Note the principal ID for this identity in the response for the next step.

+## Give the experiment permission to your AKS cluster

+Give the experiment access to your resources by using the following command. Replace `$EXPERIMENT_PRINCIPAL_ID` with the principal ID from the previous step. Replace `$RESOURCE_ID` with the resource ID of the target resource. In this case, it's the AKS cluster resource ID. Run this command for each resource targeted in your experiment.

+You're now ready to run your experiment. To see the effect, we recommend that you open your AKS cluster overview and go to **Insights** in a separate browser tab. Live data for the **Active Pod Count** shows the effect of running your experiment.

+1. Start the experiment by using the Azure CLI. Replace `$SUBSCRIPTION_ID`, `$RESOURCE_GROUP`, and `$EXPERIMENT_NAME` with the properties for your experiment.

+1. The response includes a status URL that you can use to query experiment status as the experiment runs.

+Now that you've run an AKS Chaos Mesh service-direct experiment, you're ready to:

+ Title: Create an experiment using a Chaos Mesh fault with the Azure portal

+description: Create an experiment that uses an AKS Chaos Mesh fault by using Azure Chaos Studio Preview with the Azure portal.

+You can use a chaos experiment to verify that your application is resilient to failures by causing those failures in a controlled environment. In this article, you cause periodic Azure Kubernetes Service (AKS) pod failures on a namespace by using a chaos experiment and Azure Chaos Studio Preview. Running this experiment can help you defend against service unavailability when there are sporadic failures.

+Chaos Studio uses [Chaos Mesh](https://chaos-mesh.org/), a free, open-source chaos engineering platform for Kubernetes, to inject faults into an AKS cluster. Chaos Mesh faults are [service-direct](chaos-studio-tutorial-aks-portal.md) faults that require Chaos Mesh to be installed on the AKS cluster. You can use these same steps to set up and run an experiment for any AKS Chaos Mesh fault.

+- An Azure subscription. [!INCLUDE [quickstarts-free-trial-note](../../includes/quickstarts-free-trial-note.md)]

+- An AKS cluster with a Linux node pool. If you don't have an AKS cluster, see the AKS quickstart that uses the [Azure CLI](../aks/learn/quick-kubernetes-deploy-cli.md), [Azure PowerShell](../aks/learn/quick-kubernetes-deploy-powershell.md), or the [Azure portal](../aks/learn/quick-kubernetes-deploy-portal.md).

+Previously, Chaos Mesh faults didn't work with private clusters. You can now use Chaos Mesh faults with private clusters by configuring [virtual network injection in Chaos Studio](chaos-studio-private-networking.md).

+Before you can run Chaos Mesh faults in Chaos Studio, you must install Chaos Mesh on your AKS cluster.

+ ```azurecli

+ az aks get-credentials -g $RESOURCE_GROUP -n $CLUSTER_NAME

+ ```

+

+ ```bash

+ helm repo add chaos-mesh https://charts.chaos-mesh.org

+ helm repo update

+ kubectl create ns chaos-testing

+ helm install chaos-mesh chaos-mesh/chaos-mesh --namespace=chaos-testing --set chaosDaemon.runtime=containerd --set chaosDaemon.socketPath=/run/containerd/containerd.sock

+ ```

+1. Verify that the Chaos Mesh pods are installed by running the following command:

+ ```bash

+ kubectl get po -n chaos-testing

+ ```

+ You should see output similar to the following example (a chaos-controller-manager and one or more chaos-daemons):

+

+ ```bash

+ NAME READY STATUS RESTARTS AGE

+ chaos-controller-manager-69fd5c46c8-xlqpc 1/1 Running 0 2d5h

+ chaos-daemon-jb8xh 1/1 Running 0 2d5h

+ chaos-dashboard-98c4c5f97-tx5ds 1/1 Running 0 2d5h

+ ```

+You can also [use the installation instructions on the Chaos Mesh website](https://chaos-mesh.org/docs/production-installation-using-helm/).

+## Enable Chaos Studio on your AKS cluster

+Chaos Studio can't inject faults against a resource unless that resource is added to Chaos Studio first. You add a resource to Chaos Studio by creating a [target and capabilities](chaos-studio-targets-capabilities.md) on the resource. AKS clusters have only one target type (service-direct), but other resources might have up to two target types. One target type is for service-direct faults. Another target type is for agent-based faults. Each type of Chaos Mesh fault is represented as a capability like PodChaos, NetworkChaos, and IOChaos.

+1. Open the [Azure portal](https://portal.azure.com).

+1. Search for **Chaos Studio (preview)** in the search bar.

+1. Select **Targets** and go to your AKS cluster.

+ 

+1. Select the checkbox next to your AKS cluster. Select **Enable targets** and then select **Enable service-direct targets** from the dropdown menu.

+ 

+1. A notification appears that indicates that the resources you selected were successfully enabled.

+ 

+You've now successfully added your AKS cluster to Chaos Studio. In the **Targets** view, you can also manage the capabilities enabled on this resource. Select the **Manage actions** link next to a resource to display the capabilities enabled for that resource.

+## Create an experiment

+Now you can create your experiment. A chaos experiment defines the actions you want to take against target resources. The actions are organized and run in sequential steps. The chaos experiment also defines the actions you want to take against branches, which run in parallel.

+1. Select the **Experiments** tab in Chaos Studio. In this view, you can see and manage all your chaos experiments. Select **Add an experiment**

+ 

+1. Fill in the **Subscription**, **Resource Group**, and **Location** where you want to deploy the chaos experiment. Give your experiment a name. Select **Next: Experiment designer**.

+ 

+1. You're now in the Chaos Studio experiment designer. The experiment designer allows you to build your experiment by adding steps, branches, and faults. Give a friendly name to your **Step** and **Branch** and select **Add fault**.

+ 

+1. Select **AKS Chaos Mesh Pod Chaos** from the dropdown list. Fill in **Duration** with the number of minutes you want the failure to last and **jsonSpec** with the following information:

+ To formulate your Chaos Mesh `jsonSpec`:

+ 1. See the Chaos Mesh documentation for a fault type, [for example, the PodChaos type](https://chaos-mesh.org/docs/simulate-pod-chaos-on-kubernetes/#create-experiments-using-yaml-configuration-files).

+ 1. Formulate the YAML configuration for that fault type by using the Chaos Mesh documentation.

+ 1. Remove any YAML outside of the `spec` (including the spec property name) and remove the indentation of the spec details.

+ 1. Use a [YAML-to-JSON converter like this one](https://www.convertjson.com/yaml-to-json.htm) to convert the Chaos Mesh YAML to JSON and minimize it.

+ 1. Paste the minimized JSON into the **jsonSpec** field in the portal.

+1. Select **Next: Target resources**.

+ 

+1. Select your AKS cluster and select **Next**.

+ 

+1. Verify that your experiment looks correct and select **Review + create** > **Create**.

+ 

+## Give the experiment permission to your AKS cluster

+1. Go to your AKS cluster and select **Access control (IAM)**.

+ 

+1. Select **Add** > **Add role assignment**.

+ 

+1. Search for **Azure Kubernetes Service Cluster Admin Role** and select the role. Select **Next**.

+ 

+1. Choose **Select members** and search for your experiment name. Select your experiment and choose **Select**. If there are multiple experiments in the same tenant with the same name, your experiment name is truncated with random characters added.

+ 

+1. Select **Review + assign** > **Review + assign**.

+You're now ready to run your experiment. To see the effect, we recommend that you open your AKS cluster overview and go to **Insights** in a separate browser tab. Live data for the **Active Pod Count** shows the effect of running your experiment.

+1. In the **Experiments** view, select your experiment. Select **Start** > **OK**.

+ 

+1. When the **Status** changes to *Running*, select **Details** for the latest run under **History** to see details for the running experiment.

+Now that you've run an AKS Chaos Mesh service-direct experiment, you're ready to:

+ Title: Create an experiment using a service-direct fault with Chaos Studio

+description: Create an experiment that uses a service-direct fault with Azure Chaos Studio Preview to fail over an Azure Cosmos DB instance.

+You can use a chaos experiment to verify that your application is resilient to failures by causing those failures in a controlled environment. In this article, you cause a multi-read, single-write Azure Cosmos DB failover by using a chaos experiment and Azure Chaos Studio Preview. Running this experiment can help you defend against data loss when a failover event occurs.

+You can use these same steps to set up and run an experiment for any service-direct fault. A *service-direct* fault runs directly against an Azure resource without any need for instrumentation. Agent-based faults require installation of the chaos agent.

+- An Azure subscription. [!INCLUDE [quickstarts-free-trial-note](../../includes/quickstarts-free-trial-note.md)]

+- An Azure Cosmos DB account. If you don't have an Azure Cosmos DB account, follow these steps to [create one](../cosmos-db/sql/create-cosmosdb-resources-portal.md).

+Chaos Studio can't inject faults against a resource unless that resource is added to Chaos Studio first. You add a resource to Chaos Studio by creating a [target and capabilities](chaos-studio-targets-capabilities.md) on the resource. Azure Cosmos DB accounts have only one target type (service-direct) and one capability (failover). Other resources might have up to two target types. One target type is for service-direct faults. Another target type is for agent-based faults. Other resources might have many other capabilities.

+1. Search for **Chaos Studio (preview)** in the search bar.

+1. Select **Targets** and go to your Azure Cosmos DB account.

+ 

+1. Select the checkbox next to your Azure Cosmos DB account. Select **Enable targets** and then select **Enable service-direct targets** from the dropdown menu.

+ 

+1. A notification appears that indicates that the resources selected were successfully enabled.

+ 

+You've now successfully added your Azure Cosmos DB account to Chaos Studio. In the **Targets** view, you can also manage the capabilities enabled on this resource. Selecting the **Manage actions** link next to a resource displays the capabilities enabled for that resource.

+Now you can create your experiment. A chaos experiment defines the actions you want to take against target resources. The actions are organized and run in sequential steps. The chaos experiment also defines the actions you want to take against branches, which run in parallel.

+1. Select the **Experiments** tab in Chaos Studio. In this view, you can see and manage all your chaos experiments. Select **Add an experiment**.

+ 

+1. Fill in the **Subscription**, **Resource Group**, and **Location** where you want to deploy the chaos experiment. Give your experiment a name. Select **Next: Experiment designer**.

+ 

+1. You're now in the Chaos Studio experiment designer. The experiment designer allows you to build your experiment by adding steps, branches, and faults. Give a friendly name to your **Step** and **Branch** and select **Add fault**.

+ 

+1. Select **CosmosDB Failover** from the dropdown list. Fill in **Duration** with the number of minutes you want the failure to last and **readRegion** with the read region of your Azure Cosmos DB account. Select **Next: Target resources**.

+ 

+1. Select your Azure Cosmos DB account and select **Next**.

+ 

+1. Verify that your experiment looks correct and select **Review + create** > **Create**.

+ 

+## Give the experiment permission to your target resource

+When you create a chaos experiment, Chaos Studio creates a system-assigned managed identity that executes faults against your target resources. This identity must be given [appropriate permissions](chaos-studio-fault-providers.md) to the target resource for the experiment to run successfully. You can use these steps for any resource and target type by modifying the role assignment in step 3 to match the [appropriate role for that resource and target type.](chaos-studio-fault-providers.md).

+1. Go to your Azure Cosmos DB account and select **Access control (IAM)**.

+ 

+1. Select **Add** > **Add role assignment**.

+ 

+1. Search for **Cosmos DB Operator** and select the role. Select **Next**.

+ 

+1. Choose **Select members** and search for your experiment name. Select your experiment and choose **Select**. If there are multiple experiments in the same tenant with the same name, your experiment name is truncated with random characters added.

+ 

+1. Select **Review + assign** > **Review + assign**.

+You're now ready to run your experiment. To see the effect, we recommend that you open your Azure Cosmos DB account overview and go to **Replicate data globally** in a separate browser tab. Refreshing periodically during the experiment shows the region swap.

+1. In the **Experiments** view, select your experiment. Select **Start** > **OK**.

+1. When **Status** changes to *Running*, select **Details** for the latest run under **History** to see details for the running experiment.

+Now that you've run an Azure Cosmos DB service-direct experiment, you're ready to:

+## Container image and license updates

+| gpt-35-turbo¹ (ChatGPT) | East US, France Central, South Central US, UK South, West Europe | N/A | 4,096 | Sep 2021 |

+> The currently listed deprecation dates in Azure OpenAI Studio and via REST API for gpt-35-turbo (0301) is a temporary placeholder. Deprecation will not happen prior to October 1st 2023.

+> The currently listed deprecation dates in Azure OpenAI Studio and via REST API for the gpt-4 and gpt-4-32k (0314) models are temporary placeholders. Deprecation will not happen prior to October 1st 2023.

+The best way to start exploring completions is through our playground in [Azure OpenAI Studio](https://oai.azure.com). It's a simple text box where you can submit a prompt to generate a completion. You can start with a simple example like the following:

+## Configuring content filters via Azure OpenAI Studio (preview)

+1. Go to Azure OpenAI Studio and navigate to the Content Filters tab (in the bottom left navigation, as designated by the red box below).

+Here are a few examples of using Codex that can be tested in [Azure OpenAI Studio's](https://oai.azure.com) playground with a deployment of a Codex series model, such as `code-davinci-002`.

+Azure OpenAI Service provides REST API access to OpenAI's powerful language models including the GPT-3, Codex and Embeddings model series. In addition, the new GPT-4 and ChatGPT (gpt-35-turbo) model series have now reached general availability. These models can be easily adapted to your specific task including but not limited to content generation, summarization, semantic search, and natural language to code translation. Users can access the service through REST APIs, Python SDK, or our web-based interface in the Azure OpenAI Studio.

+| Model regional availability | [Model availability](./concepts/models.md) |

+### Prompt engineering

+GPT-3, GPT-3.5, and GPT-4 models from OpenAI are prompt-based. With prompt-based models, the user interacts with the model by entering a text prompt, to which the model responds with a text completion. This completion is the modelΓÇÖs continuation of the input text.

+While these models are extremely powerful, their behavior is also very sensitive to the prompt. This makes [prompt engineering](./concepts/prompt-engineering.md) an important skill to develop.

+Prompt construction can be difficult. In practice, the prompt acts to configure the model weights to complete the desired task, but it's more of an art than a science, often requiring experience and intuition to craft a successful prompt.

+Quota increase requests can be submitted from the [Quotas](./how-to/quota.md) page of Azure OpenAI Studio. Please note that due to overwhelming demand, we are not currently approving new quota increase requests. Your request will be queued until it can be filled at a later time.

+| `ENDPOINT` | This value can be found in the **Keys & Endpoint** section when examining your resource from the Azure portal. Alternatively, you can find the value in **Azure OpenAI Studio** > **Playground** > **Code View**. An example endpoint is: `https://docs-test-001.openai.azure.com`.|

+## June 2023

+### UK South

+- Azure OpenAI is now available in the UK South region. Check the [models page](concepts/models.md), for the latest information on model availability in each region.

+### Content filtering & annotations (Preview)

+- How to [configure content filters](how-to/content-filters.md) with Azure OpenAI Service.

+- [Enable annotations](concepts/content-filter.md) to view content filtering category and severity information as part of your GPT based Completion and Chat Completion calls.

+### Quota

+- Quota provides the flexibility to actively [manage the allocation of rate limits across the deployments](how-to/quota.md) within your subscription.

+### Java & JavaScript SDK support

+- NEW Azure OpenAI preview SDKs offering support for [JavaScript](/azure/cognitive-services/openai/quickstart?tabs=command-line&pivots=programming-language-javascript) and [Java](/azure/cognitive-services/openai/quickstart?tabs=command-line&pivots=programming-language-java).

+* See [What are Cognitive Services](./what-are-cognitive-services.md) for available features you can develop along with [Azure Key Vault](../key-vault/general/index.yml).

+ Title: Azure Communication Services Rooms Insights Dashboard

+description: Descriptions of data visualizations available for Rooms Communications Services via Workbooks

+# Rooms Insights

+In this document, we outline the available insights dashboard to monitor Rooms logs and metrics.

+## Overview

+Within your Communications Resource, we've provided a **Rooms Insights** feature that displays many data visualizations conveying insights from the Azure Monitor logs and metrics monitored for Rooms. The visualizations within Insights are made possible via [Azure Monitor Workbooks](../../../../azure-monitor/visualize/workbooks-overview.md). In order to take advantage of Workbooks, follow the instructions outlined in [Enable Azure Monitor in Diagnostic Settings](../enable-logging.md). To enable Workbooks, you need to send your logs to a [Log Analytics workspace](../../../../azure-monitor/logs/log-analytics-overview.md) destination.

+## Prerequisites

+- In order to take advantage of Workbooks, follow the instructions outlined in [Enable Azure Monitor in Diagnostic Settings](../enable-logging.md). You need to enable `Operational Rooms Logs`

+- To use Workbooks, you need to send your logs to a [Log Analytics workspace](../../../../azure-monitor/logs/log-analytics-overview.md) destination.

+## Accessing Rooms Insights for Communication Services

+Inside your Azure Communication Services resource, scroll down on the left nav bar to the **Monitor** category and click on the **Insights** tab:

+## Rooms insights

+The **Rooms** tab displays Rooms API success Rate, Rooms API Volume by Operation Type/ Response Code, and Rooms Operation Drill-Down:

+## More information about workbooks

+For an in-depth description of workbooks, refer to the [Azure Monitor Workbooks](../../../../azure-monitor/visualize/workbooks-overview.md) documentation.

+## Editing dashboards

+The **Rooms Insights** dashboards provided with your **Communication Service** resource can be customized by clicking on the **Edit** button on the top navigation bar:

+Editing these dashboards doesn't modify the **Insights** tab, but rather creates a separate workbook that can be accessed on your resourceÆs Workbooks tab:

+For an in-depth description of workbooks, refer to the [Azure Monitor Workbooks](../../../../azure-monitor/visualize/workbooks-overview.md) documentation.

+ Title: Azure Communication Services Rooms logs

+description: Learn about logging for Azure Communication Services Rooms.

+# Azure Communication Services Rooms Logs

+Azure Communication Services offers logging capabilities that you can use to monitor and debug your Communication Services solution. These capabilities can be configured through the Azure portal.

+> [!IMPORTANT]

+> The following refers to logs enabled through [Azure Monitor](../../../../azure-monitor/overview.md) (see also [FAQ](../../../../azure-monitor/faq.yml)). To enable these logs for your Communications Services, see: [Enable logging in Diagnostic Settings](../enable-logging.md)

+## Pre-requisites

+Azure Communications Services provides monitoring and analytics features via [Azure Monitor Logs overview](../../../../azure-monitor/logs/data-platform-logs.md) and [Azure Monitor Metrics](../../../../azure-monitor/essentials/data-platform-metrics.md). Each Azure resource requires its own diagnostic setting, which defines the following criteria:

+ * Categories of logs and metric data sent to the destinations defined in the setting. The available categories will vary for different resource types.

+ * One or more destinations to send the logs. Current destinations include Log Analytics workspace, Event Hubs, and Azure Storage.

+ * A single diagnostic setting can define no more than one of each of the destinations. If you want to send data to more than one of a particular destination type (for example, two different Log Analytics workspaces), then create multiple settings. Each resource can have up to five diagnostic settings.

+The following are instructions for configuring your Azure Monitor resource to start creating logs and metrics for your Communications Services. For detailed documentation about using Diagnostic Settings across all Azure resources, see: [Enable logging in Diagnostic Settings](../enable-logging.md)

+> [!NOTE]

+> Under diagnostic setting name please select "Operational Rooms Logs" to enable the logs for Rooms.

+## Overview

+Rooms operational logs are records of events and activities that provide insights into your Rooms API requests. They capture details about the performance and functionality of the Rooms primitive, including the status of each Rooms request as well as additional properties.

+Rooms operational logs contain information that help identify trends and patterns of Rooms usage.

+## Log categories

+Communication Services offers the following types of logs that you can enable:

+* **Operational Rooms logs** - provides basic information related to the Rooms service

+### Operational Rooms logs schema

+| Property | Description |

+| -- | |

+| `Correlation ID` | Unique ID of the request. |

+| `Level` | The severity level of the event. |

+| `Operation Name` | The operation associated with log record. E.g., CreateRoom, PatchRoom, GetRoom, ListRooms, DeleteRoom, GetParticipants, UpdateParticipants.|

+| `Operation Version` | The api-version associated with the operation. |

+| `ResultType` | The status of the operation. |

+| `ResultSignature` | The sub status of the operation. If this operation corresponds to a REST API call, this field is the HTTP status code of the corresponding REST call. |

+|.`RoomId` | The ID of the Room. |

+| `RoomLifeSpan` | The Room lifespan in minutes. |

+| `AddedRoomParticipantsCount` | The count of participants added to a Room. |

+| `UpsertedRoomParticipantsCount` | The count of participants upserted in a Room. |

+| `RemovedRoomParticipantsCount` | The count of participants removed from a Room. |

+| `TimeGenerated` | The timestamp (UTC) of when the log was generated. |

+#### Example CreateRoom log

+```json

+ [

+ {

+ "CorrelationId": "Y4x6ZabFE0+E8ERwMpd68w",

+ "Level": "Informational",

+ "OperationName": "CreateRoom",

+ "OperationVersion": "2022-03-31-preview",

+ "ResultType": "Succeeded",

+ "ResultSignature": 201,

+ "RoomId": "99466898241024408",

+ "RoomLifespan": 61,

+ "AddedRoomParticipantsCount": 4,

+ "TimeGenerated": "5/25/2023, 4:32:49.469 AM",

+ }

+ ]

+```

+#### Example GetRoom log

+```json

+ [

+ {

+ "CorrelationId": "CNiZIX7fvkumtBSpFq7fxg",

+ "Level": "Informational",

+ "OperationName": "GetRoom",

+ "OperationVersion": "2022-03-31-preview",

+ "ResultType": "Succeeded",

+ "ResultSignature": "200",

+ "RoomId": "99466387192310000",

+ "RoomLifespan": 61,

+ "TimeGenerated": "2022-08-19T17:07:30.2400300Z",

+ },

+ ]

+```

+#### Example UpdateRoom log

+```json

+ [

+ {

+ "CorrelationId": "Bwqzh0pdnkGPDwNcMnBkng",

+ "Level": "Informational",

+ "OperationName": "UpdateRoom",

+ "OperationVersion": "2022-03-31-preview",

+ "ResultType": "Succeeded",

+ "ResultSignature": "200",

+ "RoomId": "99466387192310000",

+ "RoomLifespan": 121,

+ "TimeGenerated": "2022-08-19T17:07:30.3543160Z",

+ },

+ ]

+```

+#### Example DeleteRoom log

+```json

+ [

+ {

+ "CorrelationId": "x7rMXmihYEe3GFho9T/H2w",

+ "Level": "Informational",

+ "OperationName": "DeleteRoom",

+ "OperationVersion": "2022-02-01",

+ "ResultType": "Succeeded",

+ "ResultSignature": "204",

+ "RoomId": "99466387192310000",

+ "RoomLifespan": 121,

+ "TimeGenerated": "2022-08-19T17:07:30.5393800Z",

+ },

+ ]

+```

+ #### Example ListRooms log

+```json

+ [

+ {

+ "CorrelationId": "KibM39CaXkK+HTInfsiY2w",

+ "Level": "Informational",

+ "OperationName": "ListRooms",

+ "OperationVersion": "2022-03-31-preview",

+ "ResultType": "Succeeded",

+ "ResultSignature": "200",

+ "TimeGenerated": "2022-08-19T17:07:30.5393800Z",

+ },

+ ]

+```

+#### Example UpdateParticipants log

+```json

+ [

+ {

+ "CorrelationId": "zHT8snnUMkaXCRDFfjQDJw",

+ "Level": "Informational",

+ "OperationName": "UpdateParticipants",

+ "OperationVersion": "2022-03-31-preview",

+ "ResultType": "Succeeded",

+ "ResultSignature": "200",

+ "RoomId": "99466387192310000",

+ "RoomLifespan": 121,

+ "UpsertedRoomParticipantsCount": 5,

+ "RemovedRoomParticipantsCount": 1,

+ "TimeGenerated": "2023-04-14T17:07:30.5393800Z",

+ },

+ ]

+```

+ (See also [FAQ](../../../../azure-monitor/faq.yml)).

+| GetChatMessage | Gets a message by message ID. |

+If a request is made to an operation that isn't recognized, you receive a "Bad Route" value response.

+| SMSMessageSent | Sends an SMS message. |

+### Rooms API requests

+The following operations are available on Rooms API request metrics:

+| Operation / Route | Description |

+| -- | - |

+| CreateRoom | Creates a Room. |

+| DeleteRoom | Deletes a Room. |

+| GetRoom | Gets a Room by Room ID. |

+| PatchRoom | Updates a Room by Room ID. |

+| ListRooms | Lists all the Rooms for an ACS Resource. |

+| AddParticipants | Adds participants to a Room.|

+| RemoveParticipants | Removes participants from a Room. |

+| GetParticipants | Gets list of participants for a Room. |

+| UpdateParticipants | Updates list of participants for a Room. |

+Azure Communication Services Number Lookup is part of the Phone Numbers SDK. It can be used for your applications to add additional checks before sending an SMS or placing a call.

+- [Number Lookup Concept](../numbers/number-lookup-concept.md)

+- Analyze your Rooms data, see: [Rooms Logs](../Analytics/logs/rooms-logs.md).

+- Learn how to use the Log Analytics workspace, see: [Log Analytics Tutorial](../../../azure-monitor/logs/log-analytics-tutorial.md).

+- Create your own queries in Log Analytics, see: [Get Started Queries](../../../azure-monitor/logs/get-started-queries.md).

+In the context of a call center, customers might be assigned an account manager or have a relationship with a specific worker. In that event, you might want to route a specific job to a specific worker if possible.

+- A deployed Azure Communication Services resource. [Create a Communication Services resource](../../quickstarts/create-communication-resource.md).

+In the following example, a job is created that targets a specific worker. If that worker does not accept the job within the time to live(TTL) of 1 minute, the condition for the specific worker is no longer valid and the job can go to any worker.

+The Trusted Computing Base (TCB) refers to all of a system's hardware, firmware, and software components that provide a secure environment. The components inside the TCB are considered "critical". If one component inside the TCB is compromised, the entire system's security may be jeopardized. A lower TCB means higher security. There's less risk of exposure to various vulnerabilities, malware, attacks, and malicious people.

+The execution history for scheduled & event-based jobs is limited to the most recent `100` successful and failed job executions.

+ Title: Enable automatic HTTPS with Caddy as a sidecar container

+description: This guide describes how Caddy can be used as a reverse proxy to enhance your application with automatic HTTPS

+# Enable automatic HTTPS with Caddy in a sidecar container

+This article describes how Caddy can be used as a sidecar container in a [container group](container-instances-container-groups.md) acting as a reverse proxy to provide an automatically managed HTTPS endpoint for your application.

+Caddy is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go and represents an alternative to Nginx.

+The automatization of certificates is possible because Caddy supports the ACMEv2 API ([RFC 8555](https://www.rfc-editor.org/rfc/rfc8555)) that interacts with [Let's Encrypt](https://letsencrypt.org/) to issue certificates.

+In this example, only the Caddy container gets exposed on ports 80/TCP and 443/TCP. The application behind the reverse proxy remains private. The network communication between Caddy and your application happens via localhost.

+> [!NOTE]

+> This stands in contrast to the intra container group communication known from docker compose, where containers can be referenced by name.

+The example mounts the [Caddyfile](https://caddyserver.com/docs/caddyfile), which is required to configure the reverse proxy, from a file share hosted on an Azure Storage account.

+> [!NOTE]

+> For production deployments, most users will want to bake the Caddyfile into a custom docker image based on [caddy](https://hub.docker.com/_/caddy). This way, there is no need to mount files into the container.

+- This article requires version 2.0.55 or later of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.

+## Prepare the Caddyfile

+Create a file called `Caddyfile` and paste the following configuration. This configuration creates a reverse proxy configuration, pointing to your application container listening on 5000/TCP.

+```console

+my-app.westeurope.azurecontainer.io {

+ reverse_proxy http://localhost:5000

+}

+```

+It's important to note, that the configuration references a domain name instead of an IP address. Caddy needs to be reachable by this URL to carry out the challenge step required by the ACME protocol and to successfully retrieve a certificate from Let's Encrypt.

+> [!NOTE]

+> For production deployment, users might want to use a domain name they control, e.g., `api.company.com` and create a CNAME record pointing to e.g. `my-app.westeurope.azurecontainer.io`. If so, it needs to be ensured, that the custom domain name is also used in the Caddyfile, instead of the one assigned by Azure (e.g., `*.westeurope.azurecontainer.io`). Further, the custom domain name, needs to be referenced in the ACI YAML configuration described later in this example.

+## Prepare storage account

+Create a storage account

+```azurecli

+az storage account create \

+ --name <storage-account> \

+ --resource-group <resource-group> \

+ --location westeurope

+```

+Store the connection string to an environment variable

+```azurecli

+AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string --name <storage-account> --resource-group <resource-group> --output tsv)

+```

+Create the file shares required to store the container state and caddy configuration.

+```azurecli

+az storage share create \

+ --name proxy-caddyfile \

+ --account-name <storage-account>

+az storage share create \

+ --name proxy-config \

+ --account-name <storage-account>

+

+ az storage share create \

+ --name proxy-data \

+ --account-name <storage-account>

+```

+Retrieve the storage account keys and make a note for later use

+```azurecli

+az storage account keys list -g <resource-group> -n <storage-account>

+```

+## Deploy container group

+### Create YAML file

+Create a file called `ci-my-app.yaml` and paste the following content. Ensure to replace `<account-key>` with one of the access keys previously received and `<storage-account>` accordingly.

+This YAML file defines two containers `reverse-proxy` and `my-app`. The `reverse-proxy` container mounts the three previously created file shares. The configuration also exposes port 80/TCP and 443/TCP of the `reverse-proxy` container. The communication between both containers happens on localhost only.

+>[!NOTE]

+> It's important to note, that the `dnsNameLabel` key, defines the public DNS name, under which the container instance group will be reachable, it needs to match the FQDN defined in the `Caddyfile`

+```yml

+name: ci-my-app

+apiVersion: "2021-10-01"

+location: westeurope

+properties:

+ containers:

+ - name: reverse-proxy

+ properties:

+ image: caddy:2.6

+ ports:

+ - protocol: TCP

+ port: 80

+ - protocol: TCP

+ port: 443

+ resources:

+ requests:

+ memoryInGB: 1.0

+ cpu: 1.0

+ limits:

+ memoryInGB: 1.0

+ cpu: 1.0

+ volumeMounts:

+ - name: proxy-caddyfile

+ mountPath: /etc/caddy

+ - name: proxy-data

+ mountPath: /data

+ - name: proxy-config

+ mountPath: /config

+ - name: my-app

+ properties:

+ image: mcr.microsoft.com/azuredocs/aci-helloworld

+ ports:

+ - port: 5000

+ protocol: TCP

+ environmentVariables:

+ - name: PORT

+ value: 5000

+ resources:

+ requests:

+ memoryInGB: 1.0

+ cpu: 1.0

+ limits:

+ memoryInGB: 1.0

+ cpu: 1.0

+ ipAddress:

+ ports:

+ - protocol: TCP

+ port: 80

+ - protocol: TCP

+ port: 443

+ type: Public

+ dnsNameLabel: my-app

+ osType: Linux

+ volumes:

+ - name: proxy-caddyfile

+ azureFile:

+ shareName: proxy-caddyfile

+ storageAccountName: "<storage-account>"

+ storageAccountKey: "<account-key>"

+ - name: proxy-data

+ azureFile:

+ shareName: proxy-data

+ storageAccountName: "<storage-account>"

+ storageAccountKey: "<account-key>"

+ - name: proxy-config

+ azureFile:

+ shareName: proxy-config

+ storageAccountName: "<storage-account>"

+ storageAccountKey: "<account-key>"

+```

+### Deploy the container group

+Create a resource group with the [az group create](/cli/azure/group#az-group-create) command:

+```azurecli

+az group create --name <resource-group> --location westeurope

+```

+Deploy the container group with the [az container create](/cli/azure/container#az-container-create) command, passing the YAML file as an argument.

+```azurecli

+az container create --resource-group <resource-group> --file ci-my-app.yaml

+```

+### View the deployment state

+To view the state of the deployment, use the following [az container show](/cli/azure/container#az-container-show) command:

+```azurecli

+az container show --resource-group <resource-group> --name ci-my-app --output table

+```

+### Verify TLS connection

+Before verifying if everything went well, give the container group some time to fully start and for Caddy to request a certificate.

+#### OpenSSL

+We can use the `s_client` subcommand of OpenSSL for that purpose.

+```bash

+echo "Q" | openssl s_client -connect my-app.westeurope.azurecontainer.io:443

+```

+```console

+CONNECTED(00000188)

+Certificate chain

+ 0 s:CN = my-app.westeurope.azurecontainer.io

+ i:C = US, O = Let's Encrypt, CN = R3

+ 1 s:C = US, O = Let's Encrypt, CN = R3

+ i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

+ 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1

+ i:O = Digital Signature Trust Co., CN = DST Root CA X3

+Server certificate

+--BEGIN CERTIFICATE--

+MIIEgTCCA2mgAwIBAgISAxxidSnpH4vVuCZk9UNG/pd2MA0GCSqGSIb3DQEBCwUA

+MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD

+EwJSMzAeFw0yMzA0MDYxODAzMzNaFw0yMzA3MDUxODAzMzJaMC4xLDAqBgNVBAMT

+I215LWFwcC53ZXN0ZXVyb3BlLmF6dXJlY29udGFpbmVyLmlvMFkwEwYHKoZIzj0C

+AQYIKoZIzj0DAQcDQgAEaaN/wGyFcimM+1O4WzbFgO6vIlXxXqp9vgmLZHpFrNwV

+aO8JbaB7hE+M5EAg34LDY80RyHgY+Ff4vTh2Z96rVqOCAl4wggJaMA4GA1UdDwEB

+/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/

+BAIwADAdBgNVHQ4EFgQUoL5DP+4PWiyE79hL5o+v8uymHdAwHwYDVR0jBBgwFoAU

+FC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzAB

+hhVodHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5p

+LmxlbmNyLm9yZy8wLgYDVR0RBCcwJYIjbXktYXBwLndlc3RldXJvcGUuYXp1cmVj

+b250YWluZXIuaW8wTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEw

+KDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEEBgor

+BgEEAdZ5AgQCBIH1BIHyAPAAdgC3Pvsk35xNunXyOcW6WPRsXfxCz3qfNcSeHQmB

+Je20mQAAAYdX8+CQAAAEAwBHMEUCIQC9Ztqd3DXoJhOIHBW+P7ketGrKlVA6nPZl

+9CiOrn6t8gIgXHcrbBqItemndRMv+UJ3DaBfTkYOqECecOJCgLhSYNUAdgDoPtDa

+PvUGNTLnVyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYdX8+CAAAAEAwBHMEUCIBJ1

+24z44vKFUOLCi1a7ymVuWErkmLb/GtysvcxILaj0AiEAr49hyKfen4BbSTwC8Fg4

+/LgZnn2F3uHI+9p+ZMO9xTAwDQYJKoZIhvcNAQELBQADggEBACqxa21eiW3JrZwk

+FHgpd6SxhUeecrYXxFNva1Y6G//q2qCmGeKK3GK+ZGPqDtcoASH5t5ghV4dIT4WU

+auVDLFVywXzR8PT6QUu3W8QxU+W7406twBf23qMIgrF8PIWhStI5mn1uCpeqlnf5

+HpRaj2f5/5n19pcCZcrRx94G9qhPYdMzuy4mZRhxXRqrpIsabqX3DC2ld8dszCvD

+pkV61iuARgm3MIQz1yL/x5Bn4nywjnhYZA4KFktC0Ti55cPRh1mkzGQAsYQDdWrq

+dVav+U9dOLQ4Sq4suaDmzDzApr+hpQSJhwgRN16+tLMyZ6INAU2JWKDxiyDTdOuH

+jz456og=

+--END CERTIFICATE--

+subject=CN = my-app.westeurope.azurecontainer.io

+issuer=C = US, O = Let's Encrypt, CN = R3

+No client certificate CA names sent

+Peer signing digest: SHA256

+Peer signature type: ECDSA

+Server Temp Key: X25519, 253 bits

+SSL handshake has read 4208 bytes and written 401 bytes

+Verification error: unable to get local issuer certificate

+New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256

+Server public key is 256 bit

+Secure Renegotiation IS NOT supported

+Compression: NONE

+Expansion: NONE

+No ALPN negotiated

+Early data was not sent

+Verify return code: 20 (unable to get local issuer certificate)

+Post-Handshake New Session Ticket arrived:

+SSL-Session:

+ Protocol : TLSv1.3

+ Cipher : TLS_AES_128_GCM_SHA256

+ Session-ID: 85F1A4290F99A0DD28C8CB21EF4269E7016CC5D23485080999A8548057729B24

+ Session-ID-ctx:

+ Resumption PSK: 752D438C19A5DBDBF10781F863D5E5D9A8859230968A9EAFFF7BBA86937D004F

+ PSK identity: None

+ PSK identity hint: None

+ SRP username: None

+ TLS session ticket lifetime hint: 604800 (seconds)

+ TLS session ticket:

+ 0000 - 2f 25 98 90 9d 46 9b 01-03 78 db bd 4d 64 b3 a6 /%...F...x..Md..

+ 0010 - 52 c0 7a 8a b6 3d b8 4b-c0 d7 fc 04 e8 63 d4 bb R.z..=.K.....c..

+ 0020 - 15 b3 25 b7 be 64 3d 30-2b d7 dc 7a 1a d1 22 63 ..%..d=0+..z.."c

+ 0030 - 42 30 90 65 6b b5 e1 83-a3 6c 76 c8 f6 ae e9 31 B0.ek....lv....1

+ 0040 - 45 91 33 57 8e 9f 4b 6a-2e 2c 9b f9 87 5f 71 1d E.3W..Kj.,..._q.

+ 0050 - 5a 84 59 50 17 31 1f 62-2b 0e 1e e5 70 03 d9 e9 Z.YP.1.b+...p...

+ 0060 - 50 1c 5d 1f a4 3c 8a 0e-f4 c5 7d ce 9e 5c 98 de P.]..<....}..\..

+ 0070 - e5 .

+ Start Time: 1680808973

+ Timeout : 7200 (sec)

+ Verify return code: 20 (unable to get local issuer certificate)

+ Extended master secret: no

+ Max Early Data: 0

+read R BLOCK

+```

+#### Chrome browser

+Navigate to https://my-app.westeurope.azurecontainer.io and verify the certificate by clicking on the padlock next to the URL.

+To see the certificate details, click on "Connection is secure" followed by "certificate is valid".

+## Next steps

+- [Caddy documentation](https://caddyserver.com/docs/)

+- [GitHub aci-helloworld](https://github.com/Azure-Samples/aci-helloworld)

+- [YAML reference: Azure Container Instances](container-instances-reference-yaml.md)

+- [Secure your codeless REST API with automatic HTTPS using Data API builder and Caddy](https://www.azureblue.io/secure-your-codeless-rest-api-with-automatic-https-using-data-api-builder-and-caddy/)

+ .option("spark.cosmos.dropColumn","FirstName,LastName")\

+ .option("spark.cosmos.dropColumn","FirstName,LastName;StreetName,StreetNumber")\

+To enable multi-region writes in your application, call `.multipleWriteRegionsEnabled(true)` and `.preferredRegions(preferredRegions)` in the client builder, where `preferredRegions` is a `List` of regions the data is replicated into ordered by preference - ideally the regions with shortest distance/best latency first:

+The Java V2 SDK used the Maven [com.microsoft.azure::azure-cosmosdb](https://mvnrepository.com/artifact/com.microsoft.azure/azure-cosmosdb). To enable multi-region writes in your application, set `policy.setUsingMultipleWriteLocations(true)` and set `policy.setPreferredLocations` to the `List` of regions the data is replicated into ordered by preference - ideally the regions with shortest distance/best latency first:

+To enable multi-region writes in your application, set `connectionPolicy.UseMultipleWriteLocations` to `true`. Also, set `connectionPolicy.PreferredLocations` to the regions the data is replicated into ordered by preference - ideally the regions with shortest distance/best latency first:

+To enable multi-region writes in your application, set `connection_policy.UseMultipleWriteLocations` to `true`. Also, set `connection_policy.PreferredLocations` to the regions the data is replicated into ordered by preference - ideally the regions with shortest distance/best latency first.

+During the preview, computed properties must be created using the .NET v3 or Java v4 SDK. Once the computed properties have been created, you can execute queries that reference them using any method including all SDKs and Data Explorer in the Azure portal.

+|Java SDK v4 |>= [4.46.0](https://mvnrepository.com/artifact/com.azure/azure-cosmos/4.46.0) |Computed properties are currently under preview version. |

+Here's an example of how to create computed properties in a new container:

+### [.NET](#tab/dotnet)

+### [Java](#tab/java)

+```java

+CosmosContainerProperties containerProperties = new CosmosContainerProperties("myContainer", "/pk");

+List<ComputedProperty> computedProperties = new ArrayList<>(List.of(new ComputedProperty("cp_lowerName", "SELECT VALUE LOWER(c.name) FROM c")));

+containerProperties.setComputedProperties(computedProperties);

+client.getDatabase("myDatabase").createContainer(containerProperties);

+```

+Here's an example of how to update computed properties on an existing container:

+### [.NET](#tab/dotnet)

+### [Java](#tab/java)

+```java

+CosmosContainer container = client.getDatabase("myDatabase").getContainer("myContainer");

+// Read the current container properties

+CosmosContainerProperties containerProperties = container.read().getProperties();

+// Make the necessary updates to the container properties

+Collection<ComputedProperty> modifiedComputedProperites = containerProperties.getComputedProperties();

+modifiedComputedProperites.add(new ComputedProperty("cp_upperName", "SELECT VALUE UPPER(c.firstName) FROM c"));

+containerProperties.setComputedProperties(modifiedComputedProperites);

+// Update container with changes

+container.replace(containerProperties);

+```

+- Azure Cosmos DB - [Quickstart: Create an Azure Cosmos DB account](../cosmos-db/nosql/quickstart-portal.md) or Create a free [Try Cosmos DB Account](https://aka.ms/trycosmosdbvercel)

+We have an [Azure Cosmos DB Next.js Starter](https://aka.ms/azurecosmosdb-vercel-template), which a great ready-to-use template with guided structure and configuration, saving you time and effort in setting up the initial project setup. Click on Deploy to Deploy on Vercel and View Repo to view the (source code)[https://github.com/Azure/azurecosmosdb-vercel-starter].

+4. Upon successful completion, the completion page would contain the link to the deployed app, or you go to the Vercel project's dashboard to get the link of your app. Now your app is successfully deployed to vercel.

+## Next steps

+- To learn more about Azure Cosmos DB, see [Welcome to Azure Cosmos DB](../cosmos-db/introduction.md).

+- Create a new [Vercel project](https://vercel.com/dashboard).

+- Learn about [Try Cosmos DB and limits](../cosmos-db/try-free.md).

+You can configure budgets to start automated actions using Azure Action Groups. To learn more about automating actions using budgets, see [Automation with budgets](../manage/cost-management-budget-scenario.md).

+- Until the bug is fixed, you can work around the problem by adding a test budget in the Azure portal at the billing account/EA enrollment level. The test budget unblocks connecting with Power BI. For more information about creating a budget, see [Tutorial: Create and manage budgets](tutorial-acm-create-budgets.md).

+_Before you begin_: If you're unfamiliar with cost analysis, see the [Explore and analyze costs with Cost analysis](quick-acm-cost-analysis.md) quickstart. And, if you're unfamiliar with budgets in Azure, see the [Create and manage budgets](tutorial-acm-create-budgets.md) tutorial.

+- If you're unfamiliar with budgets in Azure, see [Create and manage budgets](tutorial-acm-create-budgets.md).

+After you've identified and analyzed your spending patterns, it's important to begin setting limits for yourself and your teams. Budgets give you the ability to set either a cost or usage-based budget with many thresholds and alerts. Make sure to review the budgets that you create regularly to see your budget burn-down progress and make changes as needed. Budgets also allow you to configure an automation trigger when a given budget threshold is reached. For example, you can configure your service to shut down VMs. Or you can move your infrastructure to a different pricing tier in response to a budget trigger.

+For more information, see [Create budgets](tutorial-acm-create-budgets.md).

+There are two critical components to maximizing the value of your investment in the cloud. One is automatic budget creation. The other is configuring cost-based orchestration in response to budget alerts. There are different ways to automate budget creation. Various alert responses happen when your configured alert thresholds are exceeded.

+You can configure budgets to start automated actions using Azure Action Groups. To learn more about automating actions using budgets, see [Automation with budgets](../manage/cost-management-budget-scenario.md).

+ Title: Quickstart - Create a budget with Bicep

+- [Microsoft.Consumption/budgets](/azure/templates/microsoft.consumption/budgets): Create a budget.

+- [Microsoft.Consumption/budgets](/azure/templates/microsoft.consumption/budgets): Create a budget.

+- [Microsoft.Consumption/budgets](/azure/templates/microsoft.consumption/budgets): Create a budget.

+In this quickstart, you created a budget and deployed it using Bicep. To learn more about Cost Management and Billing and Bicep, continue on to the articles below.

+* [Microsoft.Consumption/budgets](/azure/templates/microsoft.consumption/budgets): Create a budget.

+* [Microsoft.Consumption/budgets](/azure/templates/microsoft.consumption/budgets): Create a budget.

+* [Microsoft.Consumption/budgets](/azure/templates/microsoft.consumption/budgets): Create a budget.

+In this quickstart, you created a budget and deployed it. To learn more about Cost Management and Billing and Azure Resource Manager, continue on to the articles below.

+ Title: Tutorial - Create and manage budgets

+# Tutorial: Create and manage budgets

+In the following example, an email alert gets generated when 90% of the budget is reached. If you create a budget with the Budgets API, you can also assign roles to people to receive alerts. Assigning roles to people isn't supported in the Azure portal. For more about the Budgets API, see [Budgets API](/rest/api/consumption/budgets). If you want to have an email alert sent in a different language, see [Supported locales for budget alert emails](../automate/automate-budget-creation.md#supported-locales-for-budget-alert-emails).

+For more information about using budget-based automation with action groups, see [Manage costs with budgets](../manage/cost-management-budget-scenario.md).

+# Manage costs with budgets

+- Create the budget with the wanted thresholds and wire it to the action group.

+## Create the budget

+- How to create the budget with the desired thresholds and wire it to the action group.

+EA customers can set budgets for each department and account under an enrollment. Budgets in Cost Management help you plan for and drive organizational accountability. They help you inform others about their spending to proactively manage costs, and to monitor how spending progresses over time. You can configure alerts based on your actual cost or forecasted cost to ensure that your spending is within your organizational spend limit. When the budget thresholds you've created are exceeded, only notifications are triggered. None of your resources are affected and your consumption isn't stopped. You can use budgets to compare and track spending as you analyze costs. For more information about how to create budgets, see [Tutorial: Create and manage budgets](../costs/tutorial-acm-create-budgets.md).

+Spending quotas that were set for departments in your Enterprise Agreement enrollment are replaced with budgets in the new billing account. A budget is created for each spending quota set on departments in your enrollment. For more information on budgets, see [Tutorial: Create and manage budgets](../costs/tutorial-acm-create-budgets.md).

+You can now create budgets for the billing account, allowing you to track costs across subscriptions. You can also stay on top of your purchase charges using budgets. For more information about budgets, see [Create and manage budgets](../costs/tutorial-acm-create-budgets.md).

+### Azure Data Factory and Azure Synapse Analytics

+1. For further assistance, select **Send logs**.

+### Microsoft Purview

+For failed Microsoft Purview activities that are running on a self-hosted IR or shared IR, the service supports viewing and uploading error logs from the [Windows Event Viewer](/shows/inside/event-viewer).

+You can look up any errors you see in the error guide below.

+To get support and troubleshooting guidance for SHIR issues, you may need to generate an error report ID and [reach out to Microsoft support](https://azure.microsoft.com/support/create-ticket/).

+To generate the error report ID for Microsoft Support, follow these instructions:

+1. Before starting a scan in the Microsoft Purview governance portal:

+ 1. Navigate to the machine where the self-hosted integration runtime is installed and open the Windows Event Viewer.

+ 1. Clear the Windows Event Viewer logs in the **Integration Runtime** section. Right-click on the logs and select the clear logs option.

+ 1. Navigate back to the Microsoft Purview governance portal and start the scan.

+1. Once the scan shows status **Failed**, navigate back to the SHIR VM, or machine and refresh the event viewer in the **Integration Runtime** section.

+1. The activity logs are displayed for the failed scan run.

+1. For further assistance from Microsoft, select **Send Logs**.

+ The **Share the self-hosted integration runtime (SHIR) logs with Microsoft** window opens.

+ :::image type="content" source="media/self-hosted-integration-runtime-troubleshoot-guide/send-logs-integration-runtime.png" lightbox="media/self-hosted-integration-runtime-troubleshoot-guide/send-logs-integration-runtime.png" alt-text="Screenshot of the send logs button on the self-hosted integration runtime (SHIR) to upload logs to Microsoft.":::

+1. Select which logs you want to send.

+ * For a *self-hosted IR*, you can upload logs that are related to the failed activity or all logs on the self-hosted IR node.

+ * For a *shared IR*, you can upload only logs that are related to the failed activity.

+1. When the logs are uploaded, keep a record of the Report ID for later use if you need further assistance to solve the issue.

+ :::image type="content" source="media/self-hosted-integration-runtime-troubleshoot-guide/send-logs-complete.png" lightbox="media/self-hosted-integration-runtime-troubleshoot-guide/send-logs-complete.png" alt-text="Screenshot of the displayed report ID in the upload progress window for the Purview SHIR logs.":::

+> [!NOTE]

+> Log viewing and uploading requests are executed on all online self-hosted IR instances. If any logs are missing, make sure that all the self-hosted IR instances are online.

+## May 2023

+### Understanding throttling

+Azure Data Manager for Agriculture implements API throttling to ensure consistent performance by limiting the number of requests within a specified time frame. Throttling prevents resource overuse and maintains optimal performance and reliability for all customers. Details are available [here](concepts-understanding-throttling.md).

+## March 2023

+### Key Announcement: Preview Release

+Azure Data Manager for Agriculture is now available in preview. See our blog post [here](https://azure.microsoft.com/blog/announcing-microsoft-azure-data-manager-for-agriculture-accelerating-innovation-across-the-agriculture-value-chain/).

+- [Agentless discovery and visibility](#agentless-discovery-and-visibility-within-kubernetes-components) within Kubernetes components.

+- [Agentless container registry vulnerability assessment](#agentless-container-registry-vulnerability-assessment), using the image scanning results of your Azure Container Registry (ACR) with cloud security explorer.

+All of these capabilities are available as part of the [Defender Cloud Security Posture Management](concept-cloud-security-posture-management.md) plan.

+When you enable the Agentless discovery for Kubernetes extension, the following process occurs:

+### What's the refresh interval?

+Agentless information in Defender CSPM is updated through a snapshot mechanism. It can take up to **24 hours** to see results in Cloud Security Explorer and Attack Path.

+> [!NOTE]

+> This feature supports scanning of images in the Azure Container Registry (ACR) only. If you want to find vulnerabilities stored in other container registries, you can import the images into ACR, after which the imported images are scanned by the built-in vulnerability assessment solution. Learn how to [import container images to a container registry](https://learn.microsoft.com/azure/container-registry/container-registry-import-images?tabs=azure-cli).

+- **Query vulnerability information via sub-assessment API** - You can get scan results via REST API. See the [subassessment list](/rest/api/defenderforcloud/sub-assessments/get?tabs=HTTP).

+

+### If I remove an image from my registry, how long before vulnerabilities reports on that image would be removed?

+It currently takes 3 days to remove findings for a deleted image. We are working on providing quicker deletion for removed images.

+Defender for Containers provides real-time threat protection for [supported containerized environments](support-matrix-defender-for-containers.md) and generates alerts for suspicious activities. You can use this information to quickly remediate security issues and improve the security of your containers.

+Threat protection at the cluster level is provided by the Defender agent and analysis of the Kubernetes audit logs. This means that security alerts are only triggered for actions and deployments that occur after you've enabled Defender for Containers on your subscription.

+Examples of security events that Microsoft Defenders for Containers monitors include:

+- Exposed Kubernetes dashboards

+- Creation of high privileged roles

+- Creation of sensitive mounts

+You can view security alerts by selecting the Security alerts tile at the top of the Defender for Cloud's overview page, or the link from the sidebar.

+ :::image type="content" source="media/managing-and-responding-alerts/overview-page-alerts-links.png" alt-text="Screenshot showing how to get to the security alerts page from Microsoft Defender for Cloud's overview page." lightbox="media/managing-and-responding-alerts/overview-page-alerts-links.png":::

+The security alerts page opens.

+ :::image type="content" source="media/defender-for-containers/view-containers-alerts.png" alt-text="Screenshot showing you where to view the list of alerts." lightbox="media/defender-for-containers/view-containers-alerts.png":::

+Security alerts for runtime workload in the clusters can be recognized by the `K8S.NODE_` prefix of the alert type. For a full list of the cluster level alerts, see the [reference table of alerts](alerts-reference.md#alerts-k8scluster).

+Defender for Containers also includes host-level threat detection with over 60 Kubernetes-aware analytics, AI, and anomaly detections based on your runtime workload.

+Onboarding Agentless Container posture in Defender CSPM will allow you to gain all its [capabilities](concept-agentless-containers.md#capabilities).

+Defender CSPM includes [two extensions](#what-are-the-extensions-for-agentless-container-posture-management) that allow for agentless visibility into Kubernetes and containers registries across your organization's SDLC and runtime.

+## What are the extensions for Agentless Container Posture management?

+There are two extensions that provide agentless CSPM functionality:

+- **Container registries vulnerability assessments**: Provides agentless containers registries vulnerability assessments. Recommendations are available based on the vulnerability assessment timeline. Learn more about [image scanning](concept-agentless-containers.md#agentless-container-registry-vulnerability-assessment).

+- **Agentless discovery for Kubernetes**: Provides API-based discovery of information about Kubernetes cluster architecture, workload objects, and setup.

+## How can I onboard multiple subscriptions at once?

+To onboard multiple subscriptions at once, you can use this [script](https://github.com/Azure/Microsoft-Defender-for-Cloud/tree/main/Powershell%20scripts/Agentless%20Container%20Posture).

+- Are your [resource groups, subscriptions, or clusters locked](#what-do-i-do-if-i-have-locked-resource-groups-subscriptions-or-clusters)?

+## What can I do if I have stopped clusters?

+We do not support or charge stopped clusters. To get the value of agentless capabilities on a stopped cluster, you can rerun the cluster.

+## What do I do if I have locked resource groups, subscriptions, or clusters?

+We suggest that you unlock the locked resource group/subscription/cluster, make the relevant requests manually, and then re-lock the resource group/subscription/cluster by doing the following:

+1. Enable the feature flag manually via CLI:

+ ``` CLI

+ ΓÇ£az feature register --namespace "Microsoft.ContainerService" --name "TrustedAccessPreviewΓÇ¥

+ ```

+1. Perform the bind operation in the CLI:

+ ``` CLI

+ az account set -s <SubscriptionId>

+ az extension add --name aks-preview

+ az aks trustedaccess rolebinding create --resource-group <cluster resource group> --cluster-name <cluster name> --name defender-cloudposture --source-resource-id /subscriptions/<SubscriptionId>/providers/Microsoft.Security/pricings/CloudPosture/securityOperators/DefenderCSPMSecurityOperator --roles "Microsoft.Security/pricings/microsoft-defender-operator"

+ ```

+For locked clusters, you can also do one of the following:

+- Remove the lock.

+- Perform the bind operation manually by making an API request.

+Learn more about [locked resources](/azure/azure-resource-manager/management/lock-resources?tabs=json).

+ ## Support for exemptions

+- Learn more about [Trusted Access](/azure/aks/trusted-access-feature).

+- Learn how to [view and remediate vulnerability assessment findings for registry images and running images](view-and-remediate-vulnerability-assessment-findings.md).

+- Learn how to [create an exemption](exempt-resource.md) for a resource or subscription.

+- Learn more about [Cloud Security Posture Management](concept-cloud-security-posture-management.md).

+- Accounts with owner permissions on Azure resources should be MFA enabled

+- Accounts with write permissions on Azure resources should be MFA enabled

+- Accounts with read permissions on Azure resources should be MFA enabled

+1. Open the [network ports for Azure Arc](support-matrix-defender-for-servers.md#network-requirements) in your firewall.

+|June 11 | [Planning of cloud migration with an Azure Migrate business case now includes Defender for Cloud](#planning-of-cloud-migration-with-an-azure-migrate-business-case-now-includes-defender-for-cloud) |

+|June 7 | [Express configuration for vulnerability assessments in Defender for SQL is now Generally Available](#express-configuration-for-vulnerability-assessments-in-defender-for-sql-is-now-generally-available) |

+### Planning of cloud migration with an Azure Migrate business case now includes Defender for Cloud

+June 11, 2023

+Now you can discover potential cost savings in security by leveraging Defender for Cloud within the context of an [Azure Migrate business case](/azure/migrate/how-to-build-a-business-case).

+Review the requirements on this page before setting up [agentless containers posture](concept-agentless-containers.md) in Microsoft Defender for Cloud.

+> Agentless Posture is currently in Preview. Previews are provided "as is" and "as available" and are excluded from the service-level agreements and limited warranty.

+|Release state:|Preview |

+| Permissions | You need to have access as a:<br><br> - Subscription Owner, **or** <br> - User Access Admin and Security Admin permissions for the Azure subscription used for onboarding |

+You need to have a Defender CSPM plan enabled. There's no dependency on Defender for Containers​.

+### Are you using an updated version of AKS?

+Learn more about [supported Kubernetes versions in Azure Kubernetes Service (AKS)](/azure/aks/supported-kubernetes-versions?tabs=azure-cli).

+## Network requirements

+Validate the following endpoints are configured for outbound access so that Azure Arc extension can connect to Microsoft Defender for Cloud to send security data and events:

+- For Defender for Server multicloud deployments, make sure that the [addresses and ports required by Azure Arc](../azure-arc/dat#details-on-internet-addresses-ports-encryption-and-proxy-server-support) are open.

+- For deployments with GCP connectors, open port 443 to these URLs:

+ - `osconfig.googleapis.com`

+ - `compute.googleapis.com`

+ - `containeranalysis.googleapis.com`

+ - `agentonboarding.defenderforservers.security.azure.com`

+ - `gbl.his.arc.azure.com`

+- For deployments with AWS connectors, open port 443 to these URLs:

+ - `ssm.<region>.amazonaws.com`

+ - `ssmmessages.<region>.amazonaws.com`

+ - `ec2messages.<region>.amazonaws.com`

+ - `gbl.his.arc.azure.com`

+## Azure cloud support

+This table summarizes Azure cloud support for Defender for Servers features.

+ | | |

+ - Learn more about the Defender for Cloud [Defender plans](defender-for-cloud-introduction.md#protect-cloud-workloads).

+Azure Private DNS provides a reliable and secure DNS service for your virtual networks. Azure Private DNS manages and resolves domain names in the virtual network without the need to configure a custom DNS solution. By using private DNS zones, you can use your own custom domain name instead of the Azure-provided names during deployment. Using a custom domain name helps you tailor your virtual network architecture to best suit your organization's needs. It provides a naming resolution for virtual machines (VMs) within a virtual network and connected virtual networks. Additionally, you can configure zones names with a split-horizon view, which allows a private and a public DNS zone to share the name.

+## Private zone resiliency

+When you create a private DNS zone, Azure stores the zone data as a global resource. This means that the private zone is not dependent on a single VNet or region. You can link the same private zone to multiple VNets in different regions. If service is interrupted in one VNet, your private zone is still available. For more information, see [Azure Private DNS zone resiliency](private-dns-resiliency.md).

+ Title: Azure Private DNS zone resiliency

+description: In this article, learn about resiliency in Azure Private DNS zones.

+# Azure Private DNS zone resiliency

+DNS private zones are resilient to regional outages because zone data is globally available. Resource records in a private zone are automatically replicated across regions.

+## Resiliency example

+The following figure illustrates the availability of private zone data across multiple regions.

+

+In this example:

+- The private zone azure.contoso.com is linked to VNets in three different regions. Autoregistration is enabled in two regions.

+- A temporary outage occurs in region A.

+- Regions B and C are still able to successfully query DNS names in the private zone, including names that are autoregistered from region A (ex: VM1).

+- Region B can add, edit, or delete records from the private DNS zone as needed.

+- Service interruption in region A doesn't affect name resolution in the other regions.

+The example shown here doesn't illustrate a disaster recovery scenario, however the global nature of private zones also makes it possible to recreate VM1 in another VNet and assume its workload.

+> [!NOTE]

+> Azure Private DNS is an availability zone foundational, zone-reduntant service. For more information, see [Azure services with availability zone support](/azure/reliability/availability-zones-service-support#azure-services-with-availability-zone-support).

+## Next steps

+- To learn more about Private DNS zones, see [Using Azure DNS for private domains](private-dns-overview.md).

+- Learn how to [create a Private DNS zone](./private-dns-getstarted-powershell.md) in Azure DNS.

+- Learn about DNS zones and records by visiting: [DNS zones and records overview](dns-zones-records.md).

+- Learn about some of the other key [networking capabilities](../networking/fundamentals/networking-overview.md) of Azure.

+ Title: Migrate applications to use passwordless authentication with Azure Event Hubs

+description: Learn to migrate existing applications away from Shared Key authorization with the account key to instead use Azure AD and Azure RBAC for enhanced security with Azure Event Hubs.

+# Migrate an application to use passwordless connections with Azure Event Hubs

+## Configure your local development environment

+Passwordless connections can be configured to work for both local and Azure-hosted environments. In this section, you'll apply configurations to allow individual users to authenticate to Azure Event Hubs for local development.

+### Assign user roles

+### Sign-in to Azure locally

+### Update the application code to use passwordless connections

+The Azure Identity client library, for each of the following ecosystems, provides a `DefaultAzureCredential` class that handles passwordless authentication to Azure:

+- [.NET](/dotnet/api/overview/azure/Identity-readme?view=azure-dotnet&preserve-view=true#defaultazurecredential)

+- [C++](https://github.com/Azure/azure-sdk-for-cpp/blob/main/sdk/identity/azure-identity/README.md#defaultazurecredential)

+- [Go](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/azidentity#readme-defaultazurecredential)

+- [Java](/java/api/overview/azure/identity-readme?view=azure-java-stable&preserve-view=true#defaultazurecredential)

+- [Node.js](/javascript/api/overview/azure/identity-readme?view=azure-node-latest&preserve-view=true#defaultazurecredential)

+- [Python](/python/api/overview/azure/identity-readme?view=azure-python&preserve-view=true#defaultazurecredential)

+`DefaultAzureCredential` supports multiple authentication methods. The method to use is determined at runtime. This approach enables your app to use different authentication methods in different environments (local vs. production) without implementing environment-specific code. See the preceding links for the order and locations in which `DefaultAzureCredential` looks for credentials.

+## [.NET](#tab/dotnet)

+1. To use `DefaultAzureCredential` in a .NET application, install the `Azure.Identity` package:

+ ```dotnetcli

+ dotnet add package Azure.Identity

+ ```

+1. At the top of your file, add the following code:

+ ```csharp

+ using Azure.Identity;

+ ```

+1. Identify the locations in your code that create an `EventHubProducerClient` or `EventProcessorClient` object to connect to Azure Event Hubs. Update your code to match the following example:

+ ```csharp

+ DefaultAzureCredential credential = new();

+ var eventHubNamespace = $"https://{namespace}.servicebus.windows.net";

+ // Event Hubs producer

+ EventHubProducerClient producerClient = new(

+ eventHubNamespace,

+ eventHubName,

+ credential);

+ // Event Hubs processor

+ EventProcessorClient processorClient = new(

+ storageClient,

+ EventHubConsumerClient.DefaultConsumerGroupName,

+ eventHubNamespace,

+ eventHubName,

+ credential);

+ ```

+## [Go](#tab/go)

+1. To use `DefaultAzureCredential` in a Go application, install the `azidentity` module:

+ ```bash

+ go get -u github.com/Azure/azure-sdk-for-go/sdk/azidentity

+ ```

+1. At the top of your file, add the following code:

+ ```go

+ import (

+ "github.com/Azure/azure-sdk-for-go/sdk/azidentity"

+ )

+ ```

+1. Identify the locations in your code that create a `ProducerClient` or `ConsumerClient` instance to connect to Azure Event Hubs. Update your code to match the following example:

+ ```go

+ credential, err := azidentity.NewDefaultAzureCredential(nil)

+ eventHubNamespace := fmt.Sprintf(

+ "https://%s.servicebus.windows.net",

+ namespace)

+ if err != nil {

+ // handle error

+ }

+ // Event Hubs producer

+ producerClient, err = azeventhubs.NewProducerClient(

+ eventHubNamespace,

+ eventHubName,

+ credential,

+ nil)

+ if err != nil {

+ // handle error

+ }

+ // Event Hubs processor

+ processorClient, err = azeventhubs.NewConsumerClient(

+ eventHubNamespace,

+ eventHubName,

+ azeventhubs.DefaultConsumerGroup,

+ credential,

+ nil)

+ if err != nil {

+ // handle error

+ }

+ ```

+## [Java](#tab/java)

+1. To use `DefaultAzureCredential` in a Java application, install the `azure-identity` package via one of the following approaches:

+ 1. [Include the BOM file](/java/api/overview/azure/identity-readme?view=azure-java-stable&preserve-view=true#include-the-bom-file).

+ 1. [Include a direct dependency](/java/api/overview/azure/identity-readme?view=azure-java-stable&preserve-view=true#include-direct-dependency).

+1. At the top of your file, add the following code:

+ ```java

+ import com.azure.identity.DefaultAzureCredentialBuilder;

+ ```

+1. Identify the locations in your code that create an `EventHubProducerClient` or `EventProcessorClient` object to connect to Azure Event Hubs. Update your code to match the following example:

+ ```java

+ DefaultAzureCredential credential = new DefaultAzureCredentialBuilder()

+ .build();

+ String eventHubNamespace = "https://" + namespace + ".servicebus.windows.net";

+ // Event Hubs producer

+ EventHubProducerClient producerClient = new EventHubClientBuilder()

+ .credential(eventHubNamespace, eventHubName, credential)

+ .buildProducerClient();

+ // Event Hubs processor

+ EventProcessorClient processorClient = new EventProcessorClientBuilder()

+ .consumerGroup(consumerGroupName)

+ .credential(eventHubNamespace, eventHubName, credential)

+ .checkpointStore(new SampleCheckpointStore())

+ .processEvent(eventContext -> {

+ System.out.println(

+ "Partition ID = " +

+ eventContext.getPartitionContext().getPartitionId() +

+ " and sequence number of event = " +

+ eventContext.getEventData().getSequenceNumber());

+ })

+ .processError(errorContext -> {

+ System.out.println(

+ "Error occurred while processing events " +

+ errorContext.getThrowable().getMessage());

+ })

+ .buildEventProcessorClient();

+ ```

+## [Node.js](#tab/nodejs)

+1. To use `DefaultAzureCredential` in a Node.js application, install the `@azure/identity` package:

+ ```bash

+ npm install --save @azure/identity

+ ```

+1. At the top of your file, add the following code:

+ ```nodejs

+ import { DefaultAzureCredential } from "@azure/identity";

+ ```

+1. Identify the locations in your code that create an `EventHubProducerClient` or `EventHubConsumerClient` object to connect to Azure Event Hubs. Update your code to match the following example:

+ ```nodejs

+ const credential = new DefaultAzureCredential();

+ const eventHubNamespace = `https://${namespace}.servicebus.windows.net`;

+ // Event Hubs producer

+ const producerClient = new EventHubProducerClient(

+ eventHubNamespace,

+ eventHubName,

+ credential);

+ // Event Hubs processor

+ const processorClient = new EventHubConsumerClient(

+ consumerGroupName,

+ eventHubNamespace,

+ eventHubName,

+ credential

+ );

+ ```

+## [Python](#tab/python)

+1. To use `DefaultAzureCredential` in a Python application, install the `azure-identity` package:

+

+ ```bash

+ pip install azure-identity

+ ```

+1. At the top of your file, add the following code:

+ ```python

+ from azure.identity import DefaultAzureCredential

+ ```

+1. Identify the locations in your code that create an `EventHubProducerClient` or `EventHubConsumerClient` object to connect to Azure Event Hubs. Update your code to match the following example:

+ ```python

+ credential = DefaultAzureCredential()

+ event_hub_namespace = "https://%s.servicebus.windows.net" % namespace

+ # Event Hubs producer

+ producer_client = EventHubProducerClient(

+ fully_qualified_namespace = event_hub_namespace,

+ eventhub_name = event_hub_name,

+ credential = credential

+ )

+ # Event Hubs processor

+ processor_client = EventHubConsumerClient(

+ fully_qualified_namespace = event_hub_namespace,

+ eventhub_name = event_hub_name,

+ consumer_group = "$Default",

+ checkpoint_store = checkpoint_store,

+ credential = credential

+ )

+ ```

+4. Make sure to update the event hubs namespace in the URI of your `EventHubProducerClient` or `EventProcessorClient` objects. You can find the namespace name on the overview page of the Azure portal.

+ :::image type="content" source="media/event-hubs-passwordless/event-hubs-namespace.png" alt-text="Screenshot showing how to find the namespace name.":::

+### Run the app locally

+After making these code changes, run your application locally. The new configuration should pick up your local credentials, such as the Azure CLI, Visual Studio, or IntelliJ. The roles you assigned to your user in Azure allows your app to connect to the Azure service locally.

+## Configure the Azure hosting environment

+Once your application is configured to use passwordless connections and runs locally, the same code can authenticate to Azure services after it's deployed to Azure. The sections that follow explain how to configure a deployed application to connect to Azure Event Hubs using a [managed identity](/azure/active-directory/managed-identities-azure-resources/overview). Managed identities provide an automatically managed identity in Azure Active Directory (Azure AD) for applications to use when connecting to resources that support Azure AD authentication. Learn more about managed identities:

+* [Passwordless Overview](/azure/developer/intro/passwordless-overview)

+* [Managed identity best practices](/azure/active-directory/managed-identities-azure-resources/managed-identity-best-practice-recommendations)

+### Create the managed identity

+#### Associate the managed identity with your web app

+You need to configure your web app to use the managed identity you created. Assign the identity to your app using either the Azure portal or the Azure CLI.

+# [Azure portal](#tab/azure-portal-associate)

+Complete the following steps in the Azure portal to associate an identity with your app. These same steps apply to the following Azure

+* Azure Spring Apps

+* Azure Container Apps

+* Azure virtual machines

+* Azure Kubernetes Service

+1. Navigate to the overview page of your web app.

+1. Select **Identity** from the left navigation.

+1. On the **Identity** page, switch to the **User assigned** tab.

+1. Select **+ Add** to open the **Add user assigned managed identity** flyout.

+1. Select the subscription you used previously to create the identity.

+1. Search for the **MigrationIdentity** by name and select it from the search results.

+1. Select **Add** to associate the identity with your app.

+ :::image type="content" source="../../articles/storage/common/media/create-user-assigned-identity-small.png" alt-text="Screenshot showing how to create a user assigned identity." lightbox="../../articles/storage/common/media/create-user-assigned-identity.png":::

+# [Azure CLI](#tab/azure-cli-associate)

+# [Service Connector](#tab/service-connector-associate)

+### Assign roles to the managed identity

+Next, you need to grant permissions to the managed identity you created to access your event hub. Grant permissions by assigning a role to the managed identity, just like you did with your local development user.

+### [Azure portal](#tab/assign-role-azure-portal)

+1. Navigate to your event hub overview page and select **Access Control (IAM)** from the left navigation.

+1. Choose **Add role assignment**

+ :::image type="content" source="../../includes/passwordless/media/migration-add-role-small.png" alt-text="Screenshot showing how to add a role to a managed identity." lightbox="../../includes/passwordless/media/migration-add-role.png" :::

+1. In the **Role** search box, search for *Azure Event Hub Data Sender*, which is a common role used to manage data operations for queues. You can assign whatever role is appropriate for your use case. Select the *Azure Event Hub Data Sender* from the list and choose **Next**.

+1. On the **Add role assignment** screen, for the **Assign access to** option, select **Managed identity**. Then choose **+Select members**.

+1. In the flyout, search for the managed identity you created by name and select it from the results. Choose **Select** to close the flyout menu.

+ :::image type="content" source="../../includes/passwordless/media/migration-select-identity-small.png" alt-text="Screenshot showing how to select the assigned managed identity." lightbox="../../includes/passwordless/media/migration-select-identity.png":::

+1. Select **Next** a couple times until you're able to select **Review + assign** to finish the role assignment.

+1. Repeat these steps for the **Azure Event Hub Data Receiver** role.

+### [Azure CLI](#tab/assign-role-azure-cli)

+To assign a role at the resource level using the Azure CLI, you first must retrieve the resource ID using the [az eventhubs eventhub show](/cli/azure/eventhubs/eventhub) show command. You can filter the output properties using the `--query` parameter.

+```azurecli

+az eventhubs eventhub show \

+ --resource-group '<your-resource-group-name>' \

+ --namespace-name '<your-event-hubs-namespace>' \

+ --name '<your-event-hub-name>' \

+ --query id

+```

+Copy the output ID from the preceding command. You can then assign roles using the [az role assignment](/cli/azure/role/assignment) command of the Azure CLI.

+```azurecli

+az role assignment create --assignee "<user@domain>" \

+ --role "Azure Event Hubs Data Receiver" \

+ --scope "<your-resource-id>"

+az role assignment create --assignee "<user@domain>" \

+ --role "Azure Event Hubs Data Sender" \

+ --scope "<your-resource-id>"

+```

+### [Service Connector](#tab/assign-role-service-connector)

+If you connected your services using Service Connector you don't need to complete this step. The necessary role configurations were handled for you when you ran the Service Connector CLI commands.

+### Test the app

+After deploying the updated code, browse to your hosted application in the browser. Your app should be able to connect to the event hub successfully. Keep in mind that it may take several minutes for the role assignments to propagate through your Azure environment. Your application is now configured to run both locally and in a production environment without the developers having to manage secrets in the application itself.

+## Next steps

+In this tutorial, you learned how to migrate an application to passwordless connections.

+You can read the following resources to explore the concepts discussed in this article in more depth:

+* [Passwordless connections for Azure services](/azure/developer/intro/passwordless-overview)

+* To learn more about .NET, see [Get started with .NET in 10 minutes](https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/intro).

+| **[DE-CIX](https://www.de-cix.net/en/services/directcloud/microsoft-azure)** | Supported |Supported | Amsterdam2, Chennai, Chicago2, Dallas, Dubai2, Frankfurt, Frankfurt2, Kuala Lumpur, Madrid, Marseille, Mumbai, Munich, New York, Phoenix, Singapore2 |

+1. First, ensure that the Defender "EASM API" service principal has access to the correct roles in the database where you wish to export your attack surface data. For this reason, first ensure that your Defender EASM resource has been created in the appropriate tenant as this action provisions the EASM API principal.

+5. Open the Data Explorer cluster that will ingest your Defender EASM data or [create a new cluster](/azure/data-explorer/create-cluster-database-portal).

+6. Select **Databases** in the Data section of the left-hand navigation menu.

+7. Select **+ Add Database** to create a database to house your Defender EASM data.

+ - canadacentral

+ - centralus

+ - norwayeast

+ - francecentral

+Inventory filters can be used with the following operators. Some operators aren't available for every filter; some operators are hidden if they aren't logically applicable to the specific filter.

+| `Not Equals` | Returns results where the field doesn't exactly match the search value. |

+| `Does not start with` | Returns results where the field doesn't start with the search value. |

+| `Does not match` | Returns results where a tokenized term in the field doesn't exactly matches the search value. |

+| `Not In` | Returns results where the field doesn't exactly match any of the search values. Multiple options can be selected, and manually inputted fields exclude results that match an exact value. |

+| `Does not start with in` | Returns results where the field doesn't start with any of the search values. |

+| `Does not match in` | Returns results where a tokenized term in the field doesn't exactly match any of the search values. |

+| `Does Not Contain` | Returns results where the field content doesn't contain the search value. |

+| `Does Not Contain In` | Returns results where a tokenized term in the field content doesn't contain any of the search values. |

+| `Empty` | Returns assets that don't return any value for the specified filter. |

+ | Filter name | Description | Selectable values | Available operators |

+| Wildcard | A wildcard DNS record answers DNS requests for subdomains that haven't already been defined. For example: *.contoso.com | True, False | `Equals` `Not Equals` |

+## Filtering for assets outside of your approved inventory

+1. Select **Inventory** on the left-hand navigation bar to view your inventory.

+2. To remove the Approved Inventory filter, select the "X" next to the **State = Approved** filter. This will expand your inventory list to include assets in other states (e.g. Dismissed).

+

+3. Identify the asset(s) you'd want to find and how to best surface them using the inventory filters. You may wish to review all assets in the "Candidate" state, adding any assets within your organization's purview to "Approved Inventory".

+

+

+4. Instead, you may need to find a single specific asset that you wish to add to Approved Inventory. To discover a specific asset, apply a filter searching for the name.

+

+

+4. Once your inventory list contains the unapproved assets that you were searching for, you can modify the assets. For more information on updating assets, see the [Modifying inventory assets](labeling-inventory-assets.md) article.

+ Title: Modifying inventory assets

+description: This article outlines how to update assets with labels (custom text values of a user's choice) for improved categorization and operationalization of their inventory data. It also dives into

+# Modifying inventory assets

+This article outlines how to modify inventory assets. Users can change the state of an asset or apply labels to help better contextualize and operationalize inventory data. This article describes how to modify a single asset or multiple assets, and track any updates with the Task Manager.

+## Labeling assets

+Labels help you organize your attack surface and apply business context in a highly customizable way. You can apply any text label to a subset of assets to group assets and better operationalize your inventory. Customers commonly categorize assets that:

+- Have recently come under your organizationΓÇÖs ownership through a merger or acquisition.

+- Require compliance monitoring.

+- Are owned by a specific business unit in their organization.

+- Are impacted by a specific vulnerability that requires mitigation.

+- Relate to a particular brand owned by the organization.

+- Were added to your inventory within a specific time range.

+Labels are free-form text fields, so you can create a label for any use case that applies to your organization.

+## Applying labels and modifying asset states

+Users can apply labels or modify asset states from both the inventory list and asset details pages. You can make changes to a single asset from the asset details page, or multiple assets from the inventory list page. The following sections describe how to apply changes from the two inventory views depending on your use case.

+You should modify assets from the inventory list page if you want to update numerous assets at once. This process also allows you to refine your asset list based on filter parameters, helping you identify assets that should be categorized with the desired label or state change. To modify assets from this page:

+2. Apply filters to produce your intended results. In this example, we are looking for domains expiring within 30 days that require renewal. The applied label helps you more quickly access any expiring domains, simplifying the remediation process. This is a simple use case; users can apply as many filters as needed to obtain the specific results needed. For more information on filters, see the [Inventory filters overview](inventory-filters.md) article.

+3. Once your inventory list is filtered, select the dropdown by checkbox next to the "Asset" table header. This dropdown gives you the option to select all results that match your query, the results on that specific page (up to 25), or "none" which unselects all assets. You can also choose to select only specific results on the page by selecting the individual checkmarks next to each asset.

+

+5. This action opens a new ΓÇ£Modify AssetsΓÇ¥ pane on the right-hand side of your screen. From this screen, you can quickly change the state of the selected asset(s). For this example, we will create a new label. Select **Create a new label**.

+6. Determine the label name and display text values. The label name cannot be changed after you initially create the label, but the display text can be edited at a later time. The label name is used to query for the label in the product interface or via API, so edits are disabled to ensure these queries work properly. To edit a label name, you need to delete the original label and create a new one.

+Select a color for your new label, then select **Add**. This action navigates you back to the ΓÇ£Modify AssetsΓÇ¥ screen.

+8. Allow a few moments for the labels to be applied. You will immediately see a notification that confirms the update is in progress. Once complete, you'll see a "completed" notification and the page automatically refreshes, displaying your asset list with the labels visible. A banner at the top of the screen confirms that your labels have been applied.

+Users can also modify a single asset from the asset details page. This is ideal for situations when assets need to be thoroughly reviewed before a label or state change is applied.

+2. Select the specific asset to which you want to modify to open the asset details page.

+5. Once complete, the asset details page refreshes, displaying the newly applied label or state change and a banner that indicates the asset was successfully updated.

+3. To remove a label, select the trash can icon from the **Actions** column of the label you wish to delete. A box appears that asks you to confirm the removal of this label; select **Remove Label** to confirm.

+The Labels page will automatically refresh and the label will be removed from the list, as well as removed from any assets that had the label applied. A banner appears to confirm the removal.

+## Task manager and notifications

+Once a task is submitted, you will immediately see a notification pop-up that confirms that the update is in progress. From any page in Azure, simply click on the notification (bell) icon to view additional information about recent tasks.

+ 

+The Defender EASM system can take seconds to update a handful of assets or minutes to update thousands. The Task Manager enables you to check on the status of any modification tasks in progress. This section outlines how to access the Task Manager and use it to better understand the completion of submitted updates.

+1. From your Defender EASM resource, select **Task Manager** on the left-hand navigation menu.

+

+2. This page displays all your recent tasks and their status. Tasks will be listed as "Completed", "Failed" or "In Progress" with a completion percentage and progress bar also displayed. To see more details about a specific task, simply select the task name. A right-hand pane will open that provides additional information.

+3. Select **Refresh** to see the latest status of all items in the Task Manager.

+

+

+

+

+

+

+

+### Web components

+

+### Observations

+The Observations tab displays any insights from the Attack Surface Priorities dashboard that pertain to the asset. These priorities can include critical CVEs, known associations to compromised infrastructure, use of deprecated technology, infrastructure best practice violations, or compliance issues. For more information on Observations, see the [Understanding dashboards](understanding-dashboards.md) article. For each observation, Defender EASM provides the name of the observation, categorizes it by type, assigns a priority, and lists both CVSS v2 and v3 scores where applicable.

+

+

+

+

+The seed list view displays seed values with three columns: type, source name, and discovery group. The ΓÇ£type" field displays the category of the seed asset; the most common seeds are domains, hosts and IP blocks, but you can also use email contacts, ASNs, certificate common names or WhoIs organizations. The source name is simply the value that was inputted in the appropriate type box when creating the discovery group. The final column shows a list of discovery groups that use the seed; each value is clickable, taking you to the details page for that discovery group.

+When inputting seeds, remember to validate the appropriate format for each entry. When saving the Discovery Group, the platform will run a series of validation checks and alert you of any misconfigured seeds. For example, IP Blocks should be inputted by network address (i.e. the start of the IP range).

+- **SNAT** - Additional ports are available for outbound SNAT connections, reducing the potential for SNAT port exhaustion. Azure Firewall uses the primary public IP address first before it uses the other associated public IP addresses. If you have any downstream filtering on your network, you need to allow all public IP addresses associated with your firewall. Consider using a [public IP address prefix](../virtual-network/ip-services/public-ip-address-prefix.md) to simplify this configuration.

+ Title: Use managed identities to access Azure Key Vault certificates

+description: This article shows you how to set up managed identities with Azure Front Door to access certificates in an Azure Key Vault.

+# Use managed identities to access Azure Key Vault certificates

+A managed identity generated by Azure Active Directory (Azure AD) allows your Azure Front Door instance to easily and securely access other Azure AD-protected resources, such as Azure Key Vault. Azure manages the identity resource, so you don't have to create or rotate any secrets. For more information about managed identities, seeΓÇ»[What are managed identities for Azure resources?](../active-directory/managed-identities-azure-resources/overview.md).

+Once you enable managed identity for Azure Front Door and grant proper permissions to access your Azure Key Vault, Front Door only uses managed identity to access the certificates. If you don't **add the managed identity permission to your Key Vault**, custom certificate autorotation and adding new certificates fails without permissions to Key Vault. If you disable managed identity, Azure Front Door falls back to using the original configured Azure Active Directory App. This solution isn't recommended and will be retired in the future.

+You can grant two types of identities to an Azure Front Door profile:

+* A **system-assigned** identity is tied to your service and is deleted if your service is deleted. The service can have only **one** system-assigned identity.

+* A **user-assigned** identity is a standalone Azure resource that can be assigned to your service. The service can have **multiple** user-assigned identities.

+Managed identities are specific to the Azure AD tenant where your Azure subscription is hosted. They don't get updated if a subscription gets moved to a different directory. If a subscription gets moved, you need to recreate and reconfigure the identity.

+Before you can set up managed identity for Azure Front Door, you must have an Azure Front Door Standard or Premium profile created. To create a new Front Door profile, see [create an Azure Front Door](create-front-door-portal.md).

+1. Go to an existing Azure Front Door profile. Select **Identity** from under *Security* on the left side menu pane.

+1. Select either a **System assigned** or a **User assigned** managed identity.

+ * **System assigned** - a managed identity is created for the Azure Front Door profile lifecycle and is used to access Azure Key Vault.

+ * **User assigned** - a standalone managed identity resource is used to authenticate to Azure Key Vault and has its own lifecycle.

+# [System assigned](#tab/system-assigned)

+1. You're prompted with a message to confirm that you would like to create a system managed identity for your Front Door profile. Select **Yes** to confirm.

+1. Once the system assigned managed identity has been created and registered with Azure Active Directory, you can use the **Object (principal) ID** to grant Azure Front Door access to your Azure Key Vault.

+# [User assigned](#tab/user-assigned)

+You must already have a user managed identity created. To create a new identity, see [create a user assigned managed identity](../active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md).

+1. In the **User assigned** tab, select **+ Add** to add a user assigned managed identity.

+1. You'll see the name of the user assigned managed identity you've selected show in the Azure Front Door profile.

+## Configure Key Vault access policy

+1. Navigate to your Azure Key Vault. Select **Access policies** from under *Settings* and then select **+ Create**.

+1. On the **Permissions** tab of the *Create an access policy* page, select **List** and **Get** under *Secret permissions*. Then select **Next** to configure the principal tab.

+1. On the *Principal* tab, paste the **object (principal) ID** if you're using a system managed identity or enter a **name** if you're using a user assigned manged identity. Then select **Review + create** tab. The *Application* tab is skipped since Azure Front Door gets selected for you already.

+* Learn how to [configure HTTPS on an Azure Front Door custom domain](standard-premium/how-to-configure-https-custom-domain.md).

+ Title: Migrate Azure Front Door (classic) to Standard/Premium tier with Azure PowerShell

+description: This article provides step-by-step instructions on how to migrate from an Azure Front Door (classic) profile to an Azure Front Door Standard or Premium tier profile with Azure PowerShell.

+# Migrate Azure Front Door (classic) to Standard/Premium tier with Azure PowerShell

+Azure Front Door Standard and Premium tier bring the latest cloud delivery network features to Azure. With enhanced security features and an all-in-one service, your application content is secured and closer to your end users using the Microsoft global network. This article guides you through the migration process to move your Azure Front Door (classic) profile to either a Standard or Premium tier profile with Azure PowerShell.

+## Prerequisites

+* Review the [About Front Door tier migration](tier-migration.md) article.

+* Ensure your Front Door (classic) profile can be migrated:

+ * Azure Front Door Standard and Premium require all custom domains to use HTTPS. If you don't have your own certificate, you can use an Azure Front Door managed certificate. The certificate is free of charge and gets managed for you.

+ * Session affinity gets enabled in the origin group settings for an Azure Front Door Standard or Premium profile. In Azure Front Door (classic), session affinity is set at the domain level. As part of the migration, session affinity is based on the Front Door (classic) profile settings. If you have two domains in your classic profile that shares the same backend pool (origin group), session affinity has to be consistent across both domains in order for migration validation to pass.

+* Latest Azure PowerShell module installed locally or Azure Cloud Shell. For more information, see [Install and configure Azure PowerShell](/powershell/azure/install-azure-powershell).

+> [!NOTE]

+> You don't need to make any DNS changes before or during the migration process. However, once the migration completes and traffic is flowing through your new Azure Front Door profile, you need to update your DNS records. For more information, see [Update DNS records](#update-dns-records).

+## Validate compatibility

+1. Open Azure PowerShell and connect to your Azure account. For more information, see [Connect to Azure PowerShell](/powershell/azure/authenticate-azureps).

+1. Test your Azure Front Door (classic) profile to see if it's compatible for migration. You can use the [Test-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/test-azfrontdoorcdnprofilemigration) command to test your profile. Replace the values for the resource group name and resource ID with your own values. Use [Get-AzFrontDoor](/powershell/module/az.frontdoor/get-azfrontdoor) to get the resource ID for your Front Door (classic) profile.

+ Replace the following values in the command:

+ * `<subscriptionId>`: Your subscription ID.

+ * `<resourceGroupName>`: The resource group name of the Front Door (classic).

+ * `<frontdoorClassicName>`: The name of the Front Door (classic) profile.

+ ```powershell-interactive

+ Test-AzFrontDoorCdnProfileMigration -ResourceGroupName <resourceGroupName> -ClassicResourceReferenceId /subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.Network/frontdoors/<frontdoorClassicName>

+ ```

+ If the migration is compatible for migration, you see the following output:

+ ```

+ CanMigrate DefaultSku

+ - -

+ True Standard_AzureFrontDoor or Premium_AzureFrontDoor

+ ```

+ If the migration isn't compatible, you see the following output:

+ ```

+ CanMigrate DefaultSku

+ - -

+ False

+ ```

+## Prepare for migration

+#### [Without WAF and BYOC (Bring your own certificate)](#tab/without-waf-byoc)

+Run the [Start-AzFrontDoorCdnProfilePrepareMigration](/powershell/module/az.cdn/start-azfrontdoorcdnprofilepreparemigration) command to prepare for migration. Replace the values for the resource group name, resource ID, profile name with your own values. For *SkuName* use either **Standard_AzureFrontDoor** or **Premium_AzureFrontDoor**. The *SkuName* is based on the output from the [Test-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/test-azfrontdoorcdnprofilemigration) command.

+Replace the following values in the command:

+* `<subscriptionId>`: Your subscription ID.

+* `<resourceGroupName>`: The resource group name of the Front Door (classic).

+* `<frontdoorClassicName>`: The name of the Front Door (classic) profile.

+```powershell-interactive

+Start-AzFrontDoorCdnProfilePrepareMigration -ResourceGroupName <resourceGroupName> -ClassicResourceReferenceId /subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.Network/frontdoors/<frontdoorClassicName> -ProfileName myAzureFrontDoor -SkuName Premium_AzureFrontDoor

+```

+The output looks similar to the following:

+```

+Starting the parameter validation process.

+The parameters have been successfully validated.

+Your new Front Door profile is being created. Please wait until the process has finished completely. This may take several minutes.

+Your new Front Door profile with the configuration has been successfully created.

+```

+#### [With WAF](#tab/with-waf)

+1. Run the [Get-AzFrontDoorWafPolicy](/powershell/module/az.frontdoor/get-azfrontdoorwafpolicy) command to get the resource ID for your WAF policy. Replace the values for the resource group name and WAF policy name with your own values.

+ ```powershell-interactive

+ Get-AzFrontDoorWafPolicy -ResourceGroupName myAFDResourceGroup -Name myClassicFrontDoorWAF

+ ```

+ The output looks similar to the following:

+ ```

+ PolicyMode : Detection

+ PolicyEnabledState : Enabled

+ RedirectUrl :

+ CustomBlockResponseStatusCode : 403

+ CustomBlockResponseBody :

+ RequestBodyCheck : Disabled

+ CustomRules : {}

+ ManagedRules : {Microsoft.Azure.Commands.FrontDoor.Models.PSAzureManagedRule}

+ Etag :

+ ProvisioningState : Succeeded

+ Sku : Classic_AzureFrontDoor

+ Tags :

+ Id : /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myClassicFrontDoorWAF

+ Name : myFrontDoorWAF

+ Type :

+ ```

+1. Run the [New-AzFrontDoorCdnMigrationWebApplicationFirewallMappingObject](/powershell/module/az.cdn/new-azfrontdoorcdnmigrationwebapplicationfirewallmappingobject) command to create an in-memory object for WAF policy migration. Use the WAF ID in the last step for `MigratedFromId`. To use an existing WAF policy, replace the value for `MigratedToId` with a resource ID of a WAF policy that matches the Front Door tier you're migrating to. If you're creating a new WAF policy copy, you can change the name of the WAF policy in the resource ID.

+ ```powershell-interactive

+ $wafMapping = New-AzFrontDoorCdnMigrationWebApplicationFirewallMappingObject -MigratedFromId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myClassicFrontDoorWAF -MigratedToId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myFrontDoorWAF

+1. Run the [Start-AzFrontDoorCdnProfilePrepareMigration](/powershell/module/az.cdn/start-azfrontdoorcdnprofilepreparemigration) command to prepare for migration. Replace the values for the resource group name, resource ID, profile name with your own values. For *SkuName* use either **Standard_AzureFrontDoor** or **Premium_AzureFrontDoor**. The *SkuName* is based on the output from the [Test-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/test-azfrontdoorcdnprofilemigration) command.

+ Replace the following values in the command:

+ * `<subscriptionId>`: Your subscription ID.

+ * `<resourceGroupName>`: The resource group name of the Front Door (classic).

+ * `<frontdoorClassicName>`: The name of the Front Door (classic) profile.

+ ```powershell-interactive

+ Start-AzFrontDoorCdnProfilePrepareMigration -ResourceGroupName <resourceGroupName> -ClassicResourceReferenceId /subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.Network/frontdoors/<frontdoorClassicName> -ProfileName myAzureFrontDoor -SkuName Premium_AzureFrontDoor -MigrationWebApplicationFirewallMapping $wafMapping

+ ```

+ The output looks similar to the following:

+ ```

+ Starting the parameter validation process.

+ The parameters have been successfully validated.

+ Your new Front Door profile is being created. Please wait until the process has finished completely. This may take several minutes.

+ Your new Front Door profile with the configuration has been successfully created.

+ ```

+#### [With BYOC](#tab/with-byoc)

+If you're migrating a Front Door profile with BYOC, you need to enable managed identity on the Front Door profile. You need to grant the Front Door profile access to the key vault where the certificate is stored.

+Run the [Start-AzFrontDoorCdnProfilePrepareMigration](/powershell/module/az.cdn/start-azfrontdoorcdnprofilepreparemigration) command to prepare for migration. Replace the values for the resource group name, resource ID, profile name with your own values. For *SkuName* use either **Standard_AzureFrontDoor** or **Premium_AzureFrontDoor**. The *SkuName* is based on the output from the [Test-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/test-azfrontdoorcdnprofilemigration) command.

+### System assigned

+For *IdentityType* use **SystemAssigned**.

+```powershell-interactive

+Start-AzFrontDoorCdnProfilePrepareMigration -ResourceGroupName myAFDResourceGroup -ClassicResourceReferenceId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/Frontdoors/myAzureFrontDoorClassic -ProfileName myAzureFrontDoor -SkuName Premium_AzureFrontDoor -IdentityType SystemAssigned

+```

+### User assigned

+1. Run the [Get-AzUserAssignedIdentity](/powershell/module/az.managedserviceidentity/get-azuserassignedidentity) command to the get the resource ID for a user assigned identity.

+ ```powershell-interactive

+ $id = Get-AzUserAssignedIdentity -ResourceGroupName myResourceGroup -Name afduseridentity

+ $id.Id

+ ```

+ The output looks similar to the following:

+ ```

+ /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/afduseridentity

+ ```

+1. For IdentityType use UserAssigned and for IdentityUserAssignedIdentity,* use the resource ID from the previous step.

+ Replace the following values in the command:

+ * `<subscriptionId>`: Your subscription ID.

+ * `<resourceGroupName>`: The resource group name of the Front Door (classic).

+ * `<frontdoorClassicName>`: The name of the Front Door (classic) profile.

+ ```powershell-interactive

+ Start-AzFrontDoorCdnProfilePrepareMigration -ResourceGroupName <resourceGroupName> -ClassicResourceReferenceId /subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.Network/frontdoors/<frontdoorClassicName> -ProfileName myAzureFrontDoor -SkuName Premium_AzureFrontDoor -IdentityType UserAssigned -IdentityUserAssignedIdentity @{"/subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourceGroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/afduseridentity" = @{}}

+ ```

+ The output looks similar to the following:

+ ```

+ Starting the parameter validation process.

+ The parameters have been successfully validated.

+ Your new Front Door profile is being created. Please wait until the process has finished completely. This may take several minutes.

+ Your new Front Door profile with the configuration has been successfully created.

+ ```

+#### [Multiple WAF and managed identity](#tab/multiple-waf-managed-identity)

+This example shows how to migrate a Front Door profile with multiple WAF policies and enable both system assigned and user assigned identity.

+1. Run the [Get-AzFrontDoorWafPolicy](/powershell/module/az.frontdoor/get-azfrontdoorwafpolicy) command to get the resource ID for your WAF policy. Replace the values for the resource group name and WAF policy name with your own values.

+ ```powershell-interactive

+ Get-AzFrontDoorWafPolicy -ResourceGroupName myAFDResourceGroup -Name myClassicFrontDoorWAF

+ ```

+ The output looks similar to the following:

+ ```

+ PolicyMode : Detection

+ PolicyEnabledState : Enabled

+ RedirectUrl :

+ CustomBlockResponseStatusCode : 403

+ CustomBlockResponseBody :

+ RequestBodyCheck : Disabled

+ CustomRules : {}

+ ManagedRules : {Microsoft.Azure.Commands.FrontDoor.Models.PSAzureManagedRule}

+ Etag :

+ ProvisioningState : Succeeded

+ Sku : Classic_AzureFrontDoor

+ Tags :

+ Id : /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myClassicFrontDoorWAF

+ Name : myFrontDoorWAF

+ Type :

+ ```

+1. Run the [New-AzFrontDoorCdnMigrationWebApplicationFirewallMappingObject](/powershell/module/az.cdn/new-azfrontdoorcdnmigrationwebapplicationfirewallmappingobject) command to create an in-memory object for WAF policy migration. Use the WAF ID in the last step for `MigratedFromId`. To use an existing WAF policy, replace the value for `MigratedToId` with a resource ID of a WAF policy that matches the Front Door tier you're migrating to. If you're creating a new WAF policy copy, you can change the name of the WAF policy in the resource ID.

+ ```powershell-interactive

+ $wafMapping1 = New-AzFrontDoorCdnMigrationWebApplicationFirewallMappingObject -MigratedFromId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myClassicFrontDoorWAF1 -MigratedToId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myFrontDoorWAF1

+ $wafMapping2 = New-AzFrontDoorCdnMigrationWebApplicationFirewallMappingObject -MigratedFromId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myClassicFrontDoorWAF2 -MigratedToId /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/myFrontDoorWAF2

+ ```

+1. Specify both managed identity types in a variable.

+ ```powershell-interactive

+ $identityType = "SystemAssigned, UserAssigned"

+ ```

+1. Run the [Get-AzUserAssignedIdentity](/powershell/module/az.managedserviceidentity/get-azuserassignedidentity) command to the get the resource ID for a user assigned identity.

+ ```powershell-interactive

+ $id1 = Get-AzUserAssignedIdentity -ResourceGroupName myResourceGroup -Name afduseridentity1

+ $id1.Id

+ $id2 = Get-AzUserAssignedIdentity -ResourceGroupName myResourceGroup -Name afduseridentity2

+ $id2.Id

+ ```

+ The output looks similar to the following:

+ ```

+ /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/afduseridentity1

+ /subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourcegroups/myAFDResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/afduseridentity2

+ ```

+1. Specify the user assigned identity resource ID in a variable.

+ ```powershell-interactive

+ $userInfo = @{

+ "subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourceGroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/afduseridentity1" = @{}}

+ "subscriptions/abcdef12-3456-7890-abcd-ef1234567890/resourceGroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/afduseridentity2" = @{}}

+ }

+ ```

+1. Run the [Start-AzFrontDoorCdnProfilePrepareMigration](/powershell/module/az.cdn/start-azfrontdoorcdnprofilepreparemigration) command to prepare for migration. Replace the values for the resource group name, resource ID, profile name with your own values. For *SkuName* use either **Standard_AzureFrontDoor** or **Premium_AzureFrontDoor**. The *SkuName* is based on the output from the [Test-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/test-azfrontdoorcdnprofilemigration) command. The *MigrationWebApplicationFirewallMapping* parameter takes an array of WAF policy migration objects. The *IdentityType* parameter takes a comma separated list of identity types. The *IdentityUserAssignedIdentity* parameter takes a hash table of user assigned identity resource IDs.

+ Replace the following values in the command:

+ * `<subscriptionId>`: Your subscription ID.

+ * `<resourceGroupName>`: The resource group name of the Front Door (classic).

+ * `<frontdoorClassicName>`: The name of the Front Door (classic) profile.

+ ```powershell-interactive

+ Start-AzFrontDoorCdnProfilePrepareMigration -ResourceGroupName <resourceGroupName> -ClassicResourceReferenceId /subscriptions/<subscriptionId>/resourcegroups/<resourceGroupName>/providers/Microsoft.Network/frontdoors/<frontdoorClassicName> -ProfileName myAzureFrontDoor -SkuName Premium_AzureFrontDoor -MigrationWebApplicationFirewallMapping @($wafMapping1, $wafMapping2) -IdentityType $identityType -IdentityUserAssignedIdentity $userInfo

+ ```

+ The output looks similar to the following:

+ ```

+ Starting the parameter validation process.

+ The parameters have been successfully validated.

+ Your new Front Door profile is being created. Please wait until the process has finished completely. This may take several minutes.

+ Your new Front Door profile with the configuration has been successfully created.

+ ```

+## Migrate

+#### [Migrate profile](#tab/migrate-profile)

+Run the [Enable-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/enable-azfrontdoorcdnprofilemigration) command to migrate your Front Door (classic).

+```powershell-interactive

+Enable-AzFrontDoorCdnProfileMigration -ProfileName myAzureFrontDoor -ResourceGroupName myAFDResourceGroup

+```

+The output looks similar to the following:

+```

+Start to migrate.

+This process will disable your Front Door (classic) profile and move all your traffic and configurations to the new Front Door profile.

+Migrate succeeded.

+```

+#### [Abort migration](#tab/abort-migration)

+Run the [Stop-AzFrontDoorCdnProfileMigration](/powershell/module/az.cdn/stop-azfrontdoorcdnprofilemigration) command to abort the migration process.

+```powershell-interactive

+Stop-AzFrontDoorCdnProfileMigration -ProfileName myAzureFrontDoor -ResourceGroupName myAFDResourceGroup

+```

+The output looks similar to the following:

+```

+Start to abort the migration.

+Your new Front Door Profile will be deleted and your existing profile will remain active. WAF policies will not be deleted.

+Please wait until the process has finished completely. This may take several minutes.

+Abort succeeded.

+```

+## Update DNS records

+Your old Azure Front Door (classic) instance uses a different fully qualified domain name (FQDN) than Azure Front Door Standard and Premium. For example, an Azure Front Door (classic) endpoint might be `contoso.azurefd.net`, while the Azure Front Door Standard or Premium endpoint might be `contoso-mdjf2jfgjf82mnzx.z01.azurefd.net`. For more information about Azure Front Door Standard and Premium endpoints, see [Endpoints in Azure Front Door](endpoint.md).

+You don't need to update your DNS records before or during the migration process. Azure Front Door automatically sends traffic that it receives on the Azure Front Door (classic) endpoint to your Azure Front Door Standard or Premium profile without you making any configuration changes.

+However, once your migration is finished, we strongly recommend that you update your DNS records to direct traffic to the new Azure Front Door Standard or Premium endpoint. Changing your DNS records helps to ensure that your profile continues to work in the future. The change in DNS record doesn't cause any downtime. You don't need to plan ahead for this update to happen, and can schedule it at your convenience.

+## Next steps

+* Understand the [mapping between Front Door tiers](tier-mapping.md) settings.

+* Learn more about the [Azure Front Door tier migration process](tier-migration.md).

+ Title: Migrate Azure Front Door (classic) to Standard/Premium tier

+# Migrate Azure Front Door (classic) to Standard/Premium tier

+Azure Front Door Standard and Premium tier bring the latest cloud delivery network features to Azure. With enhanced security features and an all-in-one service, your application content is secured and closer to your end users using the Microsoft global network. This article will guide you through the migration process to move your Azure Front Door (classic) profile to either a Standard or Premium tier profile.

+ * Azure Front Door Standard and Premium requires all custom domains to use HTTPS. If you don't have your own certificate, you can use an Azure Front Door managed certificate. The certificate is free of charge and gets managed for you.

+ * Session affinity gets enabled in the origin group settings for an Azure Front Door Standard or Premium profile. In Azure Front Door (classic), session affinity is set at the domain level. As part of the migration, session affinity is based on the Front Door (classic) profile settings. If you have two domains in your classic profile that shares the same backend pool (origin group), session affinity has to be consistent across both domains in order for migration validation to pass.

+> You don't need to make any DNS changes before or during the migration process. However, once the migration completes and traffic is flowing through your new Azure Front Door profile, you need to update your DNS records. For more information, see [Update DNS records](#update-dns-records).

+1. Go to your Azure Front Door (classic) resource and select **Migration** from under *Settings*.

+1. Select **Validate** to see if your Azure Front Door (classic) profile is compatible for migration. Validation can take up to two minutes depending on the complexity of your Front Door profile.

+ :::image type="content" source="./media/migrate-tier/validate.png" alt-text="Screenshot of the validate compatibility section of the migration page.":::

+ If the migration isn't compatible, you can select **View errors** to see the list of errors, and recommendations to resolve them.

+ :::image type="content" source="./media/migrate-tier/validation-failed.png" alt-text="Screenshot of the Front Door (classic) profile failing validation phase.":::

+1. Once your Azure Front Door (classic) profile validates and is compatible for migration, you can move onto prepare phase.

+ :::image type="content" source="./media/migrate-tier/validation-passed.png" alt-text="Screenshot of the Front Door (classic) profile passing validation for migration.":::

+1. A default name has been provided for you for the new Front Door profile. You can change the profile name before proceeding to the next step.

+ :::image type="content" source="./media/migrate-tier/prepare-name.png" alt-text="Screenshot the name field in the prepare phase for the new Front Door profile.":::

+1. The Front Door tier gets automatically selected for you based on the Front Door (classic) WAF policy settings.

+ * **Standard** - If you *only have custom WAF rules* associated to the Front Door (classic) profile. You may choose to upgrade to a Premium tier.

+ * **Premium** - If you *have managed WAF rules* associated to the Front Door (classic) profile. To use Standard tier, the managed WAF rules must be removed from the Front Door (classic) profile.

+1. Select **Configure WAF policy upgrades** to configure whether you want to upgrade your current WAF policies or to use an existing compatible WAF policy.

+ > The **Configure WAF policy upgrades** link will only appear if you have WAF policies associated to the Front Door (classic) profile.

+ For each WAF policy associated to the Front Door (classic) profile select an action. You can make copy of the WAF policy that matches the tier you're migrating the Front Door profile to or you can use an existing compatible WAF policy. You may also change the WAF policy name from the default provided name. Once completed, select **Apply** to save your Front Door WAF settings.

+ :::image type="content" source="./media/migrate-tier/waf-policy.png" alt-text="Screenshot of the upgrade WAF policy screen.":::

+1. Select **Prepare**, and when prompted, select **Yes** to confirm that you would like to proceed with the migration process. Once confirmed, you won't be able to make any further changes to the Front Door (classic) profile.

+ :::image type="content" source="./media/migrate-tier/prepare-confirmation.png" alt-text="Screenshot of the prepare button and confirmation message to proceed with the migration.":::

+1. Select the link that appears to view the configuration of the new Front Door profile. At this time, you can review each of the settings for the new profile to ensure all settings are correct. Once you're done reviewing the read-only profile, select the **X** in the top right corner of the page to go back to the migration screen.

+> [!NOTE]

+> If you're not using your own certificate, enabling managed identities and granting access to the Key Vault is not required. You can skip to the [**Migrate**](#migrate) phase.

+If you're using your own certificate and you'll need to enable managed identity so Azure Front Door can access the certificate in your Azure Key Vault. Managed identity is a feature of Azure Active Directory that allows you to securely connect to other Azure services without having to manage credentials. For more information, see [What are managed identities for Azure resources?](..//active-directory/managed-identities-azure-resources/overview.md)

+1. Select **Enable** and then select either **System assigned** or **User assigned** depending on the type of managed identities you want to use.

+1. Select the **X** in the top right corner to return to the migration page. You'll then see that you've successfully enabled managed identities.

+Select **Grant** to add the managed identity to all Azure Key Vaults used with the Front Door (classic) profile.

+1. Select **Migrate** to initiate the migration process. When prompted, select **Yes** to confirm you want to move forward with the migration. The migration may take a few minutes depending on the complexity of your Front Door (classic) profile.

+ > If you cancel the migration, only the new Front Door profile gets deleted. Any new WAF policy copies will need to be manually deleted.

+1. Once migration completes, you can select the banner the top of the page or the link at the bottom from the successful message to go to the new Front Door profile.

+1. The Front Door (classic) profile is now **Disabled** and can be deleted from your subscription.

+ :::image type="content" source="./media/migrate-tier/classic-profile.png" alt-text="Screenshot of the overview page of a Front Door (classic) in disabled state.":::

+> [!WARNING]

+> Once migration has completed, if you delete the new profile that will delete the production environment, which is an irreversible change.

+Your old Azure Front Door (classic) instance uses a different fully qualified domain name (FQDN) than Azure Front Door Standard and Premium. For example, an Azure Front Door (classic) endpoint might be `contoso.azurefd.net`, while the Azure Front Door Standard or Premium endpoint might be `contoso-mdjf2jfgjf82mnzx.z01.azurefd.net`. For more information about Azure Front Door Standard and Premium endpoints, see [Endpoints in Azure Front Door](endpoint.md).

+However, once your migration is finished, we strongly recommend that you update your DNS records to direct traffic to the new Azure Front Door Standard or Premium endpoint. Changing your DNS records helps to ensure that your profile continues to work in the future. The change in DNS record won't cause any downtime. You don't need to plan ahead for this update to happen, and can schedule it at your convenience.

+ Title: Settings mapping between Azure Front Door (classic) and Standard/Premium tier

+description: This article explains the differences between settings mapped between an Azure Front Door (classic) and Azure Front Door Standard or Premium profile.

+# Settings mapped between Azure Front Door (classic) and Standard/Premium tier

+When you migrate your Azure Front Door (classic) to Azure Front Door Standard or Premium, you'll notice some configurations have been either changed, or relocated to provide a better experience when managing your Front Door profile. In this article you'll learn how routing rules, cache duration, rules engine configuration, WAF policy and custom domains are mapped in the new Front Door tier.

+| Front Door (classic) settings | Mapping in Front Door Standard and Premium |

+| Route status - enable/disable | Changes to **Enable route** with checkbox. Location remains the same. |

+| Frontend/domains | Changes to **Domains**. Copied from Front Door (classic) profile. |

+| Rules engine configuration | The rules engine configuration name changes to rule set but will retain its association to routes from the Front Door (classic) profile. |

+| Route type: *Forwarding* | Backend pool changes to origin group. Forwarding protocol is copied from the Front Door (classic) profile. </br> - If URL rewrite is set to **disabled**, the origin path in Standard or Premium profile is *blank*. </br> - If URL rewrite is set to **enabled**, the *Custom forwarding path* of the Front Door (classic) profile is set as the *origin path*. |

+| Route type: Redirect | A URL redirect rule set gets created called *URLRedirectMigratedRuleSet1* with a URL redirect rule. |

+In Azure Front Door (classic), the *Minimum cache duration* is configured in the routing rules settings and the *Use default cache duration* is set in the Rules engine configuration. Azure Front Door Standard and Premium only supports changing caching duration in a Rule set rule.

+| Front Door (classic) | Mapping in Front Door Standard and Premium |

+| Caching is **disabled** and default caching is used. | Caching is set to **disabled**. |

+| Caching is **enabled** and the default caching duration is used. | Caching is set to **enabled**, the origin caching behavior is honored. |

+| Caching is **enabled** and minimum caching duration is set. | Caching is set to **enabled** and the cache behavior is set to **override always** with the minimum cache duration from Front Door (classic). |

+| N/A | Caching is set to **enabled**. The caching behavior is set to override if the origin is missing, and the input cache duration gets used. |

+## Route configuration override in rules engine configuration

+The route configuration override in a rules engine configuration action for Front Door (classic) is split into three different actions in a Rule set rule for Azure Front Door Standard and Premium. Those three actions are URL redirect, URL rewrite and route configuration override.

+| Actions in rules engine configuration | Mapping in Front Door Standard and Premium |

+| Route type set to **Forward** | 1. If URL rewrite is **disabled**, all settings are copied over to the Standard or Premium profile.</br>2. If URL rewrite is **enabled**, two rule actions will be created. One for URL rewrite and one for the route configuration override setting. For the URL rewrite action, the *custom forwarding path* in Front Door (classic) profile is set to the **destination**. |

+| Route type set to **Redirect** | URL redirect action settings are copied over. |

+| Route configuration override | Backend pool is mapped to an origin group. Enabling caching remains the same. Query string is mapped to query string caching behavior, dynamic compression is mapped to compression.

+| Use default cache duration | For more information, see [cache duration](#cache-duration) section. |

+| Front Door (classic) configuration | Mapping in Front Door Standard and Premium |

+| Request and response header | Request and response header in Rules engine actions is copied over to Rule set. |

+| Enforce certificate name check | Enforce certificate name check is supported at the profile level of an Azure Front Door (classic). In Azure Front Door Standard or Premium profile this setting can be found in the origin settings. This configuration gets applied to all origins in the migrated profile. |

+| Origin response time | Origin response time gets copied over to the migrated profile. |

+| Web Application Firewall (WAF) | If the Azure Front Door (classic) profile has WAF policies associated, the migration will create a copy of each WAF policy for the respective tier migrating to. Names for each WAF policy can be changed during prepare phase of the migration. You can also select an existing Front Door Standard or Premium WAF policy that matches the migrated Front Door profile. |

+| Custom domain | This section will use `www.contoso.com` as an example to show what happens to a domain going through the migration. The custom domain `www.contoso.com` points to `contoso.azurefd.net` in the Front Door (classic) as a CNAME record. </br></br>When `www.contoso.com` gets moved to the new Front Door profile:</br>- The association for the custom domain shows the new Front Door endpoint as `contoso-<hashvalue>.z01.azurefd.net`. The CNAME of the custom domain will automatically point to the new endpoint name with the hash value in the backend. At this point, you can change the CNAME record with your DNS provider to point to the new endpoint name with the hash value.</br>- The classic endpoint `contoso.azurefd.net` will show as a custom domain in the migrated Front Door profile under the *Migrated domain* tab of the **Domains* page. This domain will be associated to the default migrated route. This default route can only be removed once the domain is disassociated from it. The domain properties can't be updated, except for when associating and removing the association from a route. The domain can only be deleted after you've changed the CNAME to the new endpoint name.</br>- The certificate state and DNS state for `www.contoso.com` will be consistent as the Front Door (classic) profile.</br></br> No changes are made the managed certificate auto rotation settings. |

+* Learn more about the [Azure Front Door migration process](tier-migration.md).

+* Learn how to [migrate from Azure Front Door (classic) to Azure Front Door Standard or Premium](migrate-tier.md) using the Azure portal.

+* Learn how to [migrate from Azure Front Door (classic) to Azure Front Door Standard or Premium](migrate-tier-powershell.md) using the Azure PowerShell.

+ Title: About Azure Front Door (classic) to Standard/Premium tier migration

+# About Azure Front Door (classic) to Standard/Premium tier migration

+Azure Front Door Standard and Premium tier were released in March 2022 as the next generation content delivery network service. The newer tiers combine the capabilities of Azure Front Door (classic), Microsoft CDN (classic), and Web Application Firewall (WAF). With features such as Private Link integration, enhanced rules engine and advanced diagnostics you have the ability to secure and accelerate your web applications to bring a better experience to your customers.

+We recommend migrating your classic profile to one of the newer tier to benefit from the new features and improvements. To ease the move to the new tiers, Azure Front Door provides a zero-downtime migration to move your workload from Azure Front Door (classic) to either Standard or Premium.

+Migrating to Standard or Premium tier for Azure Front Door happens in either three or five phases depending on if you're using your certificate. The time it takes to migrate depends on the complexity of your Azure Front Door (classic) profile. You can expect the migration to take a few minutes for a simple Azure Front Door profile and longer for a profile that has multiple frontend domains, backend pools, routing rules and rule engine rules.

+### Phases of migration

+#### Validate compatibility

+The migration tool checks to see if your Azure Front Door (classic) profile is compatible for migration. If validation fails, you're provided with suggestions on how to resolve any issues before you can validate again.

+* Azure Front Door Standard and Premium require all custom domains to use HTTPS. If you don't have your own certificate, you can use an Azure Front Door managed certificate. The certificate is free of charge and gets managed for you.

+* Session affinity gets enabled in the origin group settings for an Azure Front Door Standard or Premium profile. In Azure Front Door (classic), session affinity is set at the domain level. As part of the migration, session affinity is based on the Front Door (classic) profile settings. If you have two domains in your Front Door (classic) profile that shares the same backend pool, session affinity has to be consistent across both domains in order for migration validation to pass.

+* If you're using BYOC (Bring Your Own Certificate) for Azure Front Door (classic), you need to [grant Key Vault access](standard-premium/how-to-configure-https-custom-domain.md#register-azure-front-door) to Azure Front Door Standard or Premium. This step is required for Azure Front Door Standard or Premium to access your certificate in Key Vault. If you're using Azure Front Door managed certificate, you don't need to grant Key Vault access.

+#### Prepare for migration

+Azure Front Door creates a new Standard or Premium profile based on your Front Door (classic) profile's configuration. The new Front Door profile tier depends on the Web Application Firewall (WAF) policy settings you associate with the profile.

+* **Premium** - If your WAF policy has **managed WAF rules** associated to the Azure Front Door (classic) profile.

+* **Standard** - If your WAF policy only has **custom WAF rules** associated to the Azure Front Door (classic) profile.

+> A standard tier Front Door profile **can** be upgraded to premium tier after migration. However, a premium tier Front Door profile **can't** be downgraded to standard tier after migration.

+During the preparation phase, Azure Front Door creates a copy of each WAF policy associated to the Front Door (classic) profile. The WAF policy tier is specific to the tier you're migrating to. A default name is provided for each WAF policy and you can change the name during this phase. You also can select an existing WAF policy that matches the tier you're migrating to instead of making a copy. Once the preparation phase is completed, a read-only view of the new Front Door profile is provided for you to verify configurations.

+> [!IMPORTANT]

+> You won't be able to make changes to the Front Door (classic) configuration once the preparation phase has been initiated.

+#### Enable managed identity

+During this step, you configure managed identity for Azure Front Door to access your certificate in an Azure Key Vault. Managed identity is required if you're using BYOC (Bring Your Own Certificate) for Azure Front Door (classic). If you're using Azure Front Door managed certificate, you don't need to grant Key Vault access.

+#### Grant managed identity to Key Vault

+This step adds managed identity access to all Azure Key Vaults used in the Front Door (classic) profile.

+#### Migrate

+

+Once migration begins, the Azure Front Door (classic) profile gets disabled and the Azure Front Door Standard, or Premium profile gets activated. Traffic starts flowing through the new profile once the migration completes.

+If you decided you no longer want to move forward with the migration process, you can select **Abort migration**. Aborting the migration deletes the new Front Door profile that was created. The Azure Front Door (classic) profile remains active and you can continue to use it. Any WAF policy copies need to be manually deleted.

+Service charges for Azure Front Door Standard or Premium tier start once migration is completed.

+## Breaking changes when migrating to Standard or Premium tier

+### Dev-ops

+Azure Front Door Standard and Premium use a different resource provider namespace of *Microsoft.Cdn*, while Azure Front Door (classic) uses *Microsoft.Network*. After you migrate your Azure Front Door profile, you'll need to change your Dev-ops script to use the new namespace, updated Azure PowerShell module, CLI commands and APIs.

+### Endpoint with hash value

+Azure Front Door Standard and Premium endpoints are generated to include a hash value to prevent your domain from being taken over. The format of the endpoint name is `<endpointname>-<hashvalue>.z01.azurefd.net`. The Front Door (classic) endpoint name will continue to work after migration but we recommend replacing it with the newly created endpoint name from your new Standard or Premium profile. For more information, see [Endpoint domain names](endpoint.md#endpoint-domain-names).

+### Logs and metrics

+Diagnostic logs and metrics aren't migrated. Azure Front Door Standard and Premium log fields are different from Azure Front Door (classic). Standard and Premium tier has heath probe logging and we recommend that you enable diagnostic logging after you migrate. Standard and Premium tier also supports built-in reports that start displaying data once the migration is completed. For more information, see [Azure Front Door reports](standard-premium/how-to-reports.md).

+The default Azure Front Door tier selected for migration gets determined by the type of rules contain in the WAF policy. In this section, we cover scenarios for different rule types for a WAF policy.

+**Classic WAF policy with only custom rules** - the new Azure Front Door profile defaults to Standard tier and can be upgraded to Premium during the migration. If you use the portal for migration, Azure creates custom WAF rules for Standard. If you upgrade to Premium during migration, custom WAF rules are created as part of the migration process. You'll need to add managed WAF rules manually after migration if you want to use managed rules.

+**Classic WAF policy with only managed WAF rules, or both managed and custom WAF rules** - the new Azure Front Door profile defaults to Premium tier and can't be downgraded during the migration. If you want to use Standard tier, then you need to remove the WAF policy association or delete the manage WAF rules from the Front Door (classic) WAF policy.

+> [!NOTE]

+> To avoid creating duplicate WAF policies during migration, the migration capability provides the option to either create copies or use an existing Azure Front Door Standard or Premium WAF policy.

+### Azure Policy for Azure Front Door WAF

+[Azure Policy for WAF](../web-application-firewall/shared/waf-azure-policy.md) is not available for Azure Front Door Standard and Premium. Azure Policy lets you set and check WAF standards for your organization at a large scale. This feature will be available in the near future.

+## Naming convention used for migration

+During the migration, a default profile name is used in the format of `<endpointprefix>-migrated`. For example, an Azure Front Door (classic) endpoint named `myEndpoint.azurefd.net`, has the default name of `myEndpoint-migrated`.

+A WAF policy name has `-standard` or `-premium` appended to the classic WAF policy name. For example, a Front Door (classic) WAF policy named `contosoWAF1`, has the default name of `contosoWAF1-premium`. You can rename both the Front Door profile and WAF policy during migration process. Renaming of rules engine configuration and routes aren't supported and instead default names are assigned.

+URL redirect and URL rewrite are supported through rules engine in Azure Front Door Standard and Premium, while Azure Front Door (classic) supports them through routing rules. During migration, these two rules get created as rule set rules in a Standard and Premium profile. The namings of these rules are `urlRewriteMigrated` and `urlRedirectMigrated`.

+| Before migration | Active | Yes | N/A | N/A |

+| Validating compatibility | Active | Yes | N/A | N/A |

+| Prepare for migration | Migrating | No | Creating | No |

+| Committing migration | Migrating | No | CommittingMigration | No |

+| Committed migration | Migrated | No | Active | Yes |

+| Aborting migration | AbortingMigration | No | Deleting | No |

+| Aborted migration | Active | Yes | Deleted | N/A |

+* Understand the [settings mapping between Azure Front Door tiers](tier-mapping.md).

+* Learn how to [migrate from Azure Front Door (classic) to Standard or Premium tier](migrate-tier.md) using the Azure portal.

+* Learn how to [migrate from Azure Front Door (classic) to Standard or Premium tier](migrate-tier-powershell.md) using Azure PowerShell.

+ Title: Upgrade from Azure Front Door Standard to Premium with Azure PowerShell

+description: This article shows you how to upgrade from an Azure Front Door Standard to an Azure Front Door Premium profile with Azure PowerShell.

+# Upgrade from Azure Front Door Standard to Premium with Azure PowerShell

+Azure Front Door supports upgrading from Standard to Premium for more advanced capabilities and an increase in quota limit. The upgrade doesn't cause any downtime to your services or applications. For more information about the differences between Standard and Premium, see [Tier comparison](standard-premium/tier-comparison.md).

+This article walks you through how to perform the tier upgrade for an Azure Front Door Standard profile. Once upgraded, you're charged for the Azure Front Door Premium monthly base fee at an hourly rate.

+> [!IMPORTANT]

+> Downgrading from **Premium** to **Standard** isn't supported.

+## Prerequisite

+* Confirm you have an Azure Front Door Standard profile available in your subscription to upgrade.

+* Latest Azure PowerShell module installed locally or Azure Cloud Shell. For more information, see [Install and configure Azure PowerShell](/powershell/azure/install-azure-powershell).

+## Upgrade tier

+Run the [Update-AzFrontDoorCdnProfile](/powershell/module/az.cdn/update-azfrontdoorcdnprofile) command to upgrade your Azure Front Door Standard profile to Premium. The following example shows the command to upgrade a profile named **myAzureFrontDoor** in the resource group **myAFDResourceGroup**.

+### No WAF policies associated

+```powershell-interactive

+Update-AzFrontDoorCdnProfile -ProfileName myAzureFrontDoor -ResourceGroupName myAFDResourceGroup -ProfileUpgradeParameter @{}

+```

+The following example shows the output of the command:

+```

+Location Name Kind ResourceGroupName

+-- - - --

+Global myAzureFrontDoor frontdoor myAFDResourceGroup

+```

+### WAF policies associated

+1. Run the [New-AzFrontDoorCdnProfileChangeSkuWafMappingObject](/powershell/module/az.cdn/new-azfrontdoorcdnprofilechangeskuwafmappingobject) command to create a new object for the WAF policy mapping. This command maps the standard WAF policy to the premium WAF policy resource ID. The premium WAF policy can be an existing one or a new one. If you're using an existing one, replace the WafPolicyId value with the resource ID of the premium WAF policy. If you're creating a new one, replace the `premiumWAFPolicyName` value with the name of the premium WAF policy. In this example, we're creating two premium WAF policies named **myPremiumWAFPolicy1** and **myPremiumWAFPolicy2**.

+ ```powershell-interactive

+ Replace the following values in the command:

+ * `<subscriptionId>`: Your subscription ID.

+ * `<resourceGroupName>`: The resource group name of the WAF policy.

+ * `<standardWAFPolicyName>`: The name of the standard WAF policy.

+ ```powershell-interactive

+ $waf1 = New-AzFrontDoorCdnProfileChangeSkuWafMappingObject SecurityPolicyName <standardWAFPolicyName> -WafPolicyId /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/frontDoorWebApplicationFirewallPolicies/myPremiumWAFPolicy1

+ $waf2 = New-AzFrontDoorCdnProfileChangeSkuWafMappingObject SecurityPolicyName <standardWAFPolicyName> -WafPolicyId /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/frontDoorWebApplicationFirewallPolicies/myPremiumWAFPolicy2

+ ```

+1. Run the [New-AzFrontDoorCdnProfileUpgradeParametersObject](/powershell/module/az.cdn/new-azfrontdoorcdnprofileupgradeparametersobject) command to create a new object for the upgrade parameters.

+ ```powershell-interactive

+ $upgradeParams = New-AzFrontDoorCdnProfileUpgradeParametersObject -WafPolicyMapping @{$waf1, $waf2}

+ ```

+1. Run the [Update-AzFrontDoorCdnProfile](/powershell/module/az.cdn/update-azfrontdoorcdnprofile) command to upgrade your Azure Front Door Standard profile to Premium. The following example shows the command to upgrade a profile named **myAzureFrontDoor** in the resource group **myAFDResourceGroup**.

+ ```powershell-interactive

+ Update-AzFrontDoorCdnProfile -ProfileName myAzureFrontDoor -ResourceGroupName myAFDResourceGroup -ProfileUpgradeParameter $upgradeParams

+ ```

+ The following example shows the output of the command:

+ ```

+ Location Name Kind ResourceGroupName

+ -- - - --

+ Global myAzureFrontDoor frontdoor myAFDResourceGroup

+ ```

+> [!NOTE]

+> You're now being billed for the Azure Front Door Premium at an hourly rate.

+## Next steps

+* Learn more about [Managed rule for Azure Front Door WAF policy](../web-application-firewall/afds/waf-front-door-drs.md).

+* Learn how to enable [Private Link to origin resources in Azure Front Door](private-link.md).

+ Title: Upgrade from Azure Front Door Standard to Premium

+description: This article shows you how to upgrade from an Azure Front Door Standard to an Azure Front Door Premium profile.

+# Upgrade from Azure Front Door Standard to Premium

+Azure Front Door supports upgrading from Standard to Premium for more advanced capabilities and an increase in quota limit. The upgrade doesn't cause any downtime to your services or applications. For more information about the differences between Standard and Premium, see [Tier comparison](standard-premium/tier-comparison.md).

+This article walks you through how to perform the tier upgrade for an Azure Front Door Standard profile. Once upgraded, you're charged for the Azure Front Door Premium monthly base fee at an hourly rate.

+> Downgrading from **Premium** to **Standard** isn't supported.

+1. Go to the Azure Front Door Standard profile you want to upgrade and select **Configuration** from under *Settings*.

+1. Select **Upgrade** to begin the upgrade process. If you don't have any WAF policies associated to your Front Door Standard profile, then you're prompted with a confirmation to proceed with the upgrade.

+1. If you have WAF policies associated to the Front Door Standard profile, then you're taken to the *Upgrade WAF policies* page. On this page, you decide whether you want to make copies of the WAF policies or use an existing premium WAF policy. You can also change the name of the new WAF policy copy during this step.

+ > To use managed WAF rules for the new premium WAF policy copies, you'll need to manually enable them after upgrading the Front Door profile.

+1. Select **Upgrade** once you're done setting up WAF policies. Select **Yes** to confirm you would like to proceed with the upgrade.

+1. The upgrade process creates a new premium WAF policy and associates it to the Front Door Premium profile. The upgrade can take a few minutes to complete depending on the complexity of your Front Door Standard profile.

+1. Once the upgrade completes, you see **Tier: Premium** display on the *Configuration* page.

+ > You're now being billed for the Azure Front Door Premium at an hourly rate.

+* Learn more about [Managed rule for Azure Front Door WAF policy](../web-application-firewall/afds/waf-front-door-drs.md).

+* Learn how to enable [Private Link to origin resources in Azure Front Door](private-link.md).

+- Azure Policy Add-on for Kubernetes is supported on [supported Kubernetes versions in Azure Kubernetes Service (AKS)](../../../aks/supported-kubernetes-versions.md).

+You receive an error message stating the input isn't a valid Base-64 string as it contains a nonbase 64 character, more than two padding characters, or a nonwhite space character among the padding characters.

+When using PowerShell or Azure template deployment to create clusters with Data Lake as either primary or more storage, the service principal certificate contents provided to access the Data Lake storage account is in the base-64 format. Improper conversion of pfx certificate contents to base-64 encoded string can lead to this error.

+|Import functionality isn't working as expected when NDJSON file size is greater than 2 GB. Customer sees the import job stuck in retry mode.| June 2023| Suggested workaround is to reduce file size less than 2 GB.|--|

+|The SQL provider causes the `RawResource` column in the database to save incorrectly. This occurs in a few cases when a transient exception occurs that causes the provider to use its retry logic.ΓÇ»|April 2022 |-|May 2022 Resolved [#2571](https://github.com/microsoft/fhir-server/pull/2571) |

+We have seen issues where complex FHIR queries with Reference Search Parameters would time out. Issue is fixed by updating the SQL query generator to use an INNER JOIN for Reference Search Parameters. For details, visit [#3295](https://github.com/microsoft/fhir-server/pull/3295).

+#### DICOM Service

+**Retrieve rendered image is GA**

+[Rendered images](dicom/dicom-services-conformance-statement.md#retrieve-rendered-image-for-instance-or-frame) can now be retrieved from the DICOM service by using the new rendered endpoint. This API allows a DICOM instance or frame to be accessed in a consumer format (`jpeg` or `png`), a capability that can simplify scenarios such as a client application displaying an image preview.

+**Fixed issue where DICOM events and Change Feed may miss changes**

+The DICOM Change Feed API could previously return results that incorrectly skipped pending changes when the DICOM server was under load. Identical calls to the Change Feed resource could have resulted in new change events appearing in the middle of the result set. For example, if the first call returned sequence numbers `1`, `2`, `3`, and `5`, then the second identical call could have incorrectly returned `1`, `2`, `3`, `4`, and `5`. This behavior also impacted the DICOM events sent to Azure Event Grid System Topics, and could have resulted in missing events in downstream event handlers. For more details, see [#2611](https://github.com/microsoft/dicom-server/pull/2611).

+description: This article lists the key quotas and limits that apply to an IoT Central application including from the underlying DPS and IoT Hub services.

+| Maximum size of a device-to-cloud message | 256 KB | The IoT Hub service sets this value. |

+| Maximum size of a cloud-to-device message | 64 KB | The IoT Hub service sets this value. |

+| Number of property updates per second | 100 | This limit is a soft limit. IoT Central autoscales the application as needed¹. |

+| Properties | Maximum size of desired properties and reported properties sections are 32 KB each. Maximum size of tags section is 8 KB. Maximum size of each individual property in every section is 4 KB. | The IoT Hub service sets these values. |

+| Number of command executions per second | 20 | This limit is a soft limit. IoT Central autoscales the application as needed¹. |

+| Number of devices registrations per minute | 200 | The underlying DPS instance sets this quota. Contact support to discuss increasing this quota for your application. |

+| Maximum user role assignments per application | 200 | This limit isn't the same as the number of users per application. |

+| Maximum roles per application | 50 | This limit includes the default application and organization roles. |

+Continuous integration and continuous delivery (CI/CD) refers to the process of developing and delivering software in short, frequent cycles using automation pipelines. This article shows you how to automate the build, test, and deployment of an IoT Central application configuration. This automation enables development teams to deliver reliable releases more frequently.

+Continuous integration starts with a commit of your code to a branch in a source code repository. Each commit is merged with commits from other developers to ensure that no conflicts are introduced. Changes are further validated by creating a build and running automated tests against that build. This process ultimately results in an artifact, or deployment bundle, to deploy to a target environment. In this case, the target is an Azure IoT Central application.

+In this guide, you create a pipeline that only applies an IoT Central configuration to a single instance of an IoT Central application. You should integrate the steps into a larger pipeline that deploys your entire solution and promotes it from *development* to *QA* to *preproduction* to *production*, performing all necessary testing along the way.

+While Azure Pipelines can integrate directly with a key vault, a pipeline needs a service principal for some dynamic key vault interactions such as fetching secrets for data export destinations.

+Now that you know how to integrate IoT Central configurations into your CI/CD pipelines, a suggested next step is to learn how to [Manage and monitor IoT Central from the Azure portal](howto-manage-iot-central-from-portal.md).

+To add a file upload storage account configuration:

+To test the file upload, you run a sample device application. Create a device template for the sample device to use.

+1. Select the *File Upload Device Sample* device template that you created earlier.

+1. Select the device that you created and Select **Connect**

+Copy the values for `ID scope`, `Device ID`, and `Primary key`. You use these values in the device sample code.

+Open the git repository you downloaded in VS Code. Create an ".env" file at the root of your project and add the values you copied previously. The file should look like the following sample with the values you made a note of previously.

+Open the git repository you downloaded in VS Code. Press F5 to run/debug the sample. In your terminal window you see that the device is registered and is connected to IoT Central:

+The sample project comes with a sample file named *datafile.json*. This file is uploaded when you use the **Upload File** command in your IoT Central application.

+To test the upload, open your application and select the device you created. Select the **Command** tab and you see a button named **Run**. When you select that button the IoT Central app calls a direct method on your device to upload the file. You can see this direct method in the sample code in the /device.ts file. The method is named *uploadFileCommand*.

+description: This article describes customer data residency in Azure IoT Central applications and how it relates to Azure geographies.

+IoT Central doesn't store customer data outside of the customer specified geography except for the following scenarios:

+- IoT Central uses the Device Provisioning Service (DPS) internally. DPS uses the same device provisioning endpoint for all provisioning service instances, and performs traffic load balancing to the nearest available service endpoint. As a result, authentication secrets may be temporarily transferred outside of the region where the DPS instance was initially created. However, once the device is connected, the device data flows directly to the original region of the DPS instance.

+Version 2022-07-31 of the data plane API lets you manage the following resources in your IoT Central application:

+- Enrollment groups

+- Jobs

+- Scheduled jobs

+The preview devices API also lets you [manage dashboards](howto-manage-dashboards-with-rest-api.md), [manage deployment manifests](howto-manage-deployment-manifests-with-rest-api.md), and [manage data exports](howto-manage-data-export-with-rest-api.md).

+Currently, IoT Central can export data to:

+- Dashboards and views:

+- Built-in rules and analytics:

+ Use the IoT Central continuous data export feature to publish captured IoT data into an Azure data lake. Then use a connected to Azure Databricks workspace to compute OEE and OPE. Pipe the same data to Azure Machine Learning or Azure Synapse to use their machine learning capabilities.

+ IoT Central provides feature-rich dashboards and visualizations. However, business-specific reports may require you to merge IoT data with existing business data sourced from external systems. Use the IoT Central integration features to extract IoT data from IoT Central. Then merge the IoT data with existing business data to deliver a centralized solution for analyzing and visualizing your business processes.

+You launch your IoT Central application by navigating to the URL you chose during app creation. You can see a list of all the applications you have access to in the [IoT Central app manager](https://apps.azureiotcentral.com/myapps).

+ **Data explorer** exposes rich capabilities to analyze historical trends and correlate various telemetry types from your devices.

+Data explorer exposes rich capabilities to analyze historical trends and correlate various telemetry types from your devices. To learn more, see the [Create analytics for your Azure IoT Central application](howto-create-analytics.md) article.

+You're using a managed identity to authorize the connection to an export destination. Data isn't arriving at the export destination.

+- Enable the managed identity for the application.

+Smart meters not only enable automated billing, but also advanced metering use cases such as real-time readings and bidirectional communication.

+An application template enables utilities and partners to monitor smart meter status, telemetry, and define alarms and notifications. The template provides sample commands, such as disconnecting a meter and updating software. You can export the meter data to other business applications and use the data to develop custom solutions.

+The application's key functionality includes:

+A smart meter records and communicates energy consumption data to utilities for monitoring and other use cases, such as billing and demand response.

+When you build an Internet of Things (IoT) solution, Azure IoT Central simplifies the build process and helps reduce the burden and costs of IoT management, operations, and development. With Azure IoT Central, you can easily connect, monitor, and manage your IoT assets at scale.

+After you connect your smart meters to Azure IoT Central, the application template uses built-in features such as device models, commands, and dashboards. The application template also uses the Azure IoT Central storage for warm path scenarios such as near real-time meter data monitoring, analytics, rules, and visualizations.

+### IoT Central extensibility options

+The Azure IoT Central platform provides two extensibility options: data export and APIs. Customers and partners can choose between these options to customize their solutions for their specific needs.

+For example, a partner might configure data export to continuously send data to Azure Data Lake Storage. That partner can then use Data Lake Storage for long-term data retention and other scenarios for cold path storage, such batch processing, auditing, and reporting.

+1. Go to the [Azure IoT Central build](https://aka.ms/iotcentral) site. Then sign in with a Microsoft personal, work, or school account.

+- Review the latest meter info and its installed [location](../core/howto-use-location-data.md) on the map.

+- Proactively check the meter network and connection status.

+- Monitor minimum and maximum voltage readings for network health.

+- Review the energy, power, and voltage trends to catch any anomalous patterns.

+- Track the total energy consumption for planning and billing purposes.

+- Perform command and control operations, such as reconnecting a meter and updating a firmware version. In the template, the command buttons show the possible functionalities and don't send real commands.

+The solar panel monitoring app enables utilities and partners to monitor solar panels, such as their energy generation and connection status in near real time. It can send notifications based on defined threshold criteria. It provides sample commands, such as update firmware. You can export the solar panel data to other business applications.

+Solar panels are a source of renewable energy. Typically, a solar panel uses a gateway to connect to an IoT Central application. You might need to build IoT Central device bridge to connect devices that can't connect directly. The [IoT Central device bridge](../core/howto-build-iotc-device-bridge.md) is an open-source bridge solution.

+When you build an IoT solution, Azure IoT Central simplifies the build process and helps to reduce the burden and costs of IoT management, operations, and development. With IoT Central, you can easily connect, monitor, and manage your IoT assets at scale. After you connect your solar panels to IoT Central, the application template uses built-in features such as device models, commands, and dashboards. The application template also uses the IoT Central storage for warm path scenarios such as near real-time meter data monitoring, analytics, rules, and visualization.

+The IoT Central platform provides two extensibility options: data export and APIs. The customers and partners can choose between these options to customize their solutions for specific needs. For example, use data export to send telemetry to Azure Data Lake Storage (ADLS). Use ADLS for long-term data retention and other cold path storage scenarios, such batch processing, auditing, and reporting.

+After you deploy the application template, you can explore the application. The application comes with sample smart meter device, device template, and dashboard.

+Adatum is a fictitious energy company that monitors and manages solar panels. On the solar panel monitoring dashboard, you see solar panel properties, data, and sample commands. This dashboard allows you or your support team to complete the following tasks, before any issues require extra support resources:

+- Review the latest panel info and its installed location on the map.

+- Check the panel status and connection status.

+- Review the energy generation and temperature trends to catch any anomalous patterns.

+- Track the total energy generation for planning and billing purposes.

+- Activate a panel and update the firmware version, if necessary. In the template, the command buttons show the possible functionalities, and don't send real commands.

+As shown in the previous application architecture diagram, you can use the application template to:

+ An IoT solution starts with a set of sensors that capture meaningful signals from within a retail store environment. The various icons at the far left of the architecture diagram represent the sensors.

+In this tutorial, you learn how to:

+Create the application by completing the following steps:

+You can change several settings to customize the user experience in your application. In this section, you select a predefined application theme. You can also learn how to create a custom theme and update the application image. A custom theme enables you to set the application browser colors, the browser icon, and the application logo that appears in the masthead.

+To create a custom theme, you can use a set of sample images to customize the application and complete the tutorial. Download the [Contoso sample images](https://github.com/Azure-Samples/iot-central-docs-samples/tree/main/retail).

+1. Select **Change**, and then select a **Browser icon** image to appear on browser tabs.

+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.

+The *In-store analytics - checkout* application template has device templates for several devices, including templates for two of the three devices you use in the application. The RuuviTag device template isn't included in the *In-store analytics - checkout* application template.

+1. Select **Create**.

+1. On the left pane, select **Device templates**.

+You can customize the device templates in your application in three ways:

+1. Change the **Semantic Type** option from **Relative humidity** to **Humidity**.

+1. For **Display Name**, enter the **Location** value.

+1. In the **Schema** dropdown list, select **String**.

+- A simulated *Occupancy* sensor. This simulated sensor is included in the application template, so you don't need to create it.

+As part of using sensors in your Azure IoT Central application to monitor conditions, you can create rules to run actions when certain conditions are met.

+In this tutorial, you learn how to:

+After you've created your condition-monitoring application, you can edit its default dashboard. You can also create more dashboards.

+An Azure IoT Central application dashboard consists of one or more tiles. A tile is a rectangular container for displaying content on a dashboard. You associate various types of content with tiles, and you can drag, drop, and resize tiles to customize the dashboard layout.

+The example Contoso store map shows four zones: two checkout zones, a zone for apparel and personal care, and a zone for groceries and deli.

+In this tutorial, you associate sensors with these zones to provide telemetry.

+After you've removed the unused tiles, rearrange the remaining tiles to create an organized layout. The new layout includes space for tiles that you add later.

+Application operators also use the dashboard to manage devices by running commands. You can add command tiles to the dashboard that execute predefined commands on a device. In this section, you add a command tile to enable operators to reboot the Rigado gateway.

+Your Power BI dashboard displays data from your retail monitoring application. In this solution, you use Power BI streaming datasets as the data source for the Power BI dashboard. In this section, you define the schema of the streaming datasets so that the logic app can forward data from the event hub. The following steps show you how to create two streaming datasets for the environmental sensors and one streaming dataset for the occupancy sensor:

+You now have two streaming datasets. The logic app routes telemetry from the two environmental sensors connected to your **In-store analytics - checkout** application to these two datasets:

+1. On the **Create** page:

+You can use IoT sensors to collect and monitor ambient conditions such as temperature, humidity, tilt, shock, light, and the location of a shipment. In cloud-based business intelligence systems, you can combine telemetry gathered from sensors and devices with other data sources such as weather and traffic information.

+This tutorial shows you how to get started with the IoT Central *connected logistics* application template. You learn how to deploy and use the template.

+ - **Application name**: you can use default suggested name or enter your friendly application name.

+ - **URL**: you can use suggested default URL or enter your friendly unique memorable URL.

+ - **Billing Info**: The directory, Azure subscription, and region details are required to provision the resources.

+ - **Create**: Select create at the bottom of the page to deploy your application.

+This preconfigured dashboard shows the critical logistics device operations activity.

+- View the logistics routes for truck shipments and the details of ocean shipments.

+- View the gateway status and other relevant information.

+- You can track the total number of gateways, active, and unknown tags.

+- You can do device management operations such as: update firmware, disable and enable sensors, update a sensor threshold, update telemetry intervals, and update device service contracts.

+- View device battery consumption.

+Select **Device templates** to see the gateway capability model. A capability model is structured around two interfaces:

+- **Gateway Telemetry & Property** - This interface defines all the telemetry related to sensors, location, and device information. The interface also defines device twin property capabilities such as sensor thresholds and update intervals.

+- **Gateway Commands** - This interface organizes all the gateway command capabilities.

+- **Gateway theft alert**: This rule triggers when there's unexpected light detection by the sensors during the journey. Operators must be notified immediately to investigate potential theft.

+- **Lost gateway alert**: This rule triggers if the gateway doesn't report to the cloud for a prolonged period. The gateway could be unresponsive because of low battery, loss of connectivity, or device damage.

+Select the **Jobs** tab to create the jobs in this application. The following screenshot shows an example of created jobs:

+- It's a standard operation to disable shock sensors during ocean shipment to conserve battery or lower temperature threshold during cold chain transportation.

+- Jobs enable you to do system-wide operations such as updating firmware on the gateways or updating service contract to stay current on maintenance activities.

+As manufacturers and retailers establish worldwide presences, their supply chains branch out and become more complex. Consumers now expect a large selection of products, and for those goods to arrive within one or two days of purchase. Distribution centers must adapt to these trends while overcoming existing inefficiencies.

+Today, reliance on manual labor means that picking and packing accounts for 55-65% of distribution center costs. Manual picking and packing are also typically slower than automated systems, and rapidly fluctuating staffing needs make it even harder to meet shipping volumes. This seasonal fluctuation results in high staff turnover and increases the likelihood of costly errors.

+Video cameras are the primary sensors in this example application. Machine learning and artificial intelligence enable video to be turned into structured data and that you can process at the edge before sending it to the cloud. Use IP cameras to capture images, compress them on the camera, and then send the compressed data to edge compute resources for video analytics.

+Azure IoT Edge manages the "cameras-as-sensors" and edge workloads locally and a video analytics pipeline processes the data stream from the camera. The video analytics processing pipeline at Azure IoT Edge brings many benefits including decreased response times and low-bandwidth consumption. The IoT Edge device sends only the most essential metadata, insights, or actions to the cloud.

+IoT Central platform provides rich extensibility options through data export and APIs. Business insights based on telemetry data processing or raw telemetry are typically exported to a preferred line-of-business application. Export destinations include webhooks, Azure Service Bus, an event hub, or blob storage.

+In this dashboard, you see one gateway and one camera acting as an IoT device. The gateway provides telemetry about packages such as valid, invalid, unidentified, and size along with associated device twin properties. All downstream commands are executed at IoT devices. This dashboard is preconfigured to show the critical distribution center device operations activity.

+- Complete gateway command and control tasks.

+- Manage all the cameras in the solution.

+- **Camera** - Organizes all the camera-specific command capabilities.

+- **Digital Distribution Gateway** - Represents all the telemetry coming from camera, cloud defined device twin properties and gateway info.

+Select the rules tab to see two different rules that exist in this application template. These rules configure email notifications to the operators for further investigations:

+- **Too many invalid packages alert** - This rule triggers when the camera detects a high number of invalid packages flowing through the conveyor system.

+- **Large package** - This rule triggers if the camera detects huge package that can't be inspected for the quality.

+In this tutorial, you learn how to:

+> * Use the application

+The application template that you create focuses on device connectivity, and it helps you configure and manage the RFID and Bluetooth low energy (BLE) reader devices.

+ RFID tags transmit data about an item through radio waves. RFID tags ordinarily don't have a battery, unless specified. Tags receive energy from radio waves that the RFID reader generates and then transmit a signal back to the reader.

+ An energy beacon broadcasts packets of data at regular intervals. BLE readers or installed services on smartphones detect beacon data and then transmit it to the cloud.

+ Many readers can read RFID and beacon signals and provide other sensor capabilities.

+ Azure IoT Edge server provides a place to preprocess the data locally before sending it on to the cloud. You can also deploy cloud workloads artificial intelligence, Azure and third-party services, and business logic by using standard containers.

+ The IoT Central platform provides rich extensibility options through data export and APIs. Business insights that are based on telemetry data processing or raw telemetry are typically exported to a preferred line-of-business application.

+Create the application by completing the following steps:

+After you deploy the application, your default dashboard is a smart, operator-focused, inventory-management portal. Northwind Trader is a fictitious smart inventory provider that manages its warehouse with Bluetooth low energy (BLE) beacons and its retail store with RFID tags.

+* View the gateway location, status, and related details.

+ * Update device service contracts

+* **Gateway Telemetry and Property**: This interface displays the telemetry that's related to sensors, location, device info, and device twin properties such as gateway thresholds and update intervals.

+ Title: Move a key vault to a different region - Azure Key Vault

+# Move a key vault across regions

+To capture application performance regressions early, add your load test in your [continuous integration and continuous deployment (CI/CD) workflow](./quickstart-add-load-test-cicd.md). Leverage test fail criteria to define and validate your application quality requirements.

+Get started with [adding load testing to your CI/CD workflow](./quickstart-add-load-test-cicd.md) to quickly identify performance degradation of your application under load.

+- [Quickstart: Automate load tests with CI/CD](./quickstart-add-load-test-cicd.md).

+ Title: 'Quickstart: Add load test to CI/CD'

+description: 'This quickstart shows how to run your load tests with Azure Load Testing in CI/CD. Learn how to add a load test to GitHub Actions or Azure Pipelines.'

+# Quickstart: Automate a load test with CI/CD in GitHub Actions or Azure Pipelines

+Get started with automating load tests in Azure Load Testing by adding it to a CI/CD pipeline. After running a load test in the Azure portal, you export the configuration files, and configure a CI/CD pipeline in GitHub Actions or Azure Pipelines.

+After you complete this quickstart, you have a CI/CD workflow that is configured to run a load test with Azure Load Testing.

+## Prerequisites

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

+- An Azure Load Testing test. Create a [URL-based load test](./quickstart-create-and-run-load-test.md) or [use an existing JMeter script](./how-to-create-and-run-load-test-with-jmeter-script.md) to create a load test.

+# [Azure Pipelines](#tab/pipelines)

+- An Azure DevOps organization and project. If you don't have an Azure DevOps organization, you can [create one for free](/azure/devops/pipelines/get-started/pipelines-sign-up?view=azure-devops&preserve-view=true). If you need help with getting started with Azure Pipelines, see [Create your first pipeline](/azure/devops/pipelines/create-first-pipeline?preserve-view=true&view=azure-devops&tabs=java%2Ctfs-2018-2%2Cbrowser).

+# [GitHub Actions](#tab/github)

+- A GitHub account. If you don't have a GitHub account, you can [create one for free](https://github.com/).

+- A GitHub repository to store the load test input files and create a GitHub Actions workflow. To create one, see [Creating a new repository](https://docs.github.com/github/creating-cloning-and-archiving-repositories/creating-a-new-repository).

+## Configure service authentication

+To run a load test in your CI/CD workflow, you need to grant permission to the CI/CD workflow to access your load testing resource. Create a service principal for the CI/CD workflow and assign the Load Test Contributor Azure RBAC role.

+# [Azure Pipelines](#tab/pipelines)

+### Create a service connection in Azure Pipelines

+In Azure Pipelines, you create a *service connection* in your Azure DevOps project to access resources in your Azure subscription. When you create the service connection, Azure DevOps creates an Azure Active Directory service principal object.

+1. Sign in to your Azure DevOps organization (`https://dev.azure.com/<your-organization>`), and select your project.

+

+ Replace the `<your-organization>` text placeholder with your project identifier.

+1. Select **Project settings** > **Service connections** > **+ New service connection**.

+1. In the **New service connection** pane, select the **Azure Resource Manager**, and then select **Next**.

+1. Select the **Service Principal (automatic)** authentication method, and then select **Next**.

+1. Enter the service connection details, and then select **Save** to create the service connection.

+ | Field |