Merge pull request #217915 from MicrosoftDocs/main

Publish to live, Thursday 4 AM PST, 11/10

Author: ttorble

.openpublishing.redirection.json

@@ -6358,6 +6358,11 @@
             "redirect_url": "/azure/azure-cache-for-redis/scripts/create-manage-cache",
             "redirect_document_id": false
         },
+        { 
+            "source_path_from_root": "/articles/storage/blobs/anonymous-read-access-client.md",
+            "redirect_url": "/azure/storage/blobs/anonymous-read-access-prevent",
+            "redirect_document_id": false
+        },
         { 
             "source_path_from_root": "/articles/storage/common/storage-auth-abac-attributes.md",
             "redirect_url": "/azure/storage/blobs/storage-auth-abac-attributes",

articles/active-directory/app-proxy/application-proxy-configure-native-client-application.md

@@ -112,6 +112,6 @@ After you edit the MSAL code with these parameters, your users can authenticate
 
 ## Next steps
 
-For more information about the native application flow, see [Native apps in Azure Active Directory](../azuread-dev/native-app.md).
+For more information about the native application flow, see [mobile](../develop/authentication-flows-app-scenarios.md#mobile-app-that-calls-a-web-api-on-behalf-of-an-interactive-user) and [desktop](../develop/authentication-flows-app-scenarios.md#desktop-app-that-calls-a-web-api-on-behalf-of-a-signed-in-user) apps in Azure Active Directory.
 
 Learn about setting up [Single sign-on to applications in Azure Active Directory](../manage-apps/sso-options.md#choosing-a-single-sign-on-method).

articles/active-directory/authentication/howto-authentication-temporary-access-pass.md

@@ -147,7 +147,7 @@ Users with a Temporary Access Pass can navigate the setup process on Windows 10
 For Azure AD Joined devices: 
 - During the Azure AD Join setup process, users can authenticate with a TAP (no password required) to join the device and register Windows Hello for Business.
 - On already joined devices, users must first authenticate with another method such as a password, smartcard or FIDO2 key, before using TAP to set up Windows Hello for Business. 
-- If the [Web sign-in](https://learn.microsoft.com/windows/client-management/mdm/policy-csp-authentication#authentication-enablewebsignin) feature on Windows is also enabled, the user can use TAP to sign into the device. This is intended only for completing initial device setup, or recovery when the user does not know or have a password. 
+- If the [Web sign-in](/windows/client-management/mdm/policy-csp-authentication#authentication-enablewebsignin) feature on Windows is also enabled, the user can use TAP to sign into the device. This is intended only for completing initial device setup, or recovery when the user does not know or have a password. 
 
 For Hybrid Azure AD Joined devices: 
 - Users must first authenticate with another method such as a password, smartcard or FIDO2 key, before using TAP to set up Windows Hello for Business. 

articles/active-directory/authentication/howto-authentication-use-email-signin.md

@@ -153,7 +153,7 @@ With the policy applied, it can take up to 1 hour to propagate and for users to
 ### PowerShell
 
 > [!NOTE]
-> This configuration option uses HRD policy. For more information, see [homeRealmDiscoveryPolicy resource type](/graph/api/resources/homeRealmDiscoveryPolicy?view=graph-rest-1.0).
+> This configuration option uses HRD policy. For more information, see [homeRealmDiscoveryPolicy resource type](/graph/api/resources/homeRealmDiscoveryPolicy?view=graph-rest-1.0&preserve-view=true).
 
 Once users with the *ProxyAddresses* attribute applied are synchronized to Azure AD using Azure AD Connect, you need to enable the feature for users to sign-in with email as an alternate login ID for your tenant. This feature tells the Azure AD login servers to not only check the sign-in identifier against UPN values, but also against *ProxyAddresses* values for the email address.
 

articles/active-directory/develop/msal-logging-dotnet.md

@@ -65,7 +65,7 @@ The following code snippets are examples of such an implementation. If you use t
 
 #### Log level from configuration file
 
-It's highly recommended to configure your code to use a configuration file in your environment to set the log level as it will enable your code to change the MSAL logging level without needing to rebuild or restart the application. This is critical for diagnostic purposes, enabling us to quickly gather the required logs from the application that is currently deployed and in production. Verbose logging can be costly so it's best to use the *Information* level by default and enable verbose logging when an issue is encountered. [See JSON configuration provider](https://docs.microsoft.com/aspnet/core/fundamentals/configuration#json-configuration-provider) for an example on how to load data from a configuration file without restarting the application.
+It's highly recommended to configure your code to use a configuration file in your environment to set the log level as it will enable your code to change the MSAL logging level without needing to rebuild or restart the application. This is critical for diagnostic purposes, enabling us to quickly gather the required logs from the application that is currently deployed and in production. Verbose logging can be costly so it's best to use the *Information* level by default and enable verbose logging when an issue is encountered. [See JSON configuration provider](/aspnet/core/fundamentals/configuration#json-configuration-provider) for an example on how to load data from a configuration file without restarting the application.
 
 #### Log Level as Environment Variable
 

articles/active-directory/develop/msal-net-token-cache-serialization.md

@@ -280,7 +280,7 @@ You can also specify options to limit the size of the in-memory token cache:
 
 #### Distributed caches
 
-If you use `app.AddDistributedTokenCache`, the token cache is an adapter against the .NET `IDistributedCache` implementation. So you can choose between a SQL Server cache, a Redis cache, an Azure Cosmos DB cache, or any other cache implementing the [IDistributedCache](/dotnet/api/microsoft.extensions.caching.distributed.idistributedcache?view=dotnet-plat-ext-6.0) interface. 
+If you use `app.AddDistributedTokenCache`, the token cache is an adapter against the .NET `IDistributedCache` implementation. So you can choose between a SQL Server cache, a Redis cache, an Azure Cosmos DB cache, or any other cache implementing the [IDistributedCache](/dotnet/api/microsoft.extensions.caching.distributed.idistributedcache?view=dotnet-plat-ext-6.0&preserve-view=true) interface. 
 
 For testing purposes only, you may want to use `services.AddDistributedMemoryCache()`, an in-memory implementation of `IDistributedCache`. 
 

articles/active-directory/develop/reference-app-multi-instancing.md

@@ -48,5 +48,5 @@ The IDP initiated feature exposes two settings for each application.  
 
 ## Next steps
 
-- To explore the claims mapping policy in graph see [Claims mapping policy](/graph/api/resources/claimsMappingPolicy?view=graph-rest-1.0)  
+- To explore the claims mapping policy in graph see [Claims mapping policy](/graph/api/resources/claimsMappingPolicy?view=graph-rest-1.0&preserve-view=true)  
 - To learn more about how to configure this policy see [Customize app SAML token claims](active-directory-saml-claims-customization.md)

articles/active-directory/develop/tutorial-v2-nodejs-webapp-msal.md

@@ -133,7 +133,7 @@ Fill in these details with the values you obtain from Azure app registration por
 
 ## Add code for user sign-in and token acquisition
 
-1. Create a new file named *auth.js* under the *router* folder and add the following code there:
+1. Create a new file named *auth.js* under the *routes* folder and add the following code there:
 
 :::code language="js" source="~/ms-identity-node/App/routes/auth.js":::
 

articles/active-directory/enterprise-users/clean-up-stale-guest-accounts.md

@@ -18,23 +18,23 @@ ms.collection: M365-identity-device-management
 
 As users collaborate with external partners, it’s possible that many guest accounts get created in Azure Active Directory (Azure AD) tenants over time. When collaboration ends and the users no longer access your tenant, the guest accounts may become stale. Admins can use Access Reviews to automatically review inactive guest users and block them from signing in, and later, delete them from the directory.
 
-Learn more about [how to manage inactive user accounts in Azure AD](https://learn.microsoft.com/azure/active-directory/reports-monitoring/howto-manage-inactive-user-accounts).
+Learn more about [how to manage inactive user accounts in Azure AD](/azure/active-directory/reports-monitoring/howto-manage-inactive-user-accounts).
 
 There are a few recommended patterns that are effective at cleaning up stale guest accounts:
 
 1. Create a multi-stage review whereby guests self-attest whether they still need access. A second-stage reviewer assesses results and makes a final decision. Guests with denied access are disabled and later deleted.
 
-2. Create a review to remove inactive external guests. Admins define inactive as period of days. They disable and later delete guests that don’t sign in to the tenant within that time frame. By default, this doesn't affect recently created users. [Learn more about how to identify inactive accounts](https://learn.microsoft.com/azure/active-directory/reports-monitoring/howto-manage-inactive-user-accounts#how-to-detect-inactive-user-accounts).
+2. Create a review to remove inactive external guests. Admins define inactive as period of days. They disable and later delete guests that don’t sign in to the tenant within that time frame. By default, this doesn't affect recently created users. [Learn more about how to identify inactive accounts](/azure/active-directory/reports-monitoring/howto-manage-inactive-user-accounts#how-to-detect-inactive-user-accounts).
 
 Use the following instructions to learn how to create Access Reviews that follow these patterns. Consider the configuration recommendations and then make the needed changes that suit your environment.
 
 ## Create a multi-stage review for guests to self-attest continued access
 
-1. Create a [dynamic group](https://learn.microsoft.com/azure/active-directory/enterprise-users/groups-create-rule) for the guest users you want to review. For example,
+1. Create a [dynamic group](/azure/active-directory/enterprise-users/groups-create-rule) for the guest users you want to review. For example,
 
    `(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)`
 
-2. To [create an Access Review](https://learn.microsoft.com/azure/active-directory/governance/create-access-review)
+2. To [create an Access Review](/azure/active-directory/governance/create-access-review)
     for the dynamic group, navigate to **Azure Active Directory > Identity Governance > Access Reviews**.
 
 3. Select **New access review**.
@@ -98,11 +98,11 @@ Use the following instructions to learn how to create Access Reviews that follow
 
 ## Create a review to remove inactive external guests
 
-1. Create a [dynamic group](https://learn.microsoft.com/azure/active-directory/enterprise-users/groups-create-rule) for the guest users you want to review. For example,
+1. Create a [dynamic group](/azure/active-directory/enterprise-users/groups-create-rule) for the guest users you want to review. For example,
 
    `(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)`
 
-2. To [create an access review](https://learn.microsoft.com/azure/active-directory/governance/create-access-review) for the dynamic group, navigate to **Azure Active Directory > Identity Governance > Access Reviews**.
+2. To [create an access review](/azure/active-directory/governance/create-access-review) for the dynamic group, navigate to **Azure Active Directory > Identity Governance > Access Reviews**.
 
 3. Select **New access review**.
 

articles/active-directory/fundamentals/10-secure-local-guest.md

@@ -19,7 +19,7 @@ ms.collection: M365-identity-device-management
 Azure Active Directory (Azure AD B2B) allows external users to collaborate using their own identities. However, it isn't uncommon for organizations to issue local usernames and passwords to external users. This approach isn't recommended as the bring-your-own-identity (BYOI) capabilities provided
 by Azure AD B2B to provide better security, lower cost, and reduce
 complexity when compared to local account creation. Learn more
-[here.](https://learn.microsoft.com/azure/active-directory/fundamentals/secure-external-access-resources)
+[here.](/azure/active-directory/fundamentals/secure-external-access-resources)
 
 If your organization currently issues local credentials that external users have to manage and would like to migrate to using Azure AD B2B instead, this document provides a guide to make the transition as seamlessly as possible.
 
@@ -28,7 +28,7 @@ If your organization currently issues local credentials that external users have
 Before migrating local accounts to Azure AD B2B, admins should understand what applications and workloads these external users need to access. For example, if external users need access to an application that is hosted on-premises, admins will need to validate that the application is integrated with Azure AD and that a provisioning process is implemented to provision the user from Azure AD to the application.
 The existence and use of on-premises applications could be a reason why local accounts are created in the first place. Learn more about
 [provisioning B2B guests to on-premises
-applications.](https://learn.microsoft.com/azure/active-directory/external-identities/hybrid-cloud-to-on-premises)
+applications.](/azure/active-directory/external-identities/hybrid-cloud-to-on-premises)
 
 All external-facing applications should have single-sign on (SSO) and provisioning integrated with Azure AD for the best end user experience.
 
@@ -59,7 +59,7 @@ External users should be notified that the migration will be taking place and wh
 
 ## Migrate local guest accounts to Azure AD B2B
 
-Once the local accounts have their user.mail attributes populated with the external identity/email that they're mapped to, admins can [convert the local accounts to Azure AD B2B by inviting the local account.](https://learn.microsoft.com/azure/active-directory/external-identities/invite-internal-users)
+Once the local accounts have their user.mail attributes populated with the external identity/email that they're mapped to, admins can [convert the local accounts to Azure AD B2B by inviting the local account.](/azure/active-directory/external-identities/invite-internal-users)
 This can be done in the UX or programmatically via PowerShell or the Microsoft Graph API. Once complete, the users will no longer
 authenticate with their local password, but will instead authenticate with their home identity/email that was populated in the user.mail attribute. You've successfully migrated to Azure AD B2B.