Merge pull request #177481 from MicrosoftDocs/master

10/25 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -5273,6 +5273,11 @@
       "redirect_url": "/azure/architecture/vdc/networking-virtual-datacenter",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/automation/automation-intro.md",
+      "redirect_url": "/azure/automation/overview",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/automation/automation-quickstart-create-account.md",
       "redirect_url": "/azure/automation/quickstarts/create-account-portal",
@@ -46597,6 +46602,11 @@
       "source_path_from_root": "/articles/app-service/web-sites-integrate-with-vnet.md",
       "redirect_url": "/azure/app-service/overview-vnet-integration",
       "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/mariadb/concepts-performance-recommendations.md",
+      "redirect_url": "/azure/mariadb/overview",
+      "redirect_document_id": false
     }
   ]
 }

articles/active-directory-b2c/aad-sspr-technical-profile.md

@@ -23,7 +23,7 @@ Azure Active Directory B2C (Azure AD B2C) provides support for verifying an emai
 This technical profile:
 
 - Doesn't provide an interface to interact with the user. Instead, the user interface is called from a [self-asserted](self-asserted-technical-profile.md) technical profile, or a [display control](display-controls.md) as a [validation technical profile](validation-technical-profile.md).
-- Uses the Azure AD SSPR service to generate and send a code to an email address, and then verifies the code.  
+- Uses the Azure AD SSPR service to generate and send a code to an email address, and then verifies the code.
 - Validates an email address via a verification code.
 
 [!INCLUDE [b2c-public-preview-feature](../../includes/active-directory-b2c-public-preview.md)]
@@ -38,7 +38,7 @@ Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, C
 
 The following example shows an Azure AD SSPR technical profile:
 
-```XML
+```xml
 <TechnicalProfile Id="AadSspr-SendCode">
   <DisplayName>Send Code</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -57,7 +57,6 @@ The **InputClaims** element contains a list of claims to send to Azure AD SSPR.
 | --------- | -------- | ----------- |
 | emailAddress | Yes | The identifier for the user who owns the email address. The `PartnerClaimType` property of the input claim must be set to `emailAddress`. |
 
-
 The **InputClaimsTransformations** element may contain a collection of **InputClaimsTransformation** elements that are used to modify the input claims or generate new ones before sending to the Azure AD SSPR service.
 
 ### Output claims
@@ -81,12 +80,11 @@ The following metadata can be used to configure the error messages displayed upo
 | UserMessageIfInternalError | No | User error message if the server has encountered an internal error. |
 | UserMessageIfThrottled| No | User error message if a request has been throttled.|
 
-
 ### Example: send an email
 
 The following example shows an Azure AD SSPR technical profile that is used to send a code via email.
 
-```XML
+```xml
 <TechnicalProfile Id="AadSspr-SendCode">
   <DisplayName>Send Code</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -142,7 +140,7 @@ The following metadata can be used to configure the error messages displayed upo
 
 The following example shows an Azure AD SSPR technical profile used to verify the code.
 
-```XML
+```xml
 <TechnicalProfile Id="AadSspr-VerifyCode">
   <DisplayName>Verify Code</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -154,4 +152,4 @@ The following example shows an Azure AD SSPR technical profile used to verify th
     <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress"/>
   </InputClaims>
 </TechnicalProfile>
-```
+```

articles/active-directory-b2c/add-sign-in-policy.md

@@ -22,7 +22,7 @@ zone_pivot_groups: b2c-policy-type
 
 ## Sign-in flow overview
 
-The sign-in policy lets users: 
+The sign-in policy lets users:
 
 * Users can sign in with an Azure AD B2C Local Account
 * Sign-up or sign-in with a social account
@@ -74,7 +74,7 @@ To add sign-in policy:
 
 ## Remove the sign-up link
 
-The **SelfAsserted-LocalAccountSignin-Email** technical profile is a [self-asserted](self-asserted-technical-profile.md), which is invoked during the sign-up or sign-in flow. To remove the sign-up link, set the `setting.showSignupLink` metadata to `false`. Override the SelfAsserted-LocalAccountSignin-Email technical profiles in the extension file. 
+The **SelfAsserted-LocalAccountSignin-Email** technical profile is a [self-asserted](self-asserted-technical-profile.md), which is invoked during the sign-up or sign-in flow. To remove the sign-up link, set the `setting.showSignupLink` metadata to `false`. Override the SelfAsserted-LocalAccountSignin-Email technical profiles in the extension file.
 
 1. Open the extensions file of your policy. For example, _`SocialAndLocalAccounts/`**`TrustFrameworkExtensions.xml`**_.
 1. Find the `ClaimsProviders` element. If the element doesn't exist, add it.
@@ -99,7 +99,7 @@ The **SelfAsserted-LocalAccountSignin-Email** technical profile is a [self-asser
 
 1. Within `<BuildingBlocks>` element, add the following [ContentDefinition](contentdefinitions.md) to reference the version 1.2.0, or newer data URI:
 
-    ```XML
+    ```xml
     <!-- 
     <BuildingBlocks> 
       <ContentDefinitions>-->

articles/active-directory-b2c/conditional-access-technical-profile.md

@@ -30,7 +30,7 @@ Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=
 
 The following example shows a Conditional Access technical profile:
 
-```XML
+```xml
 <TechnicalProfile Id="ConditionalAccessEvaluation">
   <DisplayName>Conditional Access Provider</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -60,7 +60,6 @@ The **InputClaims** element contains a list of claims to send to Conditional Acc
 | IsFederated | Yes |boolean | Indicates whether or not a user signed in with a federated account. The value must be `false`. |
 | IsMfaRegistered | Yes |boolean | Indicates whether the user already enrolled a phone number for multi-factor authentication. |
 
-
 The **InputClaimsTransformations** element may contain a collection of **InputClaimsTransformation** elements that are used to modify the input claims or generate new ones before sending them to the Conditional Access service.
 
 ### Output claims
@@ -78,7 +77,7 @@ The **OutputClaimsTransformations** element may contain a collection of **Output
 
 The following example shows a Conditional Access technical profile that is used to evaluate the sign-in threat.
 
-```XML
+```xml
 <TechnicalProfile Id="ConditionalAccessEvaluation">
   <DisplayName>Conditional Access Provider</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -119,7 +118,6 @@ The **InputClaims** element contains a list of claims to send to Conditional Acc
 | --------- | -------- | ----------- |----------- |
 | ChallengesSatisfied | Yes | stringCollection| The list of satisfied challenges to remediate the identified threat as return from the evaluation mode, challenges claim.|
 
-
 The **InputClaimsTransformations** element may contain a collection of **InputClaimsTransformation** elements that are used to modify the input claims or generate new ones before calling the Conditional Access service.
 
 ### Output claims

articles/active-directory-b2c/conditional-access-user-flow.md

@@ -22,7 +22,7 @@ Automating risk assessment with policy conditions means risky sign-ins are ident
 Azure AD B2C evaluates each sign-in event and ensures that all policy requirements are met before granting the user access. During this **Evaluation** phase, the Conditional Access service evaluates the signals collected by Identity Protection risk detections during sign-in events. The outcome of this evaluation process is a set of claims that indicates whether the sign-in should be granted or blocked. The Azure AD B2C policy uses these claims to act within the user flow. An example is blocking access or challenging the user with a specific remediation like multi-factor authentication (MFA). “Block access” overrides all other settings.
 ::: zone pivot="b2c-custom-policy"
 The following example shows a Conditional Access technical profile that is used to evaluate the sign-in threat.
-```XML
+```xml
 <TechnicalProfile Id="ConditionalAccessEvaluation">
   <DisplayName>Conditional Access Provider</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
@@ -41,7 +41,7 @@ The remediation may also happen through other channels. For example, when the ac
 > To remediate the risk successfully within the journey, make sure the *Remediation* technical profile is called after the *Evaluation* technical profile is executed. If  *Evaluation* is invoked without *Remediation*, the risk state will be *At risk*.
 When the *Evaluation* technical profile recommendation returns `Block`, the call to the *Evaluation* technical profile is not required. The risk state is set to *At risk*.
 The following example shows a Conditional Access technical profile used to remediate the identified threat:
-```XML
+```xml
 <TechnicalProfile Id="ConditionalAccessRemediation">
   <DisplayName>Conditional Access Remediation</DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
@@ -350,7 +350,7 @@ To enable Conditional Access for a user flow, make sure the version supports Con
 ### Configure claim other than phone number to be used for MFA
 In the Conditional Access policy above, the `DoesClaimExist` claim transformation method checks if a claim contains a value, for example if the `strongAuthenticationPhoneNumber` claim contains a phone number. 
 The claims transformation isn't limited to the `strongAuthenticationPhoneNumber` claim. Depending on the scenario, you can use any other claim. In the following XML snippet, the `strongAuthenticationEmailAddress` claim is checked instead. The claim you choose must have a valid value, otherwise the `IsMfaRegistered` claim will be set to `False`. When set to `False`, the Conditional Access policy evaluation returns a `Block` grant type, preventing the user from completing user flow.
-```XML
+```xml
  <ClaimsTransformation Id="IsMfaRegisteredCT" TransformationMethod="DoesClaimExist">
   <InputClaims>
     <InputClaim ClaimTypeReferenceId="strongAuthenticationEmailAddress" TransformationClaimType="inputClaim" />

articles/active-directory-b2c/contentdefinitions.md

@@ -75,7 +75,7 @@ The **ContentDefinition** element contains the following elements:
 
 The **LoadUri** element is used to specify the URL of the HTML5 page for the content definition. The Azure AD B2C [custom policy starter-packs](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack) come with content definitions that use Azure AD B2C HTML pages. The **LoadUri** starts with `~`, which is a relative path to your Azure AD B2C tenant.
 
-```XML
+```xml
 <ContentDefinition Id="api.signuporsignin">
   <LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>
   ...
@@ -84,12 +84,12 @@ The **LoadUri** element is used to specify the URL of the HTML5 page for the con
 
 You can [customize the user interface with HTML templates](customize-ui-with-html.md). When using HTML templates, provide an absolute URL. The following example illustrates a content definition with HTML template:
 
-```XML
+```xml
 <ContentDefinition Id="api.signuporsignin">
   <LoadUri>https://your-storage-account.blob.core.windows.net/your-container/customize-ui.html</LoadUri>
   ...
 </ContentDefinition>
-``` 
+```
 
 ### DataUri
 
@@ -98,8 +98,8 @@ The **DataUri** element is used to specify the page identifier. Azure AD B2C use
 | Page identifier | Description |
 | ----- | ----------- |
 | `globalexception` | Displays an error page when an exception or an error is encountered. |
-| `providerselection`, `idpselection` |	Lists the identity providers that users can choose from during sign-in.  |
-| `unifiedssp` | Displays a form for signing in with a local account that's based on an email address or a user name. This value also provides the “keep me sign-in functionality” and “Forgot your password?” link. |
+| `providerselection`, `idpselection` | Lists the identity providers that users can choose from during sign-in.  |
+| `unifiedssp` | Displays a form for signing in with a local account that's based on an email address or a user name. This value also provides the "keep me sign-in functionality" and "Forgot your password?" link. |
 | `unifiedssd` | Displays a form for signing in with a local account that's based on an email address or a username. This page identifier is deprecated. Use the `unifiedssp` page identifier instead.  |
 | `multifactor` | Verifies phone numbers by using text or voice during sign-up or sign-in. |
 | `selfasserted` | Displays a form to collect data from a user. For example, enables users to create or update their profile. |
@@ -108,7 +108,7 @@ The **DataUri** element is used to specify the page identifier. Azure AD B2C use
 
 You can enable [JavaScript client-side code](javascript-and-page-layout.md) by inserting `contract` between `elements` and the page type. For example, `urn:com:microsoft:aad:b2c:elements:contract:page-name:version`.
 
-The [version](page-layout.md) part of the `DataUri` specifies the package of content containing HTML, CSS, and JavaScript for the user interface elements in your  policy. If you intend to enable JavaScript client-side code, the elements you base your JavaScript on must be immutable. If they're not immutable, any changes could cause unexpected behavior on your user pages. To prevent these issues, enforce the use of a page layout and specify a page layout version. Doing so ensures that all content definitions you’ve based your JavaScript on are immutable. Even if you don’t intend to enable JavaScript, you still need to specify the page layout version for your pages.
+The [version](page-layout.md) part of the `DataUri` specifies the package of content containing HTML, CSS, and JavaScript for the user interface elements in your  policy. If you intend to enable JavaScript client-side code, the elements you base your JavaScript on must be immutable. If they're not immutable, any changes could cause unexpected behavior on your user pages. To prevent these issues, enforce the use of a page layout and specify a page layout version. Doing so ensures that all content definitions you've based your JavaScript on are immutable. Even if you don't intend to enable JavaScript, you still need to specify the page layout version for your pages.
 
 The following example shows the **DataUri** of `selfasserted` version `1.2.0`:
 
@@ -146,7 +146,7 @@ To migrate from the old **DataUri** value (without page contract) to page layout
 | `urn:com:microsoft:aad:b2c:elements:multifactor:1.0.0` | `urn:com:microsoft:aad:b2c:elements:contract:multifactor:1.2.5` |
 | `urn:com:microsoft:aad:b2c:elements:multifactor:1.1.0` | `urn:com:microsoft:aad:b2c:elements:contract:multifactor:1.2.5` |
 
-The following example shows the content definition identifiers and the corresponding **DataUri** with [latest page version](page-layout.md): 
+The following example shows the content definition identifiers and the corresponding **DataUri** with [latest page version](page-layout.md):
 
 ```xml
 <!--