fixing merge conflict

Author: paulth1

.openpublishing.redirection.healthcare-apis.json

@@ -541,6 +541,14 @@
         "source_path_from_root": "/articles/healthcare-apis/iot/iot-metrics-diagnostics-export.md",
         "redirect_url": "/azure/healthcare-apis/iot/how-to-enable-diagnostic-settings",
         "redirect_document_id": false
-    }
+    },
+    {   "source_path_from_root": "/articles/healthcare-apis/events/events-display-metrics.md",
+        "redirect_url": "/azure/healthcare-apis/events/events-use-metrics",
+        "redirect_document_id": false
+    },
+    {    "source_path_from_root": "/articles/healthcare-apis/events/events-export-logs-metrics.md",
+        "redirect_url": "/azure/healthcare-apis/events/events-enable-diagnostic-settings",
+        "redirect_document_id": false
+    }    
   ]
 }

articles/active-directory-b2c/force-password-reset.md

@@ -9,9 +9,10 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 08/04/2022
+ms.date: 10/06/2022
 ms.author: kengaderdus
 ms.subservice: B2C
+ms.custom: b2c-support
 zone_pivot_groups: b2c-policy-type
 ---
 
@@ -132,6 +133,9 @@ Content-type: application/json
 
 If you disabled the strong [password complexity](password-complexity.md), update the password policy to [DisableStrongPassword](user-profile-attributes.md#password-policy-attribute):
 
+> [!NOTE]
+> After the user resets their password, the passwordPolicies will be changed back to DisablePasswordExpiration
+
 ```http
 PATCH https://graph.microsoft.com/v1.0/users/<user-object-ID>
 Content-type: application/json

articles/active-directory/develop/active-directory-optional-claims.md

@@ -53,7 +53,7 @@ The set of optional claims available by default for applications to use are list
 | `fwd`                      | IP address.| JWT    |   | Adds the original IPv4 address of the requesting client (when inside a VNET) |
 | `groups`| Optional formatting for group claims |JWT, SAML| |For details see [Group claims](#configuring-groups-optional-claims) below. For more information about group claims, see [How to configure group claims](../hybrid/how-to-connect-fed-group-claims.md). Used with the GroupMembershipClaims setting in the [application manifest](reference-app-manifest.md), which must be set as well.
 | `idtyp`                    | Token type   | JWT access tokens | Special: only in app-only access tokens |  Value is `app` when the token is an app-only token. This claim is the most accurate way for an API to determine if a token is an app token or an app+user token.|
-| `login_hint`               | Login hint   | JWT | MSA, Azure AD | An opaque, reliable login hint claim.  This claim is the best value to use for the `login_hint` OAuth parameter in all flows to get SSO.  It can be passed between applications to help them silently SSO as well - application A can sign in a user, read the `login_hint` claim, and then send the claim and the current tenant context to application B in the query string or fragment when the user selects on a link that takes them to application B. To avoid race conditions and reliability issues, the `login_hint` claim *doesn't* include the current tenant for the user, and defaults to the user's home tenant when used.  If you're operating in a guest scenario where the user is from another tenant, you must provide a tenant identifier in the sign-in request, and pass the same to apps you partner with. This claim is intended for use with your SDK's existing `login_hint` functionality, however that it exposed. |
+| `login_hint`               | Login hint   | JWT | MSA, Azure AD | An opaque, reliable login hint claim that's base64 encoded. Do not modify this value. This claim is the best value to use for the `login_hint` OAuth parameter in all flows to get SSO.  It can be passed between applications to help them silently SSO as well - application A can sign in a user, read the `login_hint` claim, and then send the claim and the current tenant context to application B in the query string or fragment when the user selects on a link that takes them to application B. To avoid race conditions and reliability issues, the `login_hint` claim *doesn't* include the current tenant for the user, and defaults to the user's home tenant when used.  If you're operating in a guest scenario where the user is from another tenant, you must provide a tenant identifier in the sign-in request, and pass the same to apps you partner with. This claim is intended for use with your SDK's existing `login_hint` functionality, however that it exposed. |
 | `sid`                      | Session ID, used for per-session user sign-out. | JWT        |  Personal and Azure AD accounts.   |         |
 | `tenant_ctry`              | Resource tenant's country/region | JWT | | Same as `ctry` except set at a tenant level by an admin.  Must also be a standard two-letter value. |
 | `tenant_region_scope`      | Region of the resource tenant | JWT        |           | |

articles/active-directory/governance/how-to-lifecycle-workflow-sync-attributes.md

@@ -23,10 +23,10 @@ The following table shows the scheduling (trigger) relevant attributes and the m
 |Attribute|Type|Supported in HR Inbound Provisioning|Support in Azure AD Connect Cloud Sync|Support in Azure AD Connect Sync| 
 |-----|-----|-----|-----|-----|
 |employeeHireDate|DateTimeOffset|Yes|Yes|Yes|
-|employeeLeaveDateTime|DateTimeOffset|Yes|Not currently|Not currently|
+|employeeLeaveDateTime|DateTimeOffset|Yes|Yes|Not currently|
 
 > [!NOTE]
-> To take advantaged of leaver scenarios, you can set the employeeLeaveDateTime manually for cloud-only users. For more information, see: [Configure the employeeLeaveDateTime property for a user](/graph/tutorial-lifecycle-workflows-set-employeeleavedatetime)
+> Manually setting the employeeLeaveDateTime for cloud-only users requires special permissions. For more information, see: [Configure the employeeLeaveDateTime property for a user](/graph/tutorial-lifecycle-workflows-set-employeeleavedatetime)
 
 This document explains how to set up synchronization from on-premises Azure AD Connect cloud sync and Azure AD Connect for the required attributes.
 

articles/active-directory/governance/lifecycle-workflow-tasks.md

@@ -74,10 +74,10 @@ For Microsoft Graph the parameters for the **Send welcome email to new hire** ta
 ```Example for usage within the workflow
 {
             "category": "joiner",
+            "continueOnError": true,
             "description": "Send welcome email to new hire",
             "displayName": "Send Welcome Email",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "70b29d51-b59a-4773-9280-8841dfd3f2ea",
             "arguments": []
 }
@@ -344,7 +344,6 @@ For Microsoft Graph the parameters for the **Remove user from selected groups**
 ```Example for usage within the workflow
 {
             "category": "leaver",
-            "continueOnError": true,
             "displayName": "Remove user from selected groups",
             "description": "Remove user from membership of selected Azure AD groups",
             "isEnabled": true,
@@ -388,7 +387,6 @@ For Microsoft Graph the parameters for the **Remove users from all groups** task
             "displayName": "Remove user from all groups",
             "description": "Remove user from all Azure AD groups memberships",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "b3a31406-2a15-4c9a-b25b-a658fa5f07fc",
             "arguments": []
 }
@@ -418,7 +416,6 @@ For Microsoft Graph the parameters for the **Remove User from Teams** task are a
             "displayName": "Remove user from selected Teams",
             "description": "Remove user from membership of selected Teams",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "06aa7acb-01af-4824-8899-b14e5ed788d6",
             "arguments": [
                 {
@@ -453,7 +450,6 @@ For Microsoft Graph the parameters for the **Remove users from all teams** task
             "description": "Remove user from all Teams",
             "displayName": "Remove user from all Teams memberships",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "81f7b200-2816-4b3b-8c5d-dc556f07b024",
             "arguments": []
 }
@@ -485,7 +481,6 @@ For Microsoft Graph the parameters for the **Remove all license assignment from
             "displayName": "Remove all licenses for user",
             "description": "Remove all licenses assigned to the user",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "8fa97d28-3e52-4985-b3a9-a1126f9b8b4e",
             "arguments": []
 }
@@ -516,7 +511,6 @@ For Microsoft Graph the parameters for the **Delete User** task are as follows:
             "displayName": "Delete user account",
             "description": "Delete user account in Azure AD",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "8d18588d-9ad3-4c0f-99d0-ec215f0e3dff",
             "arguments": []
 }
@@ -550,7 +544,6 @@ For Microsoft Graph the parameters for the **Send email before user last day** t
             "displayName": "Send email before user’s last day",
             "description": "Send offboarding email to user’s manager before the last day of work",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "52853a3e-f4e5-4eb8-bb24-1ac09a1da935",
             "arguments": []
 }
@@ -583,7 +576,6 @@ For Microsoft Graph the parameters for the **Send email on user last day** task
             "displayName": "Send email on user’s last day",
             "description": "Send offboarding email to user’s manager on the last day of work",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "9c0a1eaf-5bda-4392-9d9e-6e155bb57411",
             "arguments": []
 }
@@ -617,7 +609,6 @@ For Microsoft Graph the parameters for the **Send offboarding email to users man
             "displayName": "Send offboarding email to user’s manager after the last day of work",
             "description": "Send email after user’s last day",
             "isEnabled": true,
-            "continueOnError": true,
             "taskDefinitionId": "6f22ddd4-b3a5-47a4-a846-0d7c201a49ce",
             "arguments": []
 }

articles/active-directory/hybrid/how-to-connect-fed-o365-certs.md

@@ -174,7 +174,9 @@ Update Microsoft 365 with the new token signing certificates to be used for the
 > [!NOTE]
 > If you need to support multiple top-level domains, such as contoso.com and fabrikam.com, you must use the **SupportMultipleDomain** switch with any cmdlets. For more information, see [Support for Multiple Top Level Domains](how-to-connect-install-multiple-domains.md).
 >
-
+> If your tenant is federated with more than one domain, the Update-MsolFederatedDomain needs to be run for all the domains, listed in the output from `Get-MsolDomain -Authentication Federated`. This will ensure that all of the federated domains are updated to the Token-Signing certificate.
+>You can achieve this by running:
+>`Get-MsolDomain -Authentication Federated | % { Update-MsolFederatedDomain -DomainName $_.Name -SupportMultipleDomain }`
 
 ## Repair Azure AD trust by using Azure AD Connect <a name="connectrenew"></a>
 If you configured your AD FS farm and Azure AD trust by using Azure AD Connect, you can use Azure AD Connect to detect if you need to take any action for your token signing certificates. If you need to renew the certificates, you can use Azure AD Connect to do so.