fix busted anchor links

Author: mmacy

articles/active-directory/develop/scenario-daemon-acquire-token.md

@@ -1,5 +1,5 @@
 ---
-title: Acquire tokens to call a web API (daemon app) - The Microsoft identity platform | Azure
+title: Acquire tokens to call a web API (daemon app) - The Microsoft identity platform
 description: Learn how to build a daemon app that calls web APIs (acquiring tokens)
 services: active-directory
 author: jmprieur
@@ -8,13 +8,9 @@ manager: CelesteDG
 ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
-ms.workload: identity
-ms.date: 10/30/2019
+ms.date: 05/12/2022
 ms.author: jmprieur
-ms.custom: aaddev
-
 #Customer intent: As an application developer, I want to know how to write a daemon app that can call web APIs by using the Microsoft identity platform.
-
 ---
 
 # Daemon app that calls web APIs - acquire a token
@@ -42,7 +38,7 @@ final static String GRAPH_DEFAULT_SCOPE = "https://graph.microsoft.com/.default"
 
 ```JavaScript
 const tokenRequest = {
-	scopes: [process.env.GRAPH_ENDPOINT + '.default'], // e.g. 'https://graph.microsoft.com/.default'
+    scopes: [process.env.GRAPH_ENDPOINT + '.default'], // e.g. 'https://graph.microsoft.com/.default'
 };
 ```
 
@@ -252,9 +248,7 @@ Content: {
 
 ### Are you calling your own API?
 
-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).
+If your daemon app calls your own web API and you weren't able to add an app permission to the daemon's app registration, you need to [Add app roles to the web API's app registration](howto-add-app-roles-in-azure-ad-apps.md).
 
 ## Next steps
 

articles/active-directory/develop/scenario-daemon-app-registration.md

@@ -36,7 +36,7 @@ A daemon application can request only application permissions to APIs (not deleg
 
 ![App permissions and admin consent](media/scenario-daemon-app/app-permissions-and-admin-consent.png)
 
-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).
+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-service-or-daemon-app).
 
 Daemon applications require that a tenant admin pre-consent to the application calling the web API. Tenant admins provide this consent on the same **API permission** page by selecting **Grant admin consent to _our organization_**
 

articles/active-directory/develop/scenario-protected-web-api-app-configuration.md

@@ -1,6 +1,5 @@
 ---
-title: Configure protected web API apps | Azure
-titleSuffix: Microsoft identity platform
+title: Configure protected web API apps
 description: Learn how to build a protected web API and configure your application's code.
 services: active-directory
 author: jmprieur
@@ -9,10 +8,8 @@ manager: CelesteDG
 ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
-ms.workload: identity
-ms.date: 07/15/2020
+ms.date: 05/12/2022
 ms.author: jmprieur
-ms.custom: aaddev 
 #Customer intent: As an application developer, I want to know how to write a protected web API using the Microsoft identity platform for developers.
 ---
 
@@ -90,7 +87,7 @@ This section describes how to configure a bearer token.
 
 #### Case where you used a custom App ID URI for your web API
 
-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.
+If you've accepted the default App ID URI proposed by the Azure portal, you don't need to specify the audience (see [Application ID URI and scopes](scenario-protected-web-api-app-registration.md#scopes-and-the-application-id-uri)). Otherwise, add an `Audience` property whose value is the App ID URI for your web API.
 
 ```Json
 {

articles/active-directory/develop/scenario-protected-web-api-app-registration.md

@@ -75,7 +75,7 @@ To expose delegated permissions, or _scopes_, follow the steps in [Configure an
 
 If you're following along with the web API scenario described in this set of articles, use these settings:
 
-- **Application ID URI**: Accept the proposed application ID URI (_api://<clientId>_) (if prompted)
+- **Application ID URI**: Accept the proposed application ID URI (_api://\<clientId\>_) (if prompted)
 - **Scope name**: _access_as_user_
 - **Who can consent**: _Admins and users_
 - **Admin consent display name**: _Access TodoListService as a user_
@@ -104,10 +104,9 @@ To add another layer of security, an Azure AD tenant administrator can configure
 To increase security by restricting token issuance only to client apps that have been assigned app roles:
 
 1. In the Azure portal, select your app in **Azure Active Directory** > **App registrations**.
-1. On application's overview page, select **Managed application in local directory** (it might be ), select your application to go to its **Enterprise Application Overview** page.
-
+1. On the application's overview page, select its **Managed application in local directory** link to navigate to its **Enterprise Application Overview** page.
 1. Under **Manage**, select **Properties**.
-1. Set **User assignment required?** to **Yes**.
+1. Set **Assignment required?** to **Yes**.
 1. Select **Save**.
 
 Azure AD will now check for app role assignments of client applications that request access tokens for your web API. If a client app hasn't been assigned any app roles, Azure AD returns an error message to the client similar to _invalid_client: AADSTS501051: Application \<application name\> isn't assigned to a role for the \<web API\>_.

articles/active-directory/develop/scenario-protected-web-api-verification-scope-app-roles.md

@@ -1,6 +1,5 @@
 ---
-title: Verify scopes and app roles protected web API | Azure
-titleSuffix: Microsoft identity platform
+title: Verify scopes and app roles protected web API
 description: Verify that the API is only called by applications on behalf of users who have the right scopes and by daemon apps that have the right application roles.
 services: active-directory
 author: jmprieur
@@ -9,10 +8,8 @@ manager: CelesteDG
 ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
-ms.workload: identity
-ms.date: 10/19/2021
+ms.date: 05/12/2022
 ms.author: jmprieur
-ms.custom: aaddev
 #Customer intent: As an application developer, I want to learn how to write a protected web API using the Microsoft identity platform for developers.
 ---
 
@@ -256,7 +253,7 @@ For a full version of `ValidateScopes` for ASP.NET Core, [_ScopesRequiredHttpCon
 
 ## Verify app roles in APIs called by daemon apps
 
-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 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#expose-application-permissions-app-roles), your API exposes such permissions. One example is the `access_as_application` app role.
 
 You now need to have your API verify that the token it receives contains the `roles` claim and that this claim has the expected value. The verification code is similar to the code that verifies delegated permissions, except that your controller action tests for roles instead of scopes:
 
@@ -335,7 +332,7 @@ For a full version of `ValidateAppRole` for ASP.NET Core, see [_RolesRequiredHtt
 
 Users can also use roles claims in user assignment patterns, as shown in [How to add app roles in your application and receive them in the token](howto-add-app-roles-in-azure-ad-apps.md). If the roles are assignable to both, checking roles will let apps sign in as users and users sign in as apps. We recommend that you declare different roles for users and apps to prevent this confusion.
 
-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. 
+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.
 
 ### Accepting app-only tokens if the web API should be called only by daemon apps
 

articles/active-directory/develop/test-setup-environment.md

@@ -11,7 +11,7 @@ ms.subservice: develop
 ms.topic: how-to
 ms.date: 05/11/2022
 ms.author: arcrowe
-ms.reviewer: marsma
+ms.reviewer: marsma, ryanwi
 # 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.
 ---
 
@@ -21,9 +21,9 @@ To help move your app through the development, test, and production lifecycle, s
 
 ## Dedicated test tenant or production Azure AD tenant?
 
-Your first task is to decide between using Azure AD tenant dedicated to testing or using your production tenant as your test environment.
+Your first task is to decide between using an Azure AD tenant dedicated to testing or your production tenant as your test environment.
 
-Using a production tenant can make some aspects application testing easier, but it requires the right level of isolation between test and production resources. Isolation is especially important for high-privilege scenarios.
+Using a production tenant can make some aspects of application testing easier, but it requires the right level of isolation between test and production resources. Isolation is especially important for high-privilege scenarios.
 
 Don't use your production Azure AD tenant if:
 
@@ -34,7 +34,7 @@ Don't use your production Azure AD tenant if:
 - Policies are enabled in your production tenant that require user interaction during authentication. For example, if multi-factor authentication is required for all users, you can't use automated sign-ins for integration testing.
 - Adding non-production resources and/or workload to your production tenant would [exceed service or throttling limits](test-throttle-service-limits.md) for the tenant.
 
-If _any_ of these restrictions apply, set up a [test environment in a separate tenant](#set-up-a-test-environment-in-a-separate-tenant).
+If any of these restrictions apply, set up a [test environment in a separate tenant](#set-up-a-test-environment-in-a-separate-tenant).
 
 If none of these restrictions apply, you can set up a [test environment in your production tenant](#set-up-a-test-environment-in-your-production-tenant). Be aware that global administrators in your production tenant can access its resources and change its configuration at any time. To prevent access to any test resources or configuration, put that data in a separate tenant.