-# DevelopersΓÇÖ guide to Conditional Access authentication context

-[Conditional Access](../conditional-access/overview.md) is the Zero Trust control plane that allows you to target policies for access to all your apps ΓÇô old or new, private, or public, on-premises, or multi-cloud. With [Conditional Access authentication context](../conditional-access/concept-conditional-access-cloud-apps.md#authentication-context-preview), you can apply different policies within those apps.

-Use the Azure AD Conditional access engineΓÇÖs new auth context feature to trigger a demand for step-up authentication from within your application and services. Developers now have the power to demand enhanced stronger authentication, selectively, like MFA from their end users from within their applications. This feature helps developers build smoother user experiences for most parts of their application, while access to more secure operations and data remains behind stronger authentication controls.

-The IT administrators and regulators often struggle between balancing prompting their users with additional factors of authentication too frequently and achieving adequate security and policy adherence for applications and services where parts of them contain sensitive data and operations. It can be a choice between a strong policy that impacts users' productivity when they access most data and actions or a policy that is not strong enough for sensitive resources.

-So, what if apps were able to mix both, where they can function with a relatively lesser security and less frequent prompts for most users and operations and yet conditionally stepping up the security requirement when the users accessed more sensitive parts?

-For example, while users may sign in to SharePoint using multi-factor authentication, accessing site collection in SharePoint containing sensitive documents can require a compliant device and only be accessible from trusted IP ranges.

-## Steps

-The following are the prerequisites and the steps if you want to use Conditional Access authentication context.

-### Prerequisites

-### Integration steps

-> The Conditional Access auth context values are declared and maintained separately from applications. It is not advisable for applications to take hard dependency on auth context ids. The Conditional Access policies are usually crafted by IT administrators as they have a better understanding of the resources available to apply policies on. For example, for an Azure AD tenant, IT admins would have the knowledge of how many of the tenantΓÇÖs users are equipped to use 2FA for MFA and thus can ensure that Conditional Access policies that require 2FA are scoped to these equipped users.

-**Third**: Your application, and for this example, weΓÇÖd assume itΓÇÖs a web API, then needs to evaluate calls against the saved mapping and accordingly raise claim challenges for its client apps. To prepare for this action, the following steps are to be taken:

-1. In a sensitive and protected by auth context operation, evaluate the values in the **acrs** claim against the Auth Context ID mappings saved earlier and raise a [Claims Challenge](claims-challenge.md) as provided in the code snippet below.

- The code snippet that follows is from the code sample, [Use the Conditional Access auth context to perform step-up authentication](https://github.com/Azure-Samples/ms-identity-ca-auth-context/blob/main/README.md). The first method, `CheckForRequiredAuthContext()` in the API

- ```

- string authType = _commonDBContext.AuthContext.FirstOrDefault(x => x.Operation == method

- if (context == null || context.User == null || context.User.Claims == null

- Claim acrsClaim = context.User.FindAll(authenticationContextClassReferencesClaim).FirstOrDefault(x

- > The format of the claims challenge is described in the article, [Claims Challenge in the Microsoft Identity Platform](claims-challenge.md).

- ```

- ```

- // Call the API

-

-Do not hard-code Auth Context values in your app. Apps should read and apply auth context [using MS Graph calls](/graph/api/resources/authenticationcontextclassreference). This practice is critical for [multi-tenant applications](howto-convert-app-to-be-multi-tenant.md). The Auth Context values will vary between Azure AD tenants will not available in Azure AD free edition. For more information on how an app should query, set, and use auth context in their code, see the code sample, [Use the Conditional Access auth context to perform step-up authentication](https://github.com/Azure-Samples/ms-identity-ca-auth-context/blob/main/README.md) as how an app should query, set and use auth context in their code.

-On macOS 10.15+, MSAL's behavior is the same between iOS and macOS. MSAL uses [keychain access groups](https://developer.apple.com/documentation/security/keychain_services/keychain_items/sharing_access_to_keychain_items_among_a_collection_of_apps?language=objc) for keychain sharing.

-### Conditional access authentication differences

-2. On 10.15+, MSAL will prompt user for credentials for every token acquisition.

-description: Learn about changes made to the Azure AD protocols that may impact your application.

-> Get notified of updates to this page by pasting this URL into your RSS feed reader:<br/>`https://docs.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us`

-The authentication system alters and adds features on an ongoing basis to improve security and standards compliance. To stay up to date with the most recent developments, this article provides you with information about the following details:

-> This page is updated regularly, so visit often. Unless otherwise noted, these changes are only put in place for newly registered applications.

-## Upcoming changes

-### ADFS users will see additional login prompts to ensure that the correct user is signed in.

-Today, when a user is sent to ADFS to authenticate, they will be silently signed into any account that already has a session with ADFS. This silent sign-in occurs even if the user intended to sign into a different user account. To reduce the frequency of this incorrect sign in occurring, starting in December Azure AD will send the `prompt=login` parameter to ADFS if the Web Account Manager in Windows provides Azure AD a `login_hint` during sign-in, which indicates a specific user is desired for sign-in.

-When the above requirements are met (WAM is used to send the user to Azure AD to sign in, a `login_hint` is included, and the [ADFS instance for the user's domain supports `prompt=login`](/windows-server/identity/ad-fs/operations/ad-fs-prompt-login)) the user will not be silently signed in, and instead asked to provide a username to continue signing into ADFS. If they wish to sign into their existing ADFS session, they can select the "Continue as current user" option displayed below the login prompt. Otherwise, they can continue with the username that they intend to sign in with.

-This change will be rolled out in December 2021 over the course of several weeks. It does not change sign in behavior for:

-* Domains that are not federated to an ADFS instance

-Error 50105 (the current designation) is emitted when an unassigned user attempts to sign into an app that an admin has marked as requiring user assignment. This is a common access control pattern, and users must often find an admin to request assignment to unblock access. The error had a bug that would cause infinite loops in well-coded applications that correctly handled the `interaction_required` error response. `interaction_required` tells an app to perform interactive authentication, but even after doing so Azure AD would still return an `interaction_required` error response.

-The error scenario has been updated, so that during non-interactive authentication (where `prompt=none` is used to hide UX), the app will be instructed to perform interactive authentication using an `interaction_required` error response. In the subsequent interactive authentication, Azure AD will now hold the user and show an error message directly, preventing a loop from occurring.

-As a reminder, Azure AD does not support applications detecting individual error codes, such as checking strings for `AADSTS50105`. Instead, [Azure AD guidance](reference-aadsts-error-codes.md#handling-error-codes-in-your-application) is to follow the standards and use the [standardized authentication responses](https://openid.net/specs/openid-connect-core-1_0.html#AuthError) such as `interaction_required` and `login_required`. These are found in the standard `error` field in the response - the other fields are for human consumption during troubleshooting.

-You can review the current text of the 50105 error and more on the error lookup service: https://login.microsoftonline.com/error?code=50105 .

-For single tenant applications, adding or updating the AppId URI validates that the domain in the HTTPS scheme URI is listed in the verified domain list in the customer tenant or that the value uses the default scheme (`api://{appId}`) provided by Azure AD. This could prevent applications from adding an AppId URI if the domain isn't in the verified domain list or the value does not use the default scheme.

-The change does not affect existing applications using unverified domains in their AppID URI. It validates only new applications or when an existing application updates an identifier URIs or adds a new one to the identifierUri collection. The new restrictions apply only to URIs added to an app's identifierUris collection after 10/15/2021. AppId URIs already in an application's identifierUris collection when the restriction takes affect on 10/15/2021 will continue to function even if you add new URIs to that collection.

-**Effective date**: August 2021, with gradual rollout starting in April.

-Applications using dynamic consent today are given all of the permissions they have consent for, even if they were not requested in the `scope` parameter by name. This can cause an app requesting e.g. only `user.read`, but with consent to `files.read`, to be forced to pass the Conditional Access assigned for the `files.read` permission.

-In order to reduce the number of unnecessary Conditional Access prompts, Azure AD is changing the way that unrequested scopes are provided to applications so that only explicitly requested scopes trigger Conditional Access. This change may cause apps reliant on Azure AD's previous behavior (namely, providing all permissions even when they were not requested) to break, as the tokens they request will be missing permissions.

-Apps will now receive access tokens with a mix of permissions in this - those requested, as well as those they have consent for that do not require Conditional Access prompts. The scopes of the access token is reflected in the token response's `scope` parameter.

-This change will be made for all apps except those with an observed dependency on this behavior. Developers will receive outreach if they are exempted from this change, as them may have a dependency on the additional conditional access prompts.

-An app has consent for `user.read`, `files.readwrite`, and `tasks.read`. `files.readwrite` has Conditional Access policies applied to it, while the other two do not. If an app makes a token request for `scope=user.read`, and the currently signed in user has not passed any Conditional Access policies, then the resulting token will be for the `user.read` and `tasks.read` permissions. `tasks.read` is included because the app has consent for it, and it does not require a Conditional Access policy to be enforced.

-If the app then requests `scope=files.readwrite`, the Conditional Access required by the tenant will trigger, forcing the app to show an interactive auth prompt where the Conditional Access policy can be satisfied. The token returned will have all three scopes in it.

-If the app then makes one last request for any of the three scopes (say, `scope=tasks.read`), Azure AD will see that the user has already completed the Conditional access policies needed for `files.readwrite`, and again issue a token with all three permissions in it.

-As a security improvement, the device code flow has been updated to add an additional prompt, which validates that the user is signing into the app they expect. This is added to help prevent phishing attacks.

-A bug was found and fixed in the Azure AD authorization response. During the `/authorize` leg of authentication, the `state` parameter from the request is included in the response, in order to preserve app state and help prevent CSRF attacks. Azure AD incorrectly URL-encoded the `state` parameter before inserting it into the response, where it was encoded once more. This would result in applications incorrectly rejecting the response from Azure AD.

-Azure AD will no longer double-encode this parameter, allowing apps to correctly parse the result. This change will be made for all applications.

-**Effective date**: May 5th (Finishing June 2020)

-On 1 June 2018, the official Azure Active Directory (Azure AD) Authority for Azure Government changed from `https://login-us.microsoftonline.com` to `https://login.microsoftonline.us`. This change also applied to Microsoft 365 GCC High and DoD, which Azure Government Azure AD also services. If you own an application within a US Government tenant, you must update your application to sign users in on the `.us` endpoint.

-Starting May 5th, Azure AD will begin enforcing the endpoint change, blocking government users from signing into apps hosted in US Government tenants using the public endpoint (`microsoftonline.com`). Impacted apps will begin seeing an error `AADSTS900439` - `USGClientNotSupportedOnPublicEndpoint`. This error indicates that the app is attempting to sign in a US Government user on the public cloud endpoint. If your app is in a public cloud tenant and intended to support US Government users, you will need to [update your app to support them explicitly](./authentication-national-cloud.md). This may require creating a new app registration in the US Government cloud.

-Enforcement of this change will be done using a gradual rollout based on how frequently users from the US Government cloud sign in to the application - apps signing in US Government users infrequently will see enforcement first, and apps frequently used by US Government users will be last to have enforcement applied. We expect enforcement to be complete across all apps in June 2020.

-For more details, please see the [Azure Government blog post on this migration](https://devblogs.microsoft.com/azuregov/azure-government-aad-authority-endpoint-update/).

-Users with passwords longer than 256 characters that sign in directly to Azure AD (as opposed to a federated IDP like ADFS) will be unable to sign in starting March 13, 2020, and be asked to reset their password instead. Admins may receive requests to help reset the users password.

-The error in the sign in logs will be AADSTS 50052: InvalidPasswordExceedsMaxLength

-The user is unable to login because their password exceeds the permitted maximum length. They should contact their admin to reset the password. If SSPR is enabled for their tenant, they can reset their password by following the "Forgot your password" link.

-**Protocol impacted**: OAuth and OIDC flows that use response_type=query - this covers the [authorization code flow](v2-oauth2-auth-code-flow.md) in some cases, and the [implicit flow](v2-oauth2-implicit-grant-flow.md).

-When an authentication response is sent from login.microsoftonline.com to an application via HTTP redirect, the service will append an empty fragment to the reply URL. This prevents a class of redirect attacks by ensuring that the browser wipes out any existing fragment in the authentication request. No apps should have a dependency on this behavior.

-Starting the week of 9/2, authentication requests that use the POST method will be validated using stricter HTTP standards. Specifically, spaces and double-quotes (") will no longer be removed from request form values. These changes are not expected to break any existing clients, and will ensure that requests sent to Azure AD are reliably handled every time. In the future (see above) we plan to additionally reject duplicate parameters and ignore the BOM within requests.

-Today, `?e= "f"&g=h` is parsed identically as `?e=f&g=h` - so `e` == `f`. With this change, it would now be parsed so that `e` == ` "f"` - this is unlikely to be a valid argument, and the request would now fail.

-A security change went live July 26th that changes the way app-only tokens (via the client credentials grant) are issued. Previously, applications were allowed to get tokens to call any other app, regardless of presence in the tenant or roles consented to for that application. This behavior has been updated so that for resources (sometimes called web APIs) set to be single-tenant (the default), the client application must exist within the resource tenant. Note that existing consent between the client and the API is still not required, and apps should still be doing their own authorization checks to ensure that a `roles` claim is present and contains the expected value for the API.

-To remedy this issue, use the Admin Consent experience to create the client application service principal in your tenant, or create it manually. This requirement ensures that the tenant has given the application permission to operate within the tenant.

-In this example, the resource tenant (authority) is contoso.com, the resource app is a single-tenant app called `gateway.contoso.com/api` for the Contoso tenant, and the client app is `14c88eee-b3e2-4bb0-9233-f5e3053b3a28`. If the client app has a service principal within Contoso.com, this request can continue. If it doesn't, however, then the request will fail with the error above.

-Per [RFC 6749](https://tools.ietf.org/html/rfc6749#section-3.1.2), Azure AD applications can now register and use redirect (reply) URIs with static query parameters (such as `https://contoso.com/oauth2?idp=microsoft`) for OAuth 2.0 requests. Dynamic redirect URIs are still forbidden as they represent a security risk, and this cannot be used to retain state information across an authentication request - for that, use the `state` parameter.

-The static query parameter is subject to string matching for redirect URIs like any other part of the redirect URI - if no string is registered that matches the URI-decoded redirect_uri, then the request will be rejected. If the URI is found in the app registration, then the entire string will be used to redirect the user, including the static query parameter.

-Note that at this time (End of July 2019), the app registration UX in Azure portal still block query parameters. However, you can edit the application manifest manually to add query parameters and test this in your app.

-Client applications can sometimes misbehave, issuing hundreds of the same login request over a short period of time. These requests may or may not be successful, but they all contribute to poor user experience and heightened workloads for the IDP, increasing latency for all users and reducing availability of the IDP. These applications are operating outside the bounds of normal usage, and should be updated to behave correctly.

-Most clients will not need to change behavior to avoid this error. Only misconfigured clients (those without token caching or those exhibiting prompt loops already) will be impacted by this error. Clients are tracked on a per-instance basis locally (via cookie) on the following factors:

-Apps making multiple requests (15+) in a short period of time (5 minutes) will receive an `invalid_grant` error explaining that they are looping. The tokens being requested have sufficiently long-lived lifetimes (10 minutes minimum, 60 minutes by default), so repeated requests over this time period are unnecessary.

-All apps should handle `invalid_grant` by showing an interactive prompt, rather than silently requesting a token. In order to avoid this error, clients should ensure they are correctly caching the tokens they receive.

-For more information about refresh tokens, see [Refreshing the access tokens](v2-oauth2-auth-code-flow.md#refresh-the-access-token). If using ADAL or MSAL, this is handled for you by the library - replace the second instance of 'AcquireTokenByAuthorizationCodeAsync' with 'AcquireTokenSilentAsync'.

-### ID tokens cannot be used for the OBO flow

-After May 1, 2018, id_tokens cannot be used as the assertion in an OBO flow for new applications. Access tokens should be used instead to secure APIs, even between a client and middle tier of the same application. Apps registered before May 1, 2018 will continue to work and be able to exchange id_tokens for an access token; however, this pattern is not considered a best practice.

-> | Language/<br/>Platform | Code sample(s) <br/>on GitHub | Auth<br/> libraries | Auth flow |

-> | - | -- | - | -- |

-> | JavaScript | &#8226; [Sign in users](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/1-Authentication/1-sign-in/README.md)<br/>&#8226; [Sign in users (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/1-Authentication/2-sign-in-b2c/README.md) <br/> &#8226; [Call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/2-Authorization-I/1-call-graph/README.md)<br/>&#8226; [Call Node.js web API](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/3-Authorization-II/1-call-api/README.md)<br/>&#8226; [Call Node.js web API (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/3-Authorization-II/2-call-api-b2c/README.md)<br/>&#8226; [Call Microsoft Graph via OBO](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/4-AdvancedGrants/1-call-api-graph/README.md)<br/>&#8226; [Call Node.js web API via OBO and CA](https://github.com/Azure-Samples/ms-identity-javascript-tutorial/tree/main/4-AdvancedGrants/2-call-api-api-c)| MSAL.js | &#8226; Authorization code with PKCE<br/>&#8226; On-behalf-of (OBO) <br/>&#8226; Conditional Access (CA) |

-> | React | &#8226; [Sign in users](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/1-Authentication/1-sign-in/README.md)<br/>&#8226; [Sign in users (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/1-Authentication/2-sign-in-b2c/README.md) <br/> &#8226; [Call Microsoft Graph](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/2-Authorization-I/1-call-graph/README.md)<br/>&#8226; [Call Node.js web API](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/3-Authorization-II/1-call-api)<br/>&#8226; [Call Node.js web API (B2C)](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/3-Authorization-II/2-call-api-b2c)<br/>&#8226; [Call Microsoft Graph via OBO](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/6-AdvancedScenarios/1-call-api-obo/README.md)<br/>&#8226; [Call Node.js web API using PoP](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/6-AdvancedScenarios/2-call-api-pop/README.md)<br/>&#8226; [Use App Roles for access control](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/5-AccessControl/1-call-api-roles/README.md)<br/>&#8226; [Use Security Groups for access control](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/5-AccessControl/2-call-api-groups/README.md)<br/>&#8226; [Deploy to Azure Storage and App Service](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/4-Deployment/1-deploy-storage/README.md)<br/>&#8226; [Deploy to Azure Static Web Apps](https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/4-Deployment/2-deploy-static/README.md)| MSAL React | &#8226; Authorization code with PKCE<br/>&#8226; On-behalf-of (OBO) <br/>&#8226; Conditional Access (CA)<br/>&#8226; Proof of Possession (PoP) |

-> | Language/<br/>Platform | Code sample(s) <br/> on GitHub | Auth<br/> libraries | Auth flow |

-> | Language/<br/>Platform | Code sample(s) <br/>on GitHub | Auth<br/> libraries | Auth flow |

-> | - | -- | - | -- |

- scopes: [process.env.GRAPH_ENDPOINT + '.default'], // e.g. 'https://graph.microsoft.com/.default'

-If you call your own web API and couldn't add an app permission to the app registration for your daemon app, did you expose an app role in your web API?

-For details, see [Exposing application permissions (app roles)](scenario-protected-web-api-app-registration.md#exposing-application-permissions-app-roles) and, in particular, [Ensuring that Azure AD issues tokens for your web API to only allowed clients](scenario-protected-web-api-app-registration.md#ensuring-that-azure-ad-issues-tokens-for-your-web-api-to-only-allowed-clients).

-The web API that you want to call needs to define _Application permissions (app roles)_, not delegated permissions. For details on how to expose such an API, see [Protected web API: App registration - when your web API is called by a daemon app](scenario-protected-web-api-app-registration.md#if-your-web-api-is-called-by-a-daemon-app).

-MSAL provides the following values:

-

-

-

-If you've accepted the App ID URI proposed by the app registration portal, you don't need to specify the audience (see [Application ID URI and scopes](scenario-protected-web-api-app-registration.md#application-id-uri-and-scopes)). Otherwise, you should add an `Audience` property whose value is the App ID URI for your web API.

-#Customer intent: As an application developer, I want to know how to write a protected web API using the Microsoft identity platform for developers.

-### Application ID URI and scopes

-### Exposing delegated permissions (scopes)

-1. Select **Expose an API** in the application registration.

-1. Select **Add a scope**.

-1. If prompted, accept the proposed application ID URI (`api://{clientId}`) by selecting **Save and Continue**.

-1. Specify these values:

- - Select **Scope name** and enter **access_as_user**.

- - Select **Who can consent** and make sure **Admins and users** is selected.

- - Select **Admin consent display name** and enter **Access TodoListService as a user**.

- - Select **Admin consent description** and enter **Accesses the TodoListService web API as a user**.

- - Select **User consent display name** and enter **Access TodoListService as a user**.

- - Select **User consent description** and enter **Accesses the TodoListService web API as a user**.

- - Keep the **State** value set to **Enabled**.

-1. Select **Add scope**.

-### If your web API is called by a daemon app

-In this section, you learn how to register your protected web API so that daemon apps can securely call it.

-#### Exposing application permissions (app roles)

-To expose application permissions, edit the manifest.

-1. In the application registration for your application, select **Manifest**.

-1. To edit the manifest, find the `appRoles` setting and add application roles. The role definitions are provided in the following sample JSON block.

-1. Leave `allowedMemberTypes` set to `"Application"` only.

-1. Make sure `id` is a unique GUID.

-1. Make sure `displayName` and `value` don't contain spaces.

-1. Save the manifest.

-The following sample shows the contents of `appRoles`, where the value of `id` can be any unique GUID.

-```json

-"appRoles": [

- {

- "allowedMemberTypes": [ "Application" ],

- "description": "Accesses the TodoListService-Cert as an application.",

- "displayName": "access_as_application",

- "id": "ccf784a6-fd0c-45f2-9c08-2f9d162a0628",

- "isEnabled": true,

- "lang": null,

- "origin": "Application",

- "value": "access_as_application"

- }

-],

-```

-#### Ensuring that Azure AD issues tokens for your web API to only allowed clients

-The web API checks for the app role. This role is a software developer's way to expose application permissions. You can also configure Azure AD to issue API tokens only to apps that the tenant admin approves for API access.

-To add this increased security:

-1. Go to the app **Overview** page for your app registration.

-1. Under **Managed application in local directory**, select the link with the name of your app. The label for this selection might be truncated. For example, you might see **Managed application in ...**

- When you select this link, you go to the **Enterprise Application Overview** page. This page is associated with the service principal for your application in the tenant where you created it. You can go to the app registration page by using the back button of your browser.

-1. Select the **Properties** page in the **Manage** section of the Enterprise application pages.

-1. If you want Azure AD to allow access to your web API from only certain clients, set **User assignment required?** to **Yes**.

-

- If you set **User assignment required?** to **Yes**, Azure AD checks the app role assignments of a client when it requests a web API access token. If the client isn't assigned to any app roles, Azure AD will return the error message "invalid_client: AADSTS501051: Application \<application name\> isn't assigned to a role for the \<web API\>".

-

- If you keep **User assignment required?** set to **No**, Azure AD wonΓÇÖt check the app role assignments when a client requests an access token for your web API. Any daemon client, meaning any client using the client credentials flow, can get an access token for the API just by specifying its audience. Any application can access the API without having to request permissions for it.

-

- But as explained in the previous section, your web API can always verify that the application has the right role, which is authorized by the tenant admin. The API performs this verification by validating that the access token has a role claim and that the value for this claim is correct. In the previous JSON sample, the value is `access_as_application`.

-1. Select **Save**.

-Move on to the next article in this scenario,

-[App code configuration](scenario-protected-web-api-app-configuration.md).

-If your web API is called by a [daemon app](scenario-daemon-overview.md), that app should require an application permission to your web API. As shown in [Exposing application permissions (app roles)](./scenario-protected-web-api-app-registration.md#exposing-application-permissions-app-roles), your API exposes such permissions. One example is the `access_as_application` app role.

-If you have defined app roles with user/group, then roles claim can also be verified in the API along with scopes. The verification logic of the app roles in this scenario remains same as if API is called by the daemon apps since there is no differentiation in the role claim for user/group and application.

-Add the permissions to your app. Do not add any sensitive or high-privilege permissions to the app, we recommend you scope your testing scenarios to basic integration scenarios around integrating with Azure AD.

-1. Navigate to the [Azure portal](https://portal.azure.com) and sign in to your tenant. Select **Azure Active Directory**. Select **Security** in the left navigation pane and then select **Conditional access**.

- "AadAuthorityAudience": "AzureAdMultipleOrgs",

- "https://graph.microsoft.com/User.Read",

- "https://graph.microsoft.com/User.ReadBasic.All"

- string keyVaultUri = Configuration.GetValue<string>("KeyVault:KeyVaultUri");

- KeyVaultSecret userNameSecret = client.GetSecret("TestUserName");

-description: Learn how to set up an Azure Active Directory test environment so you can test your application integrated with Microsoft identity platform. Evaluate whether you need a separate tenant for testing or if you can use your production tenant.

-#Customer intent: As a developer, I want to set up a test environment so that I can test my app integrated with Microsoft identity platform.

-As a developer, you use the software development lifecycle and move your app between development, test, and production environments. When this process is used for applications protected by the Microsoft identity platform, you should set up an Azure Active Directory (Azure AD) environment to be used for testing. This environment can be used in the early testing stages of the development lifecycle as well as a long-term, permanent test environment. Depending on your resource isolation requirements, you can use your organization's Azure AD production tenant or an entirely separate tenant for testing.

-In this article, you learn how to set up an Azure AD test environment so you can test your application integrated with Microsoft identity platform. Evaluate the level of isolation needed and whether you need a separate tenant for testing or if you can use your production tenant.

-## Decide the level of isolation needed

-In general, it is easier and less overhead to use your production tenant as a test environment. However, this is only a viable option if you can achieve the right level of isolation between test and production resources. Isolation is especially important for high privilege scenarios.

-Set up your test environment in a separate tenant (not your organization's production tenant) if:

-resource in a separate tenant with separate global administrators.

-If none of these conditions apply to you, then follow these steps to [set up your test environment in your production tenant](#set-up-a-test-environment-in-your-production-tenant). If any of them do apply, however, you should [set up a test environment in a separate tenant](#set-up-a-test-environment-in-a-separate-tenant).

-If you can't safely constrain your test app in your production tenant, you can create a separate tenant for development and testing purposes.

-If you don't already have a dedicated test tenant, you can create one for free using the Microsoft 365 Developer Program or manually create one yourself.

-#### Join the Microsoft 365 Developer Program (recommended)

-5. Enter the security information, which is needed to protect the administrator account of your new tenant. This will set up multifactor authentication for the account

-#### Manually create a tenant

-### Populate your tenant with users

-For convenience, you may want to invite yourself and other members of your development team to be guest users in the tenant. This will create separate guest objects in the test tenant, but means you only have to manage one set of credentials for your corporate account and your test account.

-You can also create test users in your test tenant. If you used one of the Microsoft 365 sample packs, you may already have some test users in your tenant. If not, you should be able to create some yourself as the tenant administrator.

-If you signed up using the Microsoft 365 Developer program, your test tenant will come with Azure AD P2 licenses. If not, you can still enable a one month [free trial of Azure AD premium](https://azure.microsoft.com/trial/get-started-active-directory/).

-You'll need to create an app registration to use in your test environment. This should be a separate registration from your eventual production app registration, to maintain security isolation between your test environment and your production environment. How you configure your application depends on the type of app you are building. For more information, check out the app registration steps for your app scenario in the left navigation pane, like this article for [web application registration](scenario-web-app-sign-user-app-registration.md).

-

-If your app will primarily be used by a single organization (commonly referred to as single tenant), and you have access to that production tenant, then you should try to replicate the settings of your production tenant that can affect your app's behavior. That will lower the chances of unexpected errors when operating in production.

-#### Conditional access policies

-Viewing your production tenant conditional access policies may need to be performed by a company administrator.

-1. Sign into the [Azure portal](https://portal.azure.com) using your production tenant account

-1. Go to **Azure Active Directory** > **Enterprise applications** > **Conditional access**.

-1. View the list of policies in your tenant. Click the first one.

-1. Navigate to **Cloud apps or actions**.

-1. If the policy only applies to a select group of apps, then move on to the next policy. If not, then it will likely apply to your app as well when you move to production. You should copy the policy over to your test tenant.

-1. Go to **Azure Active Directory** > **Enterprise applications** > **Conditional access**.

-Replicating permission grant policies ensures you don't encounter unexpected prompts for admin consent when moving to production.

-1. Sign into the [Azure portal](https://portal.azure.com) using your production tenant account

-1. Go to **Enterprise applications**.

-1. From your production tenant, go to **Azure Active Directory** > **Enterprise applications** > **Consent and permissions** > **User consent** settings. Copy the settings there to your test tenant.

-

-Replicating token lifetime policies ensures tokens issued to your application don't expire unexpectedly in production.

-

-Token lifetime policies can currently only be managed through PowerShell. Read about [configurable token lifetimes](active-directory-configurable-token-lifetimes.md) to learn about identifying any token lifetime policies that apply to your whole production organization. Copy those policies to your test tenant.

-

-You'll need to create an app registration to use in your test environment. This should be a separate registration from your eventual production app registration, to maintain security isolation between your test environment and your production environment. How you configure your application depends on the type of app you are building. For more information, check out the [app registration steps for your app scenario](scenario-web-app-sign-user-app-registration.md) in the left navigation pane.

-You'll need to create some test users with associated test data to use while testing your scenarios. This step might need to be performed by an admin

-For convenience, you can assign all these users to a group, which makes other assignment operations easier.

-You can restrict the users in your tenant that are allowed to use your test application to specific users or groups, through user assignment. When you [created an app through App registrations](#create-and-configure-an-app-registration), a representation of your app was created in **Enterprise applications** as well. Use the **Enterprise applications** settings to restrict who can use the application in your tenant.

-> If your app is a [multi-tenant app](v2-supported-account-types.md), this operation won't restrict users in other tenants from signing into and using your app. It will only restrict users in the tenant that user assignment is configured in.

-

-

-* Learn more about [Conditional access and securing access to IoT apps](/azure/architecture/example-scenario/iot-aad/iot-aad).

-You can no longer assume a secure network perimeter around the applications you build. Nearly every app you build will, by design, be accessed from outside the network perimeter. You also canΓÇÖt guarantee every app you build is secure or will remain so after itΓÇÖs deployed.

-Knowing this as the app developer, it's your responsibility to not only maximize your appΓÇÖs security, but also minimize the damage your app can cause if itΓÇÖs compromised.

-|Use the [Microsoft Authentication Libraries](./reference-v2-libraries.md) (MSAL).|MSAL is a set of MicrosoftΓÇÖs authentication libraries for developers. With MSAL, you can authenticate users and applications, and acquire tokens to access corporate resources using just a few lines of code. MSAL uses modern protocols ([OpenID Connect and OAuth 2.0](./active-directory-v2-protocols.md)) that remove the need for apps to ever handle a user's credentials directly. This vastly improves the security for both users and applications as the identity provider becomes the security perimeter. Also, these protocols continuously evolve to address new paradigms, opportunities, and challenges in identity security.|

-|Adopt enhanced security extensions like [Continuous Access Evaluation](../conditional-access/concept-continuous-access-evaluation.md) (CAE) and Conditional Access authentication context when appropriate.|In Azure AD, some of the most used extensions include [Conditional Access](../conditional-access/overview.md) (CA), [Conditional Access authentication context](./developer-guide-conditional-access-authentication-context.md) and CAE. Applications that use enhanced security features like CAE and Conditional Access authentication context must be coded to handle claims challenges. Open protocols enable you to use the [claims challenges and claims requests](./claims-challenge.md) to invoke extra client capabilities. This might be to indicate to apps that they need to re-interact with Azure AD, like if there was an anomaly or if the user no longer satisfies the conditions under which they authenticated earlier. As a developer you can code for these extensions without disturbing their primary code flows for authentication.|

-# Example: Configure SAML/WS-Fed based identity provider federation with AD FS (preview)

->- SAML/WS-Fed IdP federation is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-# Federation with SAML/WS-Fed identity providers for guest users (preview)

->- SAML/WS-Fed IdP federation is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-1. To retrieve the needed **Secret Token** contact Miro support team at support@miro.com. This value will be entered in the Secret Token field in the Provisioning tab of your Miro application in the Azure portal.

-2. Go to **Enterprise applications**, and then select **All applications**.

-3. To add a new application, select the **New application** button at the top of the pane.

-4. In the search box, enter **Miro**, select **Miro** in the results panel, and then click the **Add** button to add the application.

-> You may also choose to enable SAML-based single sign-on for Miro, following the instructions provided in the [Miro Single sign-on tutorial](./miro-tutorial.md). Single sign-on can be configured independently of automatic user provisioning, though these two features compliment each other.

-2. In the applications list, select **Miro**.

-3. Select the **Provisioning** tab.

-4. Set the **Provisioning Mode** to **Automatic**.

-5. Under the **Admin Credentials** section, input `https://miro.com/api/v1/scim` in **Tenant URL**. Input the **SCIM Authentication Token** value retrieved earlier in **Secret Token**. Click **Test Connection** to ensure Azure AD can connect to Miro. If the connection fails, ensure your Miro account has Admin permissions and try again.

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

-7. Click **Save**.

-8. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Miro**.

-9. Review the user attributes that are synchronized from Azure AD to Miro in the **Attribute Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Miro for update operations. Select the **Save** button to commit any changes.

-10. Under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Miro**.

-11. Review the group attributes that are synchronized from Azure AD to Miro in the **Attribute Mapping** section. The attributes selected as **Matching** properties are used to match the groups in Miro for update operations. Select the **Save** button to commit any changes. Uncheck **Create** and **Delete** under **Target Object Actions** as Miro SCIM API does not support creating and deleting groups.

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

-13. To enable the Azure AD provisioning service for Miro, change the **Provisioning Status** to **On** in the **Settings** section.

-14. Define the users and/or groups that you would like to provision to Miro by choosing the desired values in **Scope** in the **Settings** section.

-15. When you are ready to provision, click **Save**.

-* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

-| timeout="integer" | The amount of time in seconds to wait for the HTTP response headers to be returned by the backend service before a timeout error is raised. Minimum value is 0 seconds. Values greater than 240 seconds may not be honored as the underlying network infrastructure can drop idle connections after this time. | No | None |

-This setting enables downloads of the required updates in the background, and notifies you that the updates are ready to install. In this way, Update Management remains in control of schedules, but allows downloading of updates outside the Update Management maintenance window. This behavior prevents `Maintenance window exceeded` errors in Update Management.

-Update Management supports WSUS settings. You can specify sources for scanning and downloading updates using instructions in [Specify intranet Microsoft Update service location](/windows/deployment/update/waas-wu-settings#specify-intranet-microsoft-update-service-location). By default, the Windows Update client is configured to download updates from Windows Update. When you specify a WSUS server as a source for your machines, if the updates aren't approved in WSUS, update deployment fails.

-## Sign in to the Azure portal

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

-## View update assessment

-To view update assessment from an Azure VM, navigate to **Virtual Machines** and select your virtual machine from the list. From the left menu, select **Guest + host updates**, and then select **Go to Update Management** on the **Guest + host updates** page.

-In Update Management, you can view information about your machine, missing updates, update deployments, and scheduled update deployments.

-[ ](./media/view-update-assessments/update-assessment-azure-vm-expanded.png#lightbox)

-To view update assessment from an Azure Arc-enabled server, navigate to **Servers - Azure Arc** and select your server from the list. From the left menu, select **Guest and host updates**. On the **Guest + host updates** page, select **Go to Update Management**.

-In Update Management, you can view information about your Azure Arc-enabled machine, missing updates, update deployments, and scheduled update deployments.

-[ ](./media/view-update-assessments/update-assessment-arc-server-expanded.png#lightbox)

-To view update assessment across all machines, including Azure Arc-enabled servers from your Automation account, navigate to **Automation accounts** and select your Automation account with Update Management enabled from the list. In your Automation account, select **Update management** from the left menu.

-The updates for your environment are listed on the **Update management** page. If any updates are identified as missing, a list of them is shown on the **Missing updates** tab.

-[ ](./media/overview/update-management-view-expanded.png#lightbox)

-Under the **COMPLIANCE** column, you can see the last time the machine was assessed. Under the **UPDATE AGENT READINESS** column, you can see the health of the update agent. If there's an issue, select the link to go to troubleshooting documentation that can help you correct the problem.

-Under **Information link**, select the link for an update to open the support article that gives you important information about the update.

-[ ](./media/view-update-assessments/missing-updates-expanded.png#lightbox)

-> Information that is displayed about the Windows Defender definition update status is based on the last data that was summarized from the Log Analytics workspace and might not be current. Review [Windows Defender update always show as missing](../troubleshoot/update-management.md#windows-defender-update-missing-status) to learn more about this behavior.

-[ ](./media/view-update-assessments/logsearch-results-expanded.png#lightbox)

-

-| Azure Advanced Threat Protection |  |

-An action group is a collection of notification preferences defined by the owner of an Azure subscription. Azure Monitor, Service Health and Azure Advisor alerts use action groups to notify users that an alert has been triggered. Various alerts may use the same action group or different action groups depending on the user's requirements.

-Action Group is **Global** service, therefore there's no dependency on a specific Azure region. Requests from client can be processed by action group service in any region, which means, if one region of service is down, the traffic will be routed and process by other regions automatically. Being a *global service* it helps client not to worry about **disaster recovery**.

-

-

-

-

-

-

-

-

-

-

-

-1. If you close the window or select **Back to test setup** while the test is running, the test is stopped, and you won't get test results.

-1. When the test is complete either a **Success** or **Failed** test status is displayed. If the test failed, you could select *View details* to get more information.

-All the details and links in Test email notifications for the alerts fired are a sample set for reference.

-> See [Subscription Service Limits for Monitoring](../../azure-resource-manager/management/azure-subscription-service-limits.md#azure-monitor-limits) for numeric limits on each of the items below.

-You may have a limited number of Runbook actions in an Action Group.

-1. The type of the entity being assigned to the role needs to be **ΓÇ£UserΓÇ¥**.

-3. The user needs to have an email configured in their **AAD profile**.

-You may have a limited number of ITSM actions in an Action Group.

- - Configure your protected API to be [called by a daemon app](../../active-directory/develop/scenario-protected-web-api-app-registration.md#if-your-web-api-is-called-by-a-daemon-app).

-

-

-

-

-

-

-# This is your Azure AD Application's ObjectId.

-

-

-

-

-

-

-

-

-

-See the [rate limiting information](./alerts-rate-limiting.md) and [SMS alert behavior](./alerts-sms-behavior.md) for additional important information.

-> If the Azure portal Action Group user interface does not let you select your country/region code, then SMS is not supported for your country/region. If your country/region code is not available, you can vote to have your country/region added at [user voice](https://feedback.azure.com/d365community/idea/e527eaa6-2025-ec11-b6e6-000d3a4f09d0). In the meantime, a work around is to have your Action Group call a webhook to a third-party SMS provider with support in your country/region.

-| 1 |Canada |

-> If the Azure portal Action Group user interface does not let you select your country/region code, then voice calls are not supported for your country/region. If your country/region code is not available, you can vote to have your country/region added at [user voice](https://feedback.azure.com/d365community/idea/e527eaa6-2025-ec11-b6e6-000d3a4f09d0). In the meantime, a work around is to have your Action Group call a webhook to a third-party voice call provider with support in your country/region.

-> Only Country code supported today in Azure portal Action Group for Voice Notification is +1(United States).

-* Learn more about [SMS alert behavior](./alerts-sms-behavior.md).

-* Gain an [understanding of the activity log alert webhook schema](./activity-log-alerts-webhook.md).

-* Get an [overview of activity log alerts](./alerts-overview.md), and learn how to receive alerts.

-> You can switch plans once a week.

-Workspaces in the **Free Trial** pricing tier will have daily data ingestion limited to 500 MB (except for security data types collected by [Microsoft Defender for Cloud](../../security-center/index.yml)), and the data retention is limited to seven days. The Free Trial pricing tier is intended only for evaluation purposes. No SLA is provided for the Free tier. Workspaces in the Standalone or Per Node pricing tiers have user-configurable retention from 30 to 730 days. Creating new workspaces in (or moving existing workspaces into) the Free Trial pricing tier is possible until July 1, 2022.

-Usage on the **Standalone** pricing tier is billed by the ingested data volume. It is reported in the **Log Analytics** service and the meter is named "Data Analyzed".

-The **Per Node** pricing tier charges per monitored VM (node) on an hour granularity. For each monitored node, the workspace is allocated 500 MB of data per day that's not billed. This allocation is calculated with hourly granularity and is aggregated at the workspace level each day. Data ingested above the aggregate daily data allocation is billed per GB as data overage. On your bill, the service will be **Insight and Analytics** for Log Analytics usage if the workspace is in the Per Node pricing tier. Usage is reported on three meters:

-Workspaces created before April 2016 can continue to use the **Standard** and **Premium** pricing tiers that have fixed data retention of 30 days and 365 days, respectively. New workspaces can't be created in the **Standard** or **Premium** pricing tiers, and if a workspace is moved out of these tiers, it can't be moved back. Data ingestion meters on your Azure bill for these legacy tiers are called "Data analyzed."

-> Basic Logs are currently in public preview. You can currently work with Basic Logs tables in the Azure Portal and using a limited number of other components.

-Azure Container Apps manages the details of Kubernetes and container orchestrations for you. Containers in Azure Container Apps can use any runtime, programming language, or development stack of your choice.

-Additional features include:

-The following example configuration shows the options available when setting up a container.

-{

- ...

- "template": {

- "containers": [

- "image": "myacr.azurecr.io/myrepo/api-service:v1",

- "name": "my-container-image",

- "command": ["/bin/queue"],

- "args": [],

- "env": [

- {

- "name": "HTTP_PORT",

- "value": "8080"

- }

- ],

- "resources": {

- "cpu": 0.75,

- "memory": "1.5Gi"

- }

- }]

-}

-The total amount of CPUs and memory requested for all the containers in a container app must add up to one of the following combinations.

-You can define multiple containers in a single container app. Groups of containers are known as [pods](https://kubernetes.io/docs/concepts/workloads/pods). The containers in a pod share hard disk and network resources and experience the same [application lifecycle](application-lifecycle-management.md).

-You run multiple containers together by defining more than one container in the configuration's `containers` array.

-Reasons to run containers together in a pod include:

-You can deploy images hosted on private registries where credentials are provided through the Container Apps configuration.

-To use a container registry, you first define the required fields to the [configuration's](azure-resource-manager-api-spec.md) `registries` section.

- "passwordSecretRef": "my-password-secretref-name"

-With this set up, the saved credentials can be used when you reference a container image in an `image` in the `containers` array.

-The following example shows how to deploy an app from the Azure Container Registry.

-A Container Apps [environment](environment.md) provides a security boundary around a group of container apps. A single container app typically represents a microservice, which is composed of pods made up of one or more [containers](containers.md).

-description: Learn how revisions are created in Azure Container Apps

-A revision is an immutable snapshot of a container app.

-Revisions are most useful when you enable [ingress](ingress.md) to make your container app accessible via HTTP. Revisions are often used when you want to direct traffic from one snapshot of your container app to the next. Typical traffic direction strategies include [A/B testing](https://wikipedia.org/wiki/A/B_testing) and [BlueGreen deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html).

-The scenario shown above presumes the container app is in following state:

-Changes made to a container app fall under one of two categories: *revision-scope* and *application-scope* changes. Revision-scope changes are any change that triggers a new revision, while application-scope changes don't create revisions.

-The following types of changes create a new revision:

-The following types of changes do not create a new revision:

-While changes to secrets are an application-scope change, revisions must be [restarted](revisions.md) before a container recognizes new secret values.

-New revisions remain active until you deactivate them, or you set your container app to automatically deactivate old revisions.

-Defender for Cloud is a tool for security posture management and threat protection. It strengthens the security posture of your cloud resources, and with its integrated Microsoft Defender plans, Defender for Cloud protects workloads running in Azure, hybrid, and other cloud platforms.

-Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyber attacks, and streamline security management. Because it's natively integrated, deployment of Defender for Cloud is easy, providing you with simple auto provisioning to secure your resources by default.

-> [!NOTE]

-> Defender for Containers' support for Arc-enabled Kubernetes clusters (AWS EKS and GCP GKE clusters) is a preview feature.

-1. Select the sensor's architecture.

-|Added 429 retry and logging in BundleHandler |We sometimes encounter 429 errors when processing a bundle. If the FHIR service receives a 429 at the BundleHandler layer, we abort processing of the bundle and skip the remaining resources. We've added an additional retry (in addition to the retry present in the data store layer) that will execute one time per resource that encounters a 429. For more about this feature enhancement, see [PR #2400](https://github.com/microsoft/fhir-server/pull/2400).|

-|Billing for $convert-data and $de-id |Azure API for FHIR's data conversion and de-identified export features are now Generally Available. Billing for $convert-data and $de-id operations in Azure API for FHIR has been enabled. Billing meters were turned on March 1, 2022. |

-|Resolved issue where posting a bundle with incorrect Media Type returned a 500 error. |Previously when posting a search with a key that contains certain characters, a 500 error is returned. This fixes this issue [#2264](https://github.com/microsoft/fhir-server/pull/2264), and it addresses [#2148](https://github.com/microsoft/fhir-server/issues/2148). |

- ```yml

- # DPS TPM provisioning configuration

- provisioning:

- source: "dps"

- global_endpoint: "https://global.azure-devices-provisioning.net"

- scope_id: "PASTE_YOUR_SCOPE_ID_HERE"

- attestation:

- method: "symmetric_key"

- registration_id: "PASTE_YOUR_REGISTRATION_ID_HERE"

- symmetric_key: "PASTE_YOUR_PRIMARY_KEY_OR_DERIVED_KEY_HERE"

- # always_reprovision_on_startup: true

- # dynamic_reprovisioning: false

- ```toml

- # DPS provisioning with symmetric key

- [provisioning]

- source = "dps"

- global_endpoint = "https://global.azure-devices-provisioning.net"

- id_scope = "PASTE_YOUR_SCOPE_ID_HERE"

-

- [provisioning.attestation]

- method = "symmetric_key"

- registration_id = "PASTE_YOUR_REGISTRATION_ID_HERE"

- symmetric_key = { value = "PASTE_YOUR_PRIMARY_KEY_OR_DERIVED_KEY_HERE" }

- ```

-1. Optionally, find the auto reprovisioning mode section of the file. Use the `auto_reprovisioning_mode` parameter to configure your device's reprovisioning behavior to either `Dynamic`, `AlwaysOnStartup`, or `OnErrorOnly`. For more information, see [IoT Hub device reprovisioning concepts](../iot-dps/concepts-device-reprovision.md).

- # always_reprovision_on_startup: true

- # dynamic_reprovisioning: false

-warn: edgelet_utils::logging -- caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:

- 1. If the paramter doesn't exist, add it as a new parameter with the following settings:

-This document provides a table of error codes for various Device Update components. It is meant to be used as a reference for users who want to parse their own error codes to diagnose and troubleshoot issues.

-You will most likely see the `ExtendedResultCode` as a signed integer in the PnP interface. To decode the `ExtendedResultCode`, convert the signed integer to

-Please refer to [Device Update Agent result codes and extended result codes](https://github.com/Azure/iot-hub-device-update/tree/main/docs/agent-reference/device-update-agent-extended-result-codes.md) or [implement a custom Content Handler](https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers) for details on parsing codes.

-The following table lists error codes pertaining to the content service component of the Device Update service. The content service component is responsible for handling importing of update content. Additional troubleshooting information is also available for [importing proxy updates](device-update-proxy-update-troubleshooting.md).

-| "UpdateAlreadyExists" | Update with the same identity already exists. | Make sure you are importing an update that hasnΓÇÖt already been imported into this instance of Device Update for IoT Hub. |

-| "UpdateLimitExceeded" | Error importing update due to exceeded limit. | You have reached a [limit](device-update-limits.md) on the number of different Providers, Names or Versions allowed in your instance of Device Update for IoT Hub. Delete some updates from your instance and try again. |

-| "UpdateProvider" | Cannot import a new update provider. | You have reached a [limit](device-update-limits.md) on the number of different __Providers__ allowed in your instance of Device Update for IoT Hub. Delete some updates from your instance and try again. |

-| "UpdateName" | Cannot import a new update name for the specified provider. | You have reached a [limit](device-update-limits.md) on the number of different __Names__ allowed under one Provider in your instance of Device Update for IoT Hub. Delete some updates from your instance and try again. |

-| "UpdateVersion" | Cannot import a new update version for the specified provider and name. | You have reached a [limit](device-update-limits.md) on the number of different __Versions__ allowed under one Provider and Name in your instance of Device Update for IoT Hub. Delete some updates with that Name from your instance and try again. |

-| "UpdateProviderCompatibility" | Cannot import additional update provider with the specified compatibility. | When defining device manufacturer and device model compatibility properties in an import manifest, keep in mind that Device Update for IoT Hub supports a single Provider and Name combination for a given manufacturer/model. This means if you try to use the same manufacturer/model compatibility properties with more than one Provider/Name combination, you will see these errors. To resolve this, make sure that all updates for a given device (as defined by manufacturer/model) use the same Provider and Name. While not required, you may want to consider making the Provider the same as the manufacturer and the Name the same as the model, just for simplicity. |

-| "UpdateNameCompatibility" | Cannot import additional update name with the specified compatibility. | When defining device manufacturer and device model compatibility properties in an import manifest, keep in mind that Device Update for IoT Hub supports a single Provider and Name combination for a given manufacturer/model. This means if you try to use the same manufacturer/model compatibility properties with more than one Provider/Name combination, you will see these errors. To resolve this, make sure that all updates for a given device (as defined by manufacturer/model) use the same Provider and Name. While not required, you may want to consider making the Provider the same as the manufacturer and the Name the same as the model, just for simplicity. |

-| "UpdateVersionCompatibility" | Cannot import additional update version with the specified compatibility. | When defining device manufacturer and device model compatibility properties in an import manifest, keep in mind that Device Update for IoT Hub supports a single Provider and Name combination for a given manufacturer/model. This means if you try to use the same manufacturer/model compatibility properties with more than one Provider/Name combination, you will see these errors. To resolve this, make sure that all updates for a given device (as defined by manufacturer/model) use the same Provider and Name. While not required, you may want to consider making the Provider the same as the manufacturer and the Name the same as the model, just for simplicity. |

-| "SourceFilePendingMalwareAnalysis" | A signature was detected in a file being imported that may indicate malware is present. | Content imported into Device Update for IoT Hub is scanned for malware by several different mechanisms. If a signature is identified that is not an exact match for known malware, but has characteristics of malware, the import will fail and a unique error message will be returned. The error message contains the description of the suspected malware signature, and a file hash for each file where the signature was detected. You can use the file hash to find the exact file being flagged, and use the description of the malware signature to check that file for malware. <br><br>Once you have removed the malware from any files being imported, you can start the import process again. If you are certain your files are free of malware and continue to see this error, use the [Contact Microsoft Support](troubleshoot-device-update.md#contact) process. |

-description: This article list Advanced Security Information Model (ASIM) parsers .

-For more about ASIM, in general, see:

- This video is an interview discussing covering the basics of the Azure Files billing model, including how to optimize Azure file shares to achieve the lowest costs possible and how to compare Azure Files to other file storage offerings on-premises and in the cloud.

-Although these are the units commonly used by most operating systems and tools, they are frequently mislabeled as the base-10 units, which you may be more familiar with: KB, MB, GB, and TB. Although the rationale may vary, the common reason why operating systems like Windows mislabel the storage units is because many operating systems began using these acronyms before they were standardized by the IEC, BIPM, and NIST.

-Azure Files uses a provisioned model for premium file shares. In a provisioned business model, you proactively specify to the Azure Files service what your storage requirements are, rather than being billed based on what you use. This is similar to buying hardware on-premises in that when you provision an Azure file share with a certain amount of storage, you pay for that storage regardless of whether you use it or not, just like you don't start paying the costs of physical media on-premises when you start to use space. Unlike purchasing physical media on-premises, provisioned file shares can be dynamically scaled up or down depending on your storage and IO performance characteristics.

-It is possible to decrease the size of your provisioned share below your used GiB. If you do this, you will not lose data, but you will still be billed for the size used and receive the performance (baseline IOPS, throughput, and burst IOPS) of the provisioned share, not the size used.

-If you put an infrequently accessed workload in the transaction optimized tier, you will pay almost nothing for the few times in a month that you make transactions against your share, but you will pay a high amount for the data storage costs. If you were to move this same share to the cool tier, you would still pay almost nothing for the transaction costs, simply because you are very infrequently making transactions for this workload, but the cool tier has a much cheaper data storage price. Selecting the appropriate tier for your use case allows you to considerably reduce your costs.

-| Other transactions | | <ul><li>`AbortCopyFile`</li><li>`Cancel`</li><li>`ChangeNotify`</li><li>`Close`</li><li>`Echo`</li><li>`Ioctl`</li><li>`Lock`</li><li>`Logoff`</li><li>`Negotiate`</li><li>`OplockBreak`</li><li>`SessionSetup`</li><li>`TreeConnect`</li><li>`TreeDisconnect`</li><li>`CloseHandles`</li><li>`AcquireFileLease`</li><li>`BreakFileLease`</li><li>`ChangeFileLease`</li><li>`ReleaseFileLease`</li></ul> |

-You can use the Azure CLI to copy an incremental snapshot. You will need the latest version of the Azure CLI. See the following articles to learn how to either [install](/cli/azure/install-azure-cli) or [update](/cli/azure/update-azure-cli) the Azure CLI.

-The following script will copy an incremental snapshot from one region to another:

-name=<targetSnapshotName>

-az snapshot create -g $resourceGroupName -n $targetSnapshotName --source $sourceSnapshotId --incremental --copy-start

- * Custom IP prefixes (BYOIP), to learn more, see [Custom IP address prefix (BYOIP)](/azure/virtual-network/ip-services/custom-ip-address-prefix)