Merge branch 'main' into release-msid-gtd-tutorial-web-app

Author: v-alje

.openpublishing.redirection.healthcare-apis.json

@@ -590,7 +590,11 @@
           "redirect_document_id": false
       },
       {   "source_path_from_root": "/articles/healthcare-apis/iot/data-flow.md",
-          "redirect_url": "/azure/healthcare-apis/iot/understand-service",
+          "redirect_url": "/azure/healthcare-apis/iot/overview-of-device-message-processing-stages",
+          "redirect_document_id": false
+      },
+      {   "source_path_from_root": "/articles/healthcare-apis/iot/understand-service.md",
+          "redirect_url": "/azure/healthcare-apis/iot/overview-of-device-message-processing-stages",
           "redirect_document_id": false
       },
       {   "source_path_from_root": "/articles/healthcare-apis/iot/how-to-use-device-mappings.md",

articles/active-directory/conditional-access/media/workload-identity/conditional-access-workload-identity-risk-policy.png

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: workload-identities
 ms.topic: how-to
-ms.date: 01/05/2023
+ms.date: 04/04/2023
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -29,7 +29,7 @@ These differences make workload identities harder to manage and put them at high
 
 > [!IMPORTANT]
 > Workload Identities Premium licenses are required to create or modify Conditional Access policies scoped to service principals. 
-> In directories without appropriate licenses, existing Conditional Access policies for workload identities will continue to function, but can't be modified. For more information see [Microsoft Entra Workload Identities](https://www.microsoft.com/security/business/identity-access/microsoft-entra-workload-identities#office-StandaloneSKU-k3hubfz).  
+> In directories without appropriate licenses, existing Conditional Access policies for workload identities will continue to function, but can't be modified. For more information, see [Microsoft Entra Workload Identities](https://www.microsoft.com/security/business/identity-access/microsoft-entra-workload-identities#office-StandaloneSKU-k3hubfz).  
 
 > [!NOTE]
 > Policy can be applied to single tenant service principals that have been registered in your tenant. Third party SaaS and multi-tenanted apps are out of scope. Managed identities are not covered by policy. 
@@ -49,7 +49,7 @@ Create a location based Conditional Access policy that applies to service princi
 1. Under **Assignments**, select **Users or workload identities**.
    1. Under **What does this policy apply to?**, select **Workload identities**.
    1. Under **Include**, choose **Select service principals**, and select the appropriate service principals from the list.
-1. Under **Cloud apps or actions**, select **All cloud apps**. The policy will apply only when a service principal requests a token.
+1. Under **Cloud apps or actions**, select **All cloud apps**. The policy applies only when a service principal requests a token.
 1. Under **Conditions** > **Locations**, include **Any location** and exclude **Selected locations** where you want to allow access.
 1. Under **Grant**, **Block access** is the only available option. Access is blocked when a token request is made from outside the allowed range.
 1. Your policy can be saved in **Report-only** mode, allowing administrators to estimate the effects, or policy is enforced by turning policy **On**.
@@ -68,7 +68,7 @@ Create a risk-based Conditional Access policy that applies to service principals
 1. Under **Assignments**, select **Users or workload identities**.
    1. Under **What does this policy apply to?**, select **Workload identities**.
    1. Under **Include**, choose **Select service principals**, and select the appropriate service principals from the list.
-1. Under **Cloud apps or actions**, select **All cloud apps**. The policy will apply only when a service principal requests a token.
+1. Under **Cloud apps or actions**, select **All cloud apps**. The policy applies only when a service principal requests a token.
 1. Under **Conditions** > **Service principal risk**
    1. Set the **Configure** toggle to **Yes**.
    1. Select the levels of risk where you want this policy to trigger.

articles/active-directory/conditional-access/workload-identity.md

@@ -59,7 +59,7 @@ Refer to the [configuration documentation](./msal-configuration.md) for more inf
 
 Set `"shared_device_mode_supported"` to `true` in your MSAL configuration file.
 
-You may not be planning to support multiple-account mode. That could be if you're not using a shared device, and the user can sign into the app with more than one account at the same time. If so, set `"account_mode"` to `"SINGLE"`. This guarantees that your app will always get `ISingleAccountPublicClientApplication`, and significantly simplifies your MSAL integration. The default value of `"account_mode"` is `"MULTIPLE"`, so it is important to change this value in the config file if you're using `"single account"` mode.
+You may not be planning to support multiple-account mode. That could be if you're not using a shared device, and the user can sign into the app with more than one account at the same time. If so, set `"account_mode"` to `"SINGLE"`. This guarantees that your app will always get `ISingleAccountPublicClientApplication`, and significantly simplifies your MSAL integration. The default value of `"account_mode"` is `"MULTIPLE"`, so it's important to change this value in the config file if you're using `"single account"` mode.
 
 Here's an example of the auth_config.json file included in the **app**>**main**>**res**>**raw** directory of the sample app:
 
@@ -85,7 +85,7 @@ Here's an example of the auth_config.json file included in the **app**>**main**>
 
 ### Detect shared-device mode
 
-Shared-device mode allows you to configure Android devices to be shared by multiple employees, while providing Microsoft Identity backed management of the device. Employees can sign in to their devices and access customer information quickly. When they are finished with their shift or task, they will be able to sign-out of all apps on the shared device with a single click and the device will be immediately ready for the next employee to use.
+Shared-device mode allows you to configure Android devices to be shared by multiple employees, while providing Microsoft Identity backed management of the device. Employees can sign in to their devices and access customer information quickly. When they're finished with their shift or task, they'll be able to sign-out of all apps on the shared device with a single click and the device will be immediately ready for the next employee to use.
 
 Use `isSharedDevice()` to determine if an app is running on a device that is in shared-device mode. Your app could use this flag to determine if it should modify UX accordingly.
 
@@ -122,7 +122,7 @@ PublicClientApplication.create(this.getApplicationCOntext(),
 
 If you're writing an app that will only be used for first-line workers on a shared device, we recommend you write your app to only support single-account mode. This includes most applications that are task focused such as medical records apps, invoice apps, and most line-of-business apps. This will simplify your development as many features of the SDK won't need to be accommodated.
 
-If your app supports multiple accounts as well as shared device mode, you must perform a type check and cast to the appropriate interface as shown below.
+If your app supports multiple accounts and shared device mode, you must perform a type check and cast to the appropriate interface as shown below.
 
 ```java
 private IPublicClientApplication mApplication;
@@ -207,9 +207,9 @@ private void onSignOutClicked()
 
 ### Receive broadcast to detect global sign out initiated from other applications
 
-To receive the account change broadcast, you'll need to register a broadcast receiver.  It’s recommended to register your broadcast receiver via the [Context-registered receivers](https://developer.android.com/guide/components/broadcasts#context-registered-receivers).
+To receive the account change broadcast, you need to register a broadcast receiver.  It’s recommended to register your broadcast receiver via the [Context-registered receivers](https://developer.android.com/guide/components/broadcasts#context-registered-receivers).
 
-When an account change broadcast is received, immediately [get the signed in user and determine if a user has changed on the device](#get-the-signed-in-user-and-determine-if-a-user-has-changed-on-the-device). If a change is detected, initiate data cleanup for previously signed-in account. It is recommended to properly stop any operations and do data cleanup.
+When an account change broadcast is received, immediately [get the signed in user and determine if a user has changed on the device](#get-the-signed-in-user-and-determine-if-a-user-has-changed-on-the-device). If a change is detected, initiate data cleanup for previously signed-in account. It's recommended to properly stop any operations and do data cleanup.
 
 The following code snippet shows how you could register a broadcast receiver.
 
@@ -238,14 +238,14 @@ The following steps describe setting up your application in the Azure portal and
 
 First, register your application within your organizational tenant. Then provide these values below in auth_config.json in order for your application to run correctly.
 
-For information on how to do this, refer to [Register your application](./tutorial-v2-android.md#register-your-application).
+For information on how to do this, refer to [Register your application](./tutorial-v2-android.md#register-your-application-with-azure-ad).
 
 > [!NOTE]
 > When you register your app, please use the quickstart guide on the left-hand side and then select **Android**. This will lead you to a page where you'll be asked to provide the **Package Name** and **Signature Hash** for your app. These are very important to ensure your app configuration will work. You'll then receive a configuration object that you can use for your app that you'll cut and paste into your auth_config.json file.
 
 :::image type="content" source="media/tutorial-v2-shared-device-mode/register-app.png" alt-text="Configure your Android app page in Azure portal quickstart":::
 
-You should select **Make this change for me** and then provide the values the quickstart asks for in the Azure portal. When that's done, we will generate all the configuration files you need.
+You should select **Make this change for me** and then provide the values the quickstart asks for in the Azure portal. When that's done, we'll generate all the configuration files you need.
 
 :::image type="content" source="media/tutorial-v2-shared-device-mode/config-info.png" alt-text="Configure your project page in Azure portal quickstart":::
 
@@ -257,7 +257,7 @@ For testing purposes, set up the following in your tenant: at least two employee
 
 ### Download the Authenticator App
 
-Download the Microsoft Authenticator App from the Google Play store. If you already have the app downloaded, ensure that it is the latest version.
+Download the Microsoft Authenticator App from the Google Play store. If you already have the app downloaded, ensure that it's the latest version.
 
 ### Authenticator app settings & registering the device in the cloud
 
@@ -293,7 +293,7 @@ Once you've put a device in shared-mode, it becomes known to your organization a
 
 ## Running the sample app
 
-The Sample Application is a simple app that will call the Graph API of your organization. On first run you'll be prompted to consent as the application is new to your employee account.
+The Sample Application is a simple app that will call the Graph API of your organization. On first run, you'll be prompted to consent as the application is new to your employee account.
 
 :::image type="content" source="media/tutorial-v2-shared-device-mode/run-app-permissions-requested.png" alt-text="Application configuration info screen":::
 

articles/active-directory/develop/tutorial-v2-android.md

@@ -1,11 +1,11 @@
 ---
-title: Clean up unmanaged Azure AD accounts
-description: Clean up unmanaged accounts using email OTP and PowerShell modules in Azure Active Directory
+title: Clean up unmanaged Azure Active Directory accounts
+description: Clean up unmanaged accounts using email one-time password and PowerShell modules in Azure AD
 services: active-directory 
 author: gargi-sinha
 ms.author: gasinh
 manager: martinco
-ms.date: 06/28/2022
+ms.date: 03/28/2023
 ms.topic: how-to
 ms.service: active-directory
 ms.subservice: enterprise-users
@@ -16,68 +16,65 @@ ms.collection: M365-identity-device-management
 
 # Clean up unmanaged Azure Active Directory accounts
 
-Prior to August 2022, Azure AD B2B supported Self-service sign-up for email-verified users which allowed users to create Azure AD accounts if they can verify ownership of the email. These accounts were created in unmanaged (aka “viral”) tenants. This meant that the user created an account with an organization’s domain that is not under the lifecycle management of the organization’s IT and access can persist after the user leaves the organization. To learn more, see, [What is self-service sign-up for Azure Active Directory?](./directory-self-service-signup.md)
+Prior to August 2022, Azure Active Directory B2B (Azure AD B2B) supported self-service sign-up for email-verified users. With this feature, users create Azure AD accounts, when they verify email ownership. These accounts were created in unmanaged (or viral) tenants: users created accounts with an organization domain, not under IT team management. Access persists after users leave the organization. 
 
-The creation of unmanaged Azure AD accounts via Azure AD B2B is now deprecated and new B2B invitations cannot be redeemed with these accounts as of August 2022. However, invitations sent prior to August 2022 could have been redeemed with unmanaged Azure AD accounts. 
+To learn more, see, [What is self-service sign-up for Azure AD?](./directory-self-service-signup.md)
+
+   > [!NOTE]
+   > Unmanaged Azure AD accounts via Azure AD B2B were deprecated. As of August 2022, new B2B invitations can't be redeemed. However, invitations prior to August 2022 were redeemable with unmanaged Azure AD accounts. 
 
 ## Remove unmanaged Azure AD accounts
 
-Admins can use either this sample application in [Azure-samples/Remove-unmanaged-guests](https://github.com/Azure-Samples/Remove-Unmanaged-Guests) or PowerShell cmdlets in [AzureAD/MSIdentityTools](https://github.com/AzureAD/MSIdentityTools/wiki/) to remove existing unmanaged Azure AD accounts from your Azure AD tenants. These tools allow you to identify viral users in your Azure AD tenant and reset the redemption status of these users.  
+Use the following guidance to remove unmanaged Azure AD accounts from Azure AD tenants. Tool features help identify viral users in the Azure AD tenant. You can reset the user redemption status.
+
+* Use the sample application in [Azure-samples/Remove-unmanaged-guests](https://github.com/Azure-Samples/Remove-Unmanaged-Guests)
+* Use PowerShell cmdlets in [AzureAD/MSIdentityTools](https://github.com/AzureAD/MSIdentityTools/wiki/)  
 
-Once you have run one of the available tools, when users with unmanaged Azure AD accounts try to access your tenant, they will re-redeem their invitations. However, Azure AD will prevent users from redeeming with an existing unmanaged Azure AD account and they’ll redeem with another account type. Google Federation and SAML/WS-Fed are not enabled by default. So by default, these users will redeem with either an MSA or Email OTP, with MSA taking precedence. For a full explanation on the B2B redemption precedence, refer to the [redemption precedence flow chart](../external-identities/redemption-experience.md#invitation-redemption-flow).
+After you run a tool, users with unmanaged Azure AD accounts access the tenant, and re-redeem their invitations. However, Azure AD prevents users from redeeming with an unmanaged Azure AD account. They can redeem with another account type. Google Federation and SAML/WS-Federation aren't enabled by default. Therefore, users redeem with a Microsoft account (MSA) or email one-time password (OTP). MSA is recommended. 
+
+Learn more: [Invitation redemption flow](../external-identities/redemption-experience.md#invitation-redemption-flow)
 
 ## Overtaken tenants and domains
 
-Some tenants created as unmanaged tenants can be taken over and
-converted to a managed tenant. See, [take over an unmanaged directory as
-administrator in Azure AD](./domains-admin-takeover.md).
+It's possible to convert some unmanaged tenants to managed tenants. 
 
-In some cases, overtaken domains might not be updated, for example, missing a DNS TXT record and therefore become flagged as unmanaged. Implications are:
+Learn more: [Take over an unmanaged directory as administrator in Azure AD](./domains-admin-takeover.md)
 
-- For guest users who belong to formerly unmanaged tenants, redemption status is reset and one consent prompt appears. Redemption occurs with same account as before.
+Some overtaken domains might not be updated. For example, a missing DNS TXT record indicates an unmanaged state. Implications are:
 
-- After unmanaged user redemption status is reset, the tool might identify unmanaged users that are false positives.
+* For guest users from unmanaged tenants, redemption status is reset. A consent prompt appears. 
+  * Redemption occurs with same account
+* The tool might identify unmanaged users as false positives after you reset unmanaged user redemption status
 
-## Reset redemption using a sample application
+## Reset redemption with a sample application
 
-Use the sample application on
-    [Azure-Samples/Remove-Unmanaged-Guests](https://github.com/Azure-Samples/Remove-Unmanaged-Guests).
+Use the sample application on [Azure-Samples/Remove-Unmanaged-Guests](https://github.com/Azure-Samples/Remove-Unmanaged-Guests).
 
 ## Reset redemption using MSIdentityTools PowerShell Module
 
-MSIdentityTools PowerShell Module is a collection of cmdlets and
-scripts. They are for use in the Microsoft identity platform and Azure
-AD; they augment capabilities in the PowerShell SDK. See, [Microsoft
-Graph PowerShell
-SDK](https://github.com/microsoftgraph/msgraph-sdk-powershell).
+MSIdentityTools PowerShell Module is a collection of cmdlets and scripts, which you use in the Microsoft identity platform and Azure AD. Use the cmdlets and scripts to augment PowerShell SDK capabilities. See, [microsoftgraph/msgraph-sdk-powershell](https://github.com/microsoftgraph/msgraph-sdk-powershell).
 
 Run the following cmdlets:
 
-- `Install-Module Microsoft.Graph -Scope CurrentUser`
-
-- `Install-Module MSIdentityTools`
-
-- `Import-Module msidentitytools,microsoft.graph`
+* `Install-Module Microsoft.Graph -Scope CurrentUser`
+* `Install-Module MSIdentityTools`
+* `Import-Module msidentitytools,microsoft.graph`
 
 To identify unmanaged Azure AD accounts, run:
 
-- `Connect-MgGraph -Scope User.ReadAll`
-
-- `Get-MsIdUnmanagedExternalUser`
+* `Connect-MgGraph -Scope User.ReadAll`
+* `Get-MsIdUnmanagedExternalUser`
 
 To reset unmanaged Azure AD account redemption status, run:
 
-- `Connect-MgGraph -Scopes User.ReadWriteAll`
-
-- `Get-MsIdUnmanagedExternalUser | Reset-MsIdExternalUser`
+* `Connect-MgGraph -Scopes User.ReadWriteAll`
+* `Get-MsIdUnmanagedExternalUser | Reset-MsIdExternalUser`
 
 To delete unmanaged Azure AD accounts, run:
 
-- `Connect-MgGraph -Scopes User.ReadWriteAll`
-
-- `Get-MsIdUnmanagedExternalUser | Remove-MgUser`
+* `Connect-MgGraph -Scopes User.ReadWriteAll`
+* `Get-MsIdUnmanagedExternalUser | Remove-MgUser`
 
-## Next steps
+## Resources
 
-Examples of using
-[Get-MSIdUnmanagedExternalUser](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MsIdUnmanagedExternalUser)
+See, [Get-MSIdUnmanagedExternalUser](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MsIdUnmanagedExternalUser). The tool returns a list of external unmanaged users, or viral users, in the tenant.