Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into record-calls

Author: ShawnJackson

articles/active-directory-b2c/media/client-credentials-grant-flow/copy-application-secret.png

@@ -645,12 +645,13 @@ In active-active configuration, both instances of the VPN gateway establish S2S
 
 Learn more about [Virtual network gateway - VNetGatewayActiveActive (Enable Active-Active gateways for redundancy)](https://aka.ms/aa_vpnha_learnmore).
 
+<!--
 ### Use HEAD health probes
 
 For health probes, it’s a good practice to use the HEAD method, which reduces the amount of traffic load on your origins.
 
 Learn more about [Front Door - Use HEAD health probes](https://aka.ms/afd-use-health-probes).
-
+-->
 ### Use managed TLS certificates
 
 Front Door management of your TLS certificates reduces your operational costs and helps you to avoid costly outages caused by forgetting to renew a certificate.
@@ -663,6 +664,12 @@ If you only have a single origin, Front Door always routes traffic to that origi
 
 Learn more about [Health probe best practices](https://aka.ms/afd-disable-health-probes).
 
+### Use the same domain name on Azure Front Door and your origin
+
+We recommend that you preserve the original HTTP host name when you use a reverse proxy in front of a web application. Having a different host name at the reverse proxy than the one that's provided to the back-end application server can lead to cookies or redirect URLs that don't work properly. For example, session state can get lost, authentication can fail, or back-end URLs can inadvertently be exposed to end users. You can avoid these problems by preserving the host name of the initial request so that the application server sees the same domain as the web browser.
+
+Learn more about [Use the same domain name on Azure Front Door and your origin](https://aka.ms/afd-same-domain-origin).
+
 ## SAP for Azure
 
 ### Enable the 'concurrent-fencing' parameter in Pacemaker cofiguration in ASCS HA setup in SAP workloads

articles/active-directory-b2c/media/find-help-and-submit-support-ticket/find-help-and-submit-support-ticket-1.png

@@ -19,7 +19,7 @@ It's best to use both cluster-level [auto-upgrades][Autoupgrade] and the node OS
 
 ## Channels for node OS image upgrades
 
-The selected channel determines the timing of upgrades. When making changes to node OS auto-upgrade channels, allow up to 24 hours for the changes to take effect. 
+The selected channel determines the timing of upgrades. When making changes to node OS auto-upgrade channels, allow up to 24 hours for the changes to take effect. Once you change from one channel to another channel, a reimage will be triggered leading to rolling nodes.
 
 > [!NOTE]
 > Node OS image auto-upgrade won't affect the cluster's Kubernetes version. It only works for a cluster in a [supported version][supported].