Merge pull request #226542 from lauradolan/sync

Dirty PR to fix merge conflicts in release-sap-architecture

Author: v-lmcdonald

articles/active-directory-b2c/identity-provider-facebook.md

@@ -53,7 +53,7 @@ If you don't already have a Facebook account, sign up at [https://www.facebook.c
 1. Select **Save Changes**.
 1. From the menu, select the **plus** sign or **Add Product** link next to **PRODUCTS**. Under the **Add Products to Your App**, select **Set up** under **Facebook Login**.
 1. From the menu, select **Facebook Login**, select **Settings**.
-1. In **Valid OAuth redirect URIs**, enter `https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp`. If you use a [custom domain](custom-domain.md), enter `https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp`. Replace `your-tenant-name` with the name of your tenant, and `your-domain-name` with your custom domain. 
+1. In **Valid OAuth redirect URIs**, enter `https://your-tenant-name.b2clogin.com/your-tenant-id/oauth2/authresp`. If you use a [custom domain](custom-domain.md), enter `https://your-domain-name/your-tenant-id/oauth2/authresp`. Replace `your-tenant-id` with the id of your tenant, and `your-domain-name` with your custom domain. 
 1. Select **Save Changes** at the bottom of the page.
 1. To make your Facebook application available to Azure AD B2C, select the Status selector at the top right of the page and turn it **On** to make the Application public, and then select **Switch Mode**. At this point, the Status should change from **Development** to **Live**. For more information, see [Facebook App Development](https://developers.facebook.com/docs/development/release).
 
@@ -135,4 +135,4 @@ If the sign-in process is successful, your browser is redirected to `https://jwt
 - Learn how to [pass Facebook token to your application](idp-pass-through-user-flow.md).
 - Check out the Facebook federation [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#facebook), and how to pass Facebook access token [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#facebook-with-access-token)
 
-::: zone-end
+::: zone-end

articles/active-directory/develop/scenario-mobile-overview.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 05/07/2019
+ms.date: 02/07/2023
 ms.author: henrymbugua
 ms.reviewer: brandwe, jmprieur
 ms.custom: aaddev, identityplatformtop40
@@ -38,7 +38,7 @@ Considerations for mobile apps:
 
 - **User experience is key**: Allow users to see the value of your app before you ask for sign-in. Request only the required permissions.
 - **Support all user configurations**: Many mobile business users must adhere to conditional-access policies and device-compliance policies. Be sure to support these key scenarios.
-- **Implement single sign-on (SSO)**: By using MSAL and Microsoft identity platform, you can enable single sign-on through the device's browser or Microsoft Authenticator (and Intune Company Portal on Android).
+- **Implement single sign-on (SSO)**: By using MSAL and Microsoft identity platform, you can enable SSO through the device's browser or Microsoft Authenticator (and Intune Company Portal on Android).
 - **Implement shared device mode**: Enable your application to be used in shared-device scenarios, for example hospitals, manufacturing, retail, and finance. [Read more about supporting shared device mode](msal-shared-devices.md).
 
 ## Specifics

articles/active-directory/develop/v2-supported-account-types.md

@@ -9,34 +9,34 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 07/14/2020
+ms.date: 02/06/2023
 ms.author: henrymbugua
 ms.reviewer: saeeda, jmprieur
 ms.custom: aaddev, identityplatformtop40
 ---
 
 # Supported account types
 
-This article explains what account types (sometimes called *audiences*) are supported in the Microsoft identity platform applications.
+This article explains what account types (sometimes called _audiences_) are supported in the Microsoft identity platform applications.
 
 <!-- This section can be in an include for many of the scenarios (SPA, web app signing-in users, protecting a web API, Desktop (depending on the flows), Mobile -->
 
 ## Account types in the public cloud
 
 In the Microsoft Azure public cloud, most types of apps can sign in users with any audience:
 
-- If you're writing a line-of-business (LOB) application, you can sign in users in your own organization. Such an application is sometimes called *single-tenant*.
-- If you're an ISV, you can write an application that signs in users:
+- If you're writing a line-of-business (LOB) application, you can sign in users in your own organization. Such an application is sometimes called _single-tenant_.
+- If you're an independent software vendor (ISV), you can write an application that signs in users:
 
-  - In any organization. Such an application is called a *multitenant* web application. You'll sometimes read that it signs in users with their work or school accounts.
+  - In any organization. Such an application is called a _multitenant_ web application. You'll sometimes read that it signs in users with their work or school accounts.
   - With their work or school or personal Microsoft accounts.
   - With only personal Microsoft accounts.
-    
+
 - If you're writing a business-to-consumer application, you can also sign in users with their social identities, by using Azure Active Directory B2C (Azure AD B2C).
 
 ## Account type support in authentication flows
 
-Some account types can't be used with certain authentication flows. For instance, in desktop, UWP, or daemon applications:
+Some account types can't be used with certain authentication flows. For instance, in desktop, Universal Windows Platform (UWP), or daemon applications:
 
 - Daemon applications can be used only with Azure AD organizations. It doesn't make sense to try to use daemon applications to manipulate Microsoft personal accounts. The admin consent will never be granted.
 - You can use the integrated Windows authentication flow only with work or school accounts (in your organization or any organization). Integrated Windows authentication works with domain accounts, and it requires the machines to be domain-joined or Azure AD-joined. This flow doesn't make sense for personal Microsoft accounts.

articles/active-directory/manage-apps/v2-howto-app-gallery-listing.md

@@ -30,6 +30,7 @@ To publish your application in the gallery, you must first read and agree to spe
 - Implement support for *single sign-on* (SSO). To learn more about supported options, see [Plan a single sign-on deployment](plan-sso-deployment.md).
     - For password SSO, make sure that your application supports form authentication so that password vaulting can be used.
 	- For federated applications (OpenID and SAML/WS-Fed), the application must support the [software-as-a-service (SaaS) model](https://azure.microsoft.com/overview/what-is-saas/). Enterprise gallery applications must support multiple user configurations and not any specific user.
+	- For federated applications (OpenID and SAML/WS-Fed), the application can be single **or** multitenanted
 	- For Open ID Connect, the application must be multitenanted and the [Azure AD consent framework](../develop/consent-framework.md) must be correctly implemented.
 - Provisioning is optional yet highly recommended. To learn more about Azure AD SCIM, see [build a SCIM endpoint and configure user provisioning with Azure AD](../app-provisioning/use-scim-to-provision-users-and-groups.md).
 

articles/aks/azure-cni-overlay.md

@@ -7,7 +7,7 @@ ms.service: azure-kubernetes-service
 ms.subservice: aks-networking
 ms.topic: how-to
 ms.custom: references_regions
-ms.date: 02/03/2023
+ms.date: 02/06/2023
 ---
 
 # Configure Azure CNI Overlay networking in Azure Kubernetes Service (AKS)
@@ -17,12 +17,25 @@ The traditional [Azure Container Networking Interface (CNI)](./configure-azure-c
 With Azure CNI Overlay, the cluster nodes are deployed into an Azure Virtual Network (VNet) subnet, whereas pods are assigned IP addresses from a private CIDR logically different from the VNet hosting the nodes. Pod and node traffic within the cluster use an overlay network, and Network Address Translation (using the node's IP address) is used to reach resources outside the cluster. This solution saves a significant amount of VNet IP addresses and enables you to seamlessly scale your cluster to very large sizes. An added advantage is that the private CIDR can be reused in different AKS clusters, truly extending the IP space available for containerized applications in AKS.
 
 > [!NOTE]
-> Azure CNI Overlay is currently available only in the following regions:
-> - North Central US
-> - West Central US
-> - East US
-> - UK South
-> - Australia East
+> Azure CNI Overlay is currently **_unavailable_** in the following regions:
+> - East US 2
+> - Central US
+> - South Central US
+> - West US
+> - West US 2
+> - West US 3
+> - Southeast Asia
+> - Sweden Central
+> - France Central
+> - Norway East
+> - Switzerland North
+> - Qatar Central
+> - Jio India West
+> - Jio India Central
+> - UAE Central
+> - UAE North
+> - Brazil Southeast
+
 
 ## Overview of overlay networking
 
@@ -42,13 +55,13 @@ Ingress connectivity to the cluster can be achieved using an ingress controller
 
 Like Azure CNI Overlay, Kubenet assigns IP addresses to pods from an address space logically different from the VNet but has scaling and other limitations. The below table provides a detailed comparison between Kubenet and Azure CNI Overlay. If you do not want to assign VNet IP addresses to pods due to IP shortage, then Azure CNI Overlay is the recommended solution.
 
-| Area | Azure CNI Overlay | Kubenet |
-| -- | -- | -- |
-| Cluster scale | 1000 nodes and 250 pods/node | 400 nodes and 250 pods/node |
-| Network configuration | Simple - no additional configuration required for pod networking | Complex - requires route tables and UDRs on cluster subnet for pod networking |
-| Pod connectivity performance | Performance on par with VMs in a VNet | Additional hop adds minor latency |
-| Kubernetes Network Policies | Azure Network Policies, Calico | Calico |
-| OS platforms supported | Linux and Windows | Linux only |
+| Area                         | Azure CNI Overlay                                                | Kubenet                                                                       |
+|------------------------------|------------------------------------------------------------------|-------------------------------------------------------------------------------|
+| Cluster scale                | 1000 nodes and 250 pods/node                                     | 400 nodes and 250 pods/node                                                   |
+| Network configuration        | Simple - no additional configuration required for pod networking | Complex - requires route tables and UDRs on cluster subnet for pod networking |
+| Pod connectivity performance | Performance on par with VMs in a VNet                            | Additional hop adds minor latency                                             |
+| Kubernetes Network Policies  | Azure Network Policies, Calico                                   | Calico                                                                        |
+| OS platforms supported       | Linux and Windows                                                | Linux only                                                                    |
 
 ## IP address planning
 

articles/aks/image-cleaner.md

@@ -5,7 +5,7 @@ ms.author: nickoman
 author: nickomang
 services: container-service
 ms.topic: article
-ms.date: 02/03/2023
+ms.date: 02/07/2023
 ---
 
 # Use Image Cleaner to clean up stale images on your Azure Kubernetes Service cluster (preview)
@@ -166,7 +166,7 @@ az aks update -g MyResourceGroup -n MyManagedCluster
 
 ## Logging
 
-Deletion image logs are stored in `eraser-aks-nodepool-xxx` pods for manually deleted images, and in `eraser-collector-xxx` pods for automatically deleted images.
+Deletion image logs are stored in `eraser-aks-nodepool-xxx` pods for manually deleted images, and in `collector-aks-nodes-xxx` pods for automatically deleted images.
 
 You can view these logs by running `kubectl logs <pod name> -n kubesystem`. However, this command may return only the most recent logs, since older logs are routinely deleted. To view all logs, follow these steps to enable the [Azure Monitor add-on](./monitor-aks.md) and use the Container Insights pod log table.
 
@@ -193,7 +193,7 @@ You can view these logs by running `kubectl logs <pod name> -n kubesystem`. Howe
 
 1. In the Azure portal, search for the workspace resource ID, then select **Logs**.
 
-1. Copy this query into the table, replacing `name` with either `eraser-aks-nodepool-xxx` (for manual mode) or `eraser-collector-xxx` (for automatic mode).
+1. Copy this query into the table, replacing `name` with either `eraser-aks-nodepool-xxx` (for manual mode) or `collector-aks-nodes-xxx` (for automatic mode).
 
    ```kusto
       let startTimestamp = ago(1h);

articles/api-management/api-management-gateways-overview.md

@@ -67,16 +67,17 @@ The following table compares features available in the managed gateway versus th
 | [Custom domains](configure-custom-domain.md) | ✔️ | ✔️ | ✔️ |
 | [Built-in cache](api-management-howto-cache.md) | ✔️ |  ❌ | ❌ |
 | [External Redis-compatible cache](api-management-howto-cache-external.md) | ✔️ | ✔️ | ✔️ |
-| [Virtual network injection](virtual-network-concepts.md)  |  Developer, Premium |  ❌ | ✔️<sup>1</sup> |
+| [Virtual network injection](virtual-network-concepts.md)  |  Developer, Premium |  ❌ | ✔️<sup>1,2</sup> |
 | [Private endpoints](private-endpoint.md)  |  ✔️ |  ❌ | ❌ |
 | [Availability zones](zone-redundancy.md)  |  Premium |  ❌ | ✔️<sup>1</sup> |
 | [Multi-region deployment](api-management-howto-deploy-multi-region.md) |  Premium |  ❌ | ✔️<sup>1</sup> |
-| [CA root certificates](api-management-howto-ca-certificates.md) for certificate validation |  ✔️ |  ❌ | ✔️<sup>2</sup> |  
+| [CA root certificates](api-management-howto-ca-certificates.md) for certificate validation |  ✔️ |  ❌ | ✔️<sup>3</sup> |  
 | [Managed domain certificates](configure-custom-domain.md?tabs=managed#domain-certificate-options) |  ✔️ | ✔️ | ❌ |
 | [TLS settings](api-management-howto-manage-protocols-ciphers.md) |  ✔️ | ✔️ | ✔️ |
 
 <sup>1</sup> Depends on how the gateway is deployed, but is the responsibility of the customer.<br/>
-<sup>2</sup> Requires configuration of local CA certificates.<br/>
+<sup>2</sup> Connectivity to the self-hosted gateway v2 [configuration endpoint](self-hosted-gateway-overview.md#fqdn-dependencies) requires DNS resolution of the default endpoint hostname; custom domain name is currently not supported.<br/>
+<sup>3</sup> Requires configuration of local CA certificates.<br/>
 
 ### Backend APIs
 

articles/api-management/api-management-using-with-internal-vnet.md

@@ -20,7 +20,8 @@ This article explains how to set up VNet connectivity for your API Management in
 * Git 
 
 > [!NOTE]
-> None of the API Management endpoints are registered on the public DNS. The endpoints remain inaccessible until you [configure DNS](#dns-configuration) for the VNet.
+> * None of the API Management endpoints are registered on the public DNS. The endpoints remain inaccessible until you [configure DNS](#dns-configuration) for the VNet.
+> * To use the self-hosted gateway in this mode, also enable private connectivity to the self-hosted gateway [configuration endpoint](self-hosted-gateway-overview.md#fqdn-dependencies). Currently, API Management doesn't enable configuring a custom domain name for the v2 endpoint.
 
 Use API Management in internal mode to:
 

articles/api-management/how-to-self-hosted-gateway-on-kubernetes-in-production.md

@@ -95,7 +95,7 @@ We recommend setting resource requests to two cores and 2 GiB as a starting poin
 
 ## Custom domain names and SSL certificates
 
-If you use custom domain names for the API Management endpoints, especially if you use a custom domain name for the Management endpoint, you might need to update the value of `config.service.endpoint` in the **\<gateway-name\>.yaml** file to replace the default domain name with the custom domain name. Make sure that the Management endpoint can be accessed from the pod of the self-hosted gateway in the Kubernetes cluster.
+If you use custom domain names for the [API Management endpoints](self-hosted-gateway-overview.md#fqdn-dependencies), especially if you use a custom domain name for the Management endpoint, you might need to update the value of `config.service.endpoint` in the **\<gateway-name\>.yaml** file to replace the default domain name with the custom domain name. Make sure that the Management endpoint can be accessed from the pod of the self-hosted gateway in the Kubernetes cluster.
 
 In this scenario, if the SSL certificate that's used by the Management endpoint isn't signed by a well-known CA certificate, you must make sure that the CA certificate is trusted by the pod of the self-hosted gateway.