fix merge conflict

Author: diberry

.openpublishing.publish.config.json

@@ -259,6 +259,24 @@
       "url": "https://github.com/Azure-Samples/cognitive-services-java-sdk-samples",
       "branch": "master",
       "branch_mapping": {}
+    },
+    {
+      "path_to_root": "aml-sdk-samples",
+      "url": "https://github.com/Azure/MachineLearningNotebooks",
+      "branch": "sdk-codetest",
+      "branch_mapping": {}
+    },
+    {
+      "path_to_root": "cognitive-services-vision-csharp-sdk-quickstarts",
+      "url": "https://github.com/Azure-Samples/cognitive-services-vision-csharp-sdk-quickstarts",
+      "branch": "master",
+      "branch_mapping": {}
+    },
+    {
+      "path_to_root": "cognitive-face-csharp-sample",
+      "url": "https://github.com/Azure-Samples/Cognitive-Face-CSharp-sample",
+      "branch": "master",
+      "branch_mapping": {}
     }
   ],
   "branch_target_mapping": {

.openpublishing.redirection.json

@@ -1,5 +1,10 @@
 {
     "redirections": [
+        {
+            "source_path": "articles/machine-learning/service/how-to-choose-a-dev-environment.md",
+            "redirect_url": "/azure/machine-learning/service/how-to-configure-environment",
+            "redirect_document_id": false
+        },
         {
             "source_path": "articles/frontdoor/front-door-powershell-reference.md",
             "redirect_url": "/powershell/module/azurerm.frontdoor",
@@ -11069,6 +11074,11 @@
             "redirect_url": "/azure/monitoring-and-diagnostics/alert-log",
             "redirect_document_id": false
         },
+        {
+            "source_path": "articles/monitoring-and-diagnostics/monitoring-overview-unified-alerts.md",
+            "redirect_url": "/azure/monitoring-and-diagnostics/monitoring-overview-alerts",
+            "redirect_document_id": false
+        },
         {
             "source_path": "articles/monitoring-and-diagnostics/monitoring-create-activity-log-alerts-with-resource-manager-template.md",
             "redirect_url": "/azure/monitoring-and-diagnostics/alert-activity-log",
@@ -30510,6 +30520,17 @@
             "source_path": "articles/iot-central/howto-create-application.md",
             "redirect_url": "/azure/iot-central/quick-deploy-iot-central",
             "redirect_document_id" : false
+        },
+        {
+            "source_path": "articles/media-services/latest/create-account-cli-quickstart.md",
+            "redirect_url": "/azure/media-services/latest/create-account-cli-how-to",
+            "redirect_document_id" : false
+        },
+	    {  
+            "source_path": "articles/backup/backup-mabs-upgrade-to-v2.md",
+            "redirect_url": "/azure/backup/backup-mabs-whats-new-mabs",
+            "redirect_document_id" : false
         }
+
     ]
 }

articles/active-directory-b2c/claimsschema.md

@@ -105,7 +105,7 @@ The **Mask** element contains the following attributes:
 | Type | Yes | The type of the claim mask. Possible values: `Simple` or `Regex`. The `Simple` value indicates that a simple text mask is applied to the leading portion of a string claim. The `Regex` value indicates that a regular expression is applied to the string claim as whole.  If the `Regex` value is specified, an optional attribute must also be defined with the regular expression to use. |
 | Regex | No | If **Type** is set to `Regex`, specify the regular expression to use.
 
-The follwing example configures a **PhoneNumber** claim with the `Simple` mask:
+The following example configures a **PhoneNumber** claim with the `Simple` mask:
 
 ```XML
 <ClaimType Id="PhoneNumber">
@@ -120,7 +120,7 @@ The Identity Experience Framework renders the phone number while hiding the firs
 
 ![Using claim type with mask](./media/claimsschema/mask.png)
 
-The follwing example configures a **AlternateEmail** claim with the `Regex` mask:
+The following example configures a **AlternateEmail** claim with the `Regex` mask:
 
 ```XML
 <ClaimType Id="AlternateEmail">

articles/active-directory-b2c/oauth2-technical-profile.md

@@ -42,7 +42,7 @@ The **InputClaims** and **InputClaimsTransformations** elements are not required
 
 ## Output claims
 
-The **OutputClaims** element contains a list of claims returned by the OAuth2 identity provider. You may need to map the name of the claim defined in your policy to the name defined in the identity provider. You can also include claims that aren't returned by the identity provider as long as the you set the `DefaultValue` attribute.
+The **OutputClaims** element contains a list of claims returned by the OAuth2 identity provider. You may need to map the name of the claim defined in your policy to the name defined in the identity provider. You can also include claims that aren't returned by the identity provider as long as you set the `DefaultValue` attribute.
 
 The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
 

articles/active-directory-b2c/technical-profiles-overview.md

@@ -34,8 +34,7 @@ A technical profile enables these types of scenarios:
 - [SAML2](saml-technical-profile.md) - Federation with any SAML protocol identity provider.
 - [Self-Asserted](self-asserted-technical-profile.md) - Interact with the user. For example, collect the user's credential to sign in, render the sign-up page, or password reset.
 - **WsFed** - Federation with any WsFed protocol identity provider. 
-- **Session management** - Handle different types of sessions. 
-- **User journey context provider**
+- [Session management](active-directory-b2c-reference-sso-custom.md) - Handle different types of sessions. 
 - **Application insights**
 
 ## Technical profile flow
@@ -52,7 +51,7 @@ All types of technical profiles share the same concept. You send input claims, r
     - Create or update the user account.
     - Sends and verifies the MFA text message.
 4. **ValidationTechnicalProfiles** - For a [self asserted technical profile](self-asserted-technical-profile.md), you can call an input [validation technical profile](validation-technical-profile.md). The validation technical profile validates the data profiled by the user and returns an error message or Ok, with or without output claims. For example, before Azure AD B2C creates a new account, it checks whether the user already exists in the directory services. You can call a REST API technical profile to add your own business logic.<p>The scope of the output claims of a validation technical profile is limited to the technical profile that invokes the validation technical profile and other validation technical profiles under same technical profile. If you want to use the output claims in the next orchestration step, you need to add the output claims to the technical profile that invokes the validation technical profile.
-5. **OutputClaims** - Claims are retuned back to the claims bag. You can use those claims in the next orchestrations step, or output claims transformations.
+5. **OutputClaims** - Claims are returned back to the claims bag. You can use those claims in the next orchestrations step, or output claims transformations.
 6. **OutputClaimsTransformations** - Input claims of every output [claims transformation](claimstransformations.md) are picked up from the claims bag. The output claims of the technical profile from the previous steps can be input claims of an output claims transformation. After execution, the output claims are put back in the claims bag. The output claims of an output claims transformation can also be input claims of a subsequent output claims transformation.
 7. **Single sign-on (SSO) session management** - [SSO session management](active-directory-b2c-reference-sso-custom.md) controls interaction with a user after the user has already authenticated. For example, the administrator can control whether the selection of identity providers is displayed, or whether local account details need to be entered again.
 

articles/active-directory-b2c/technicalprofiles.md

@@ -268,7 +268,7 @@ The **UseTechnicalProfileForSessionManagement** element contains the following a
 | ReferenceId | Yes | An identifier of a technical profile already defined in the policy file or parent policy file. |
 
 ### EnabledForUserJourneys
-The **ClaimsProviderSelections** in a user journey defines the list of claims provider selection options and their order. With the **EnabledForUserJourneys** element  you filter, which claims provider is avaible to the user. The **EnabledForUserJourneys** element contains one of the following values:
+The **ClaimsProviderSelections** in a user journey defines the list of claims provider selection options and their order. With the **EnabledForUserJourneys** element  you filter, which claims provider is available to the user. The **EnabledForUserJourneys** element contains one of the following values:
 
 - **Always**, execute the technical profile.
 - **Never**, skip the technical profile. 

articles/active-directory-b2c/userjourneys.md

@@ -45,8 +45,7 @@ The **UserJourney** element contains the following elements:
 
 A user journey is represented as an orchestration sequence that must be followed through for a successful transaction. If any step fails, the transaction fails. These orchestration steps reference both the building blocks and the claims providers allowed in the policy file. Any orchestration step that is responsible to show or render a user experience also has a reference to the corresponding content definition identifier.
 
-Orchestration steps can be conditionaly ecxetuted, based on preconditions defined in the orchestration step element. For examle you can check to perform an orchestration step only if a specific claims exists, or if a claim is equal or not to the specified value. 
-
+Orchestration steps can be conditionaly executed, based on preconditions defined in the orchestration step element. For examle you can check to perform an orchestration step only if a specific claims exists, or if a claim is equal or not to the specified value. 
 
 To specify the ordered list of orchestration steps, an **OrchestrationSteps** element is added as part of the policy. This element is required.
 
@@ -62,7 +61,7 @@ The **OrchestrationStep** element contains the following attributes:
 | --------- | -------- | ----------- |
 | Order | Yes | The order of the orchestration steps. | 
 | Type | Yes | The type of the orchestration step. Possible values: <ul><li>**ClaimsProviderSelection** - Indicates that the orchestration step presents various claims providers to the user to select one.</li><li>**CombinedSignInAndSignUp** - Indicates that the orchestration step presents a combined social provider sign-in and local account sign-up page.</li><li>**ClaimsExchange** - Indicates that the orchestration step exchanges claims with a claims provider.</li><li>**SendClaims** - Indicates that the orchestration step sends the claims to the relying party with a token issued by a claims issuer.</li></ul> | 
-| ContentDefinitionReferenceId | No | The identifier of the [content definition](contentdefinitions.md) associated with this orchestration step. Usually the content definition reference identifier is defined in the self-asserted technical profile. But, there are some cases when Azure AD B2C needs to display something without a technical profile. There are two examples, if the type of the orchestration step is one of follwing: `ClaimsProviderSelection` or  `CombinedSignInAndSignUp`. Azure AD B2C needs to display the identity provider selection without having a technical profile. | 
+| ContentDefinitionReferenceId | No | The identifier of the [content definition](contentdefinitions.md) associated with this orchestration step. Usually the content definition reference identifier is defined in the self-asserted technical profile. But, there are some cases when Azure AD B2C needs to display something without a technical profile. There are two examples, if the type of the orchestration step is one of following: `ClaimsProviderSelection` or  `CombinedSignInAndSignUp`. Azure AD B2C needs to display the identity provider selection without having a technical profile. | 
 | CpimIssuerTechnicalProfileReferenceId | No | The type of the orchestration step is `SendClaims`. This property defines the technical profile identifier of the claims provider that issues the token for the relying party.  If absent, no relying party token is created. |
 
 

articles/active-directory-b2c/validation-technical-profile.md

@@ -27,7 +27,7 @@ A validation technical profile is an ordinary technical profile from any protoco
 }
 ```
 
-Claims that are retuned from a validation technical profile are added back to the claims bag. You can use those claims in the next validation technical profiles.
+Claims that are returned from a validation technical profile are added back to the claims bag. You can use those claims in the next validation technical profiles.
 
 Validation technical profiles are executed in the sequence that they appear in the **ValidationTechnicalProfiles** element. You can configure in a validation technical profile whether the execution of any subsequent validation technical profiles should continue if the validation technical profile raises an error or is successful.  
 
@@ -49,8 +49,8 @@ The **ValidationTechnicalProfile** element contains the following attribute:
 | Attribute | Required | Description |
 | --------- | -------- | ----------- |
 | ReferenceId | Yes | An identifier of a technical profile already defined in the policy or parent policy. |
-|ContinueOnError|No| Indicating whether validation of any subsequent validation technical profiles should continue if this validaiton technical profile raises an error. Posible values: `true` or `false` (default,  processing of further validation profiles will stop and an error returned). 
-|ContinueOnSuccess | No | Indicating whether validation of any subsequent validation profiles should continue if this validation technical profile succeeds. Posible values: `true` or `false`. The default is `true`, meaning that the processing of further validation profiles will continue. |
+|ContinueOnError|No| Indicating whether validation of any subsequent validation technical profiles should continue if this validaiton technical profile raises an error. Possible values: `true` or `false` (default,  processing of further validation profiles will stop and an error returned). 
+|ContinueOnSuccess | No | Indicating whether validation of any subsequent validation profiles should continue if this validation technical profile succeeds. Possible values: `true` or `false`. The default is `true`, meaning that the processing of further validation profiles will continue. |
 
 The **ValidationTechnicalProfile** element contains the following element:
 
@@ -77,8 +77,8 @@ The **Precondition** element contains following elements:
 Following example uses these validation technical profiles: 
 
 1. The first validation technical profile checks user credentials and doesn't continue if an error occurs, such as invalid username or bad password. 
-2. The next validation technical profile, doesn't execute if the userType claim does not exist, or if the value of the userType is `Partner`. The validation technical profile tries to read the user profile from the internal customer database and continue if an error occurs, such as REST API service not avaible, or any internal error.
-3. The last validation technical profile, doesn't execute if the userType claim has not existed, or if the value of the userType is `Customer`. The validation technical profile tries to read the user profile from the internal partner database and continues if an error occurs, such as REST API service not avaible, or any internal error.
+2. The next validation technical profile, doesn't execute if the userType claim does not exist, or if the value of the userType is `Partner`. The validation technical profile tries to read the user profile from the internal customer database and continue if an error occurs, such as REST API service not available, or any internal error.
+3. The last validation technical profile, doesn't execute if the userType claim has not existed, or if the value of the userType is `Customer`. The validation technical profile tries to read the user profile from the internal partner database and continues if an error occurs, such as REST API service not available, or any internal error.
 
 ```XML
 <ValidationTechnicalProfiles>