Syncing with main. Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into work-mmr-limits

Author: Heidilohr

articles/active-directory/hybrid/migrate-from-federation-to-cloud-authentication.md

@@ -94,7 +94,7 @@ Modern authentication clients (Office 2016 and Office 2013, iOS, and Android app
 
 To plan for rollback, use the [documented current federation settings](#document-current-federation-settings) and check the [federation design and deployment documentation](/windows-server/identity/ad-fs/deployment/windows-server-2012-r2-ad-fs-deployment-guide). 
 
-The rollback process should include converting managed domains to federated domains by using the [Convert-MSOLDomainToFederated](/powershell/module/msonline/convert-msoldomaintofederated) cmdlet. If necessary, configuring extra claims rules.
+The rollback process should include converting managed domains to federated domains by using the [Convert-MSOLDomainToFederated](/powershell/module/microsoft.graph.identity.directorymanagement/new-mgdomainfederationconfiguration?view=graph-powershell-1.0&preserve-view=true) cmdlet. If necessary, configuring extra claims rules.
 
 ## Migration considerations 
 
@@ -136,7 +136,7 @@ The following table explains the behavior for each option. For more information,
 | rejectMfaByFederatedIdp | Azure AD always performs MFA and rejects MFA that federated identity provider performs. |
 
 >[!NOTE]
-> The **federatedIdpMfaBehavior** setting is an evolved version of the **SupportsMfa** property of the [Set-MsolDomainFederationSettings MSOnline v1 PowerShell cmdlet](/powershell/module/msonline/set-msoldomainfederationsettings). 
+> The **federatedIdpMfaBehavior** setting is an evolved version of the **SupportsMfa** property of the [Set-MsolDomainFederationSettings MSOnline v1 PowerShell cmdlet](/powershell/module/microsoft.graph.identity.directorymanagement/new-mgdomainfederationconfiguration?view=graph-powershell-1.0&preserve-view=true). 
 
 For domains that have already set the **SupportsMfa** property, these rules determine how **federatedIdpMfaBehavior** and **SupportsMfa** work together:
 
@@ -251,9 +251,11 @@ Sign in to the [Azure portal](https://portal.azure.com/), browse to **Azure Acti
 
 4. On the **User sign-in** page:
 
-    - If you select **Pass-through authentication** option button, check **Enable single sign-on**, and then select **Next**.
+    - If you select **Pass-through authentication** option button, and if SSO is needed for Windows 7 and 8.1 devices, check **Enable single sign-on**, and then select **Next**.
 
-    -  If you select the **Password hash synchronization** option button, make sure to select the **Do not convert user accounts** check box. The option is deprecated. Check **Enable single sign-on**, and then select **Next**.
+    - If you select the **Password hash synchronization** option button, make sure to select the **Do not convert user accounts** check box. The option is deprecated. If SSO is needed for Windows 7 and 8.1 devices, check **Enable single sign-on**, and then select **Next**. 
+
+      Learn more: [Enable seamless SSO using PowerShell](how-to-connect-staged-rollout.md#pre-work-for-seamless-sso). 
 
       ![Check enable single sign-on on User sign-in page](media/deploy-cloud-user-authentication/user-sign-in.png)
 
@@ -268,6 +270,8 @@ Sign in to the [Azure portal](https://portal.azure.com/), browse to **Azure Acti
 
     The domain administrator credentials aren't stored in Azure AD Connect or Azure AD and get discarded when the process successfully finishes. They are  used to turn ON this feature.
 
+    Learn more: [Seamless SSO technical deep dive.](how-to-connect-sso-how-it-works.md) 
+
 6. On the **Ready to configure** page, make sure that the **Start the synchronization process when configuration completes** check box is selected. Then, select **Configure**.
 
     ![Ready to configure page](media/deploy-cloud-user-authentication/ready-to-configure.png)

articles/active-directory/reports-monitoring/reference-azure-ad-sla-performance.md

@@ -48,7 +48,7 @@ The SLA attainment is truncated at three places after the decimal. Numbers are n
 | ---       | ---     | ---     | ---     |
 | January   |         | 99.998% | 99.998% |
 | February  | 99.999% | 99.999% | 99.999% |
-| March     | 99.568% | 99.998% | |
+| March     | 99.568% | 99.998% | 99.999% |
 | April     | 99.999% | 99.999% | |
 | May       | 99.999% | 99.999% | |
 | June      | 99.999% | 99.999% | |

articles/aks/azure-cni-overlay.md

@@ -43,7 +43,7 @@ Like Azure CNI Overlay, Kubenet assigns IP addresses to pods from an address spa
 
 ## IP address planning
 
-- **Cluster Nodes**: Cluster nodes go into a subnet in your VNet, so verify you have a subnet large enough to account for future scale. A simple `/24` subnet can host up to 251 nodes (the first three IP addresses in a subnet are reserved for management operations).
+- **Cluster Nodes**: Cluster nodes go into a subnet in your VNet, so verify you have a subnet large enough to account for future scale. Cluster can't scale to another subnet but you can add new nodepools in another subnet within the same VNet for expansion. A simple `/24` subnet can host up to 251 nodes (the first three IP addresses in a subnet are reserved for management operations).
 
 - **Pods**: The overlay solution assigns a `/24` address space for pods on every node from the private CIDR that you specify during cluster creation. The `/24` size is fixed and can't be increased or decreased. You can run up to 250 pods on a node. When planning the pod address space, ensure that the private CIDR is large enough to provide `/24` address spaces for new nodes to support future cluster expansion.
 

articles/app-service/environment/migrate.md

@@ -3,7 +3,7 @@ title: Migrate to App Service Environment v3 by using the migration feature
 description: Overview of the migration feature for migration to App Service Environment v3
 author: seligj95
 ms.topic: article
-ms.date: 03/20/2023
+ms.date: 04/07/2023
 ms.author: jordanselig
 ms.custom: references_regions
 ---
@@ -90,6 +90,7 @@ If your App Service Environment doesn't pass the validation checks or you try to
 |`<ZoneRedundant><DedicatedHosts><ASEv3/ASE>` is not available in this location. |This error appears if you're trying to migrate an App Service Environment in a region that doesn't support one of your requested features. |Migrate using one of the [manual migration options](migration-alternatives.md) if you want to migrate immediately. Otherwise, wait for the migration feature to support this App Service Environment configuration.  |
 |Migrate cannot be called on this ASE until the active upgrade has finished.    |App Service Environments can't be migrated during platform upgrades. You can set your [upgrade preference](how-to-upgrade-preference.md) from the Azure portal. In some cases, an upgrade is initiated when visiting the migration page if your App Service Environment isn't on the current build.  |Wait until the upgrade finishes and then migrate.   |
 |App Service Environment management operation in progress.    |Your App Service Environment is undergoing a management operation. These operations can include activities such as deployments or upgrades. Migration is blocked until these operations are complete.   |You can migrate once these operations are complete.  |
+|Migrate is not available for this subscription|Support needs to be engaged for migrating this App Service Environment.|Open a support case to engage support to resolve your issue.|
 
 ## Overview of the migration process using the migration feature
 

articles/application-gateway/media/tutorial-protect-application-gateway/enable-ddos-vnet.png

@@ -1,10 +1,10 @@
 ---
 title: Hosting multiple sites on Azure Application Gateway
-description: This article provides an overview of the Azure Application Gateway multi-site support.
+description: This article provides an overview of the Azure Application Gateway multi-site support. Examples are provided of rule priority and the order of evaluation for rules applied to incoming requests. Conditions and limitations for using wildcard rules are described.
 services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
-ms.date: 10/03/2022
+ms.date: 04/07/2023
 ms.author: greglin
 ms.topic: conceptual
 ---
@@ -18,34 +18,32 @@ You can also define wildcard host names in a multi-site listener and up to 5 hos
 :::image type="content" source="./media/multiple-site-overview/multisite.png" alt-text="Multi-site Application Gateway":::
 
 > [!IMPORTANT]
-> Rules are processed in the order they are listed in the portal for the v1 SKU. For v2 SKU use [rule priority](#request-routing-rules-evaluation-order) to specify the processing order. It is highly recommended to configure multi-site listeners first prior to configuring a basic listener.  This will ensure that traffic gets routed to the right back end. If a basic listener is listed first and matches an incoming request, it gets processed by that listener.
+> Rules are processed in the order they are listed in the portal for the v1 SKU. For v2 SKU use [rule priority](#request-routing-rules-evaluation-order) to specify the processing order. It is highly recommended to configure multi-site listeners first prior to configuring a basic listener.  This ensures that traffic gets routed to the right back end. If a basic listener is listed first and matches an incoming request, it gets processed by that listener.
 
 Requests for `http://contoso.com` are routed to ContosoServerPool, and `http://fabrikam.com` are routed to FabrikamServerPool.
 
 Similarly, you can host multiple subdomains of the same parent domain on the same application gateway deployment. For example, you can  host `http://blog.contoso.com` and `http://app.contoso.com` on a single application gateway deployment.
 
 ## Request Routing rules evaluation order
 
-When you use multi-site listeners to ensure that the client traffic is routed to the accurate backend, it's important to have the request routing rules be present in the correct order.
-For example, if you have 2 listeners with associated Host name as `*.contoso.com` and `shop.contoso.com` respectively, the listener with the `shop.contoso.com` Host name would have to be processed before the listener with `*.contoso.com`. If the listener with `*.contoso.com` is processed first, then no client traffic would be received by the more specific `shop.contoso.com` listener.
+When you use multi-site listeners to ensure that the client traffic is routed to the accurate backend, it's important that the request routing rules are present in the correct order.
+For example, if you have 2 listeners with associated host names of `*.contoso.com` and `shop.contoso.com`, the listener with the `shop.contoso.com` host name must be processed before the listener with `*.contoso.com`. If the listener with `*.contoso.com` is processed first, then no client traffic is received by the more specific `shop.contoso.com` listener.
 
-This ordering can be established by providing a 'Priority' field value to the request routing rules associated with the listeners. You can specify an integer value from 1 to 20000 with 1 being the highest priority and 20000 being the lowest priority. In case the incoming client traffic matches with multiple listeners, the request routing rule with highest priority will be used for serving the request. Each request routing rule needs to have a unique priority value.
+The ordering of rules can be established by providing a **Priority** field value to the request routing rules associated with the listeners. You can specify an integer value from 1 to 20000 with 1 being the highest priority and 20000 being the lowest priority. If incoming client traffic matches with multiple listeners, the request routing rule with highest priority is used to serve the request. Each request routing rule must have a unique priority value.
 
 The priority field only impacts the order of evaluation of a request routing rule, this wont change the order of evaluation of path based rules within a `PathBasedRouting` request routing rule.
 
->[!NOTE]
->If you wish to use rule priority, you will have to specify rule priority field values for all the existing request routing rules. Once the rule priority field is in use, any new routing rule that is created would also need to have a rule priority field value as part of its config.
-Starting with API version 2021-08-01 rule priority field would be a mandatory field as part of the request routing rules.
-From this API version, rule priority field values would be auto-populated for existing request routing rules based on current ordering of evaluation as part of the first PUT call. Any future updates to request routing rules would need to have the rule priority field provided as part of the configuration.
+> [!NOTE]
+> To use rule priority, you must specify rule priority field values for all the existing request routing rules. Once the rule priority field is in use, any new routing rule that is created must have a rule priority field value as part of its configuration. 
 
 > [!IMPORTANT]
-> Rule priority field values for existing request routing rules based on current order would be automatically populated if any configuration updates are applied using API version 2021-08-01 and above, portal, Azure PowerShell and Azure CLI. Any future updates to request routing rules would need to have the rule priority field provided as part of the configuration.  
+>  Starting with API version 2021-08-01, the rule priority field is a mandatory field in the request routing rules. Rule priority field values for existing request routing rules, based on current ordering of evaluation as part of the first PUT call, are automatically populated if any configuration updates are applied using API version 2021-08-01 and above, portal, Azure PowerShell and Azure CLI. Future updates to request routing rules must have the rule priority field provided as part of the configuration.
 
 ## Wildcard host names in listener
 
 Application Gateway allows host-based routing using multi-site HTTP(S) listener. Now, you can use wildcard characters like asterisk (*) and question mark (?) in the host name, and up to 5 host names per multi-site HTTP(S) listener. For example, `*.contoso.com`.
 
-Using a wildcard character in the host name, you can match multiple host names in a single listener. For example, `*.contoso.com` can match with `ecom.contoso.com`, `b2b.contoso.com` and `customer1.b2b.contoso.com` and so on. Using an array of host names, you can configure more than one host name for a listener, to route requests to a backend pool. For example, a listener can contain `contoso.com, fabrikam.com` which will accept requests for both the host names.
+Using a wildcard character in the host name, you can match multiple host names in a single listener. For example, `*.contoso.com` can match with `ecom.contoso.com`, `b2b.contoso.com` and `customer1.b2b.contoso.com` and so on. Using an array of host names, you can configure more than one host name for a listener, to route requests to a backend pool. For example, a listener can contain `contoso.com, fabrikam.com` which accepts requests for both the host names.
 
 :::image type="content" source="./media/multiple-site-overview/wildcard-listener-diag.png" alt-text="Wildcard Listener":::
 
@@ -86,7 +84,7 @@ In the Azure portal, under the multi-site listener, you must choose the **Multip
     * If it's a wildcard hostname like *.contoso.com, you must upload a wildcard certificate with CN like *.contoso.com
     * If multiple host names are mentioned in the same listener, you must upload a SAN certificate (Subject Alternative Names) with the CNs matching the host names mentioned.
 * You can't use a regular expression to mention the host name. You can only use wildcard characters like asterisk (*) and question mark (?) to form the host name pattern.
-* For backend health check, you can't associate multiple [custom probes](application-gateway-probe-overview.md) per HTTP settings. Instead, you can probe one of the websites at the backend or use "127.0.0.1" to probe the localhost of the backend server. However, when you're using wildcard or multiple host names in a listener, the requests for all the specified domain patterns will be routed to the backend pool depending on the rule type (basic or path-based).
+* For backend health check, you can't associate multiple [custom probes](application-gateway-probe-overview.md) per HTTP settings. Instead, you can probe one of the websites at the backend or use "127.0.0.1" to probe the localhost of the backend server. However, when you're using wildcard or multiple host names in a listener, the requests for all the specified domain patterns are routed to the backend pool depending on the rule type (basic or path-based).
 * The "hostname" property takes one string as input, where you can mention only one non-wildcard domain name. The "hostnames" property takes an array of strings as input, where you can mention up to 5 wildcard domain names. Both these properties can't be used at once.
 
 See [create multi-site using Azure PowerShell](tutorial-multiple-sites-powershell.md) or [using Azure CLI](tutorial-multiple-sites-cli.md) for the step-by-step guide on how to configure wildcard host names in a multi-site listener.
@@ -103,7 +101,7 @@ There are three common mechanisms for enabling multiple site hosting on the same
 
 Currently Application Gateway supports a single public IP address where it listens for traffic. So multiple applications, each with its own IP address is currently not supported.
 
-Application Gateway supports multiple applications each listening on different ports, but this scenario requires the applications to accept traffic on non-standard ports.
+Application Gateway supports multiple applications each listening on different ports, but this scenario requires the applications to accept traffic on nonstandard ports.
 
 Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. The sites hosted on application gateway can also support TLS offload with Server Name Indication (SNI) TLS extension. This scenario means that the client browser and backend web farm must support HTTP/1.1 and TLS extension as defined in RFC 6066.