Merge pull request #256441 from MicrosoftDocs/main

10/27/2023 AM Publish

Author: Taojunshen

articles/active-directory-b2c/custom-domain.md

@@ -5,7 +5,6 @@ description: Learn how to enable custom domains in your redirect URLs for Azure
 services: active-directory-b2c
 author: kengaderdus
 manager: CelesteDG
-
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
@@ -399,6 +398,9 @@ Copy the URL, change the domain name manually, and then paste it back to your br
 
 Azure Front Door passes the user's original IP address. It's the IP address that you'll see in the audit reporting or your custom policy.
 
+> [!IMPORTANT]
+> If the client sends an `x-forwarded-for` header to Azure Front Door, Azure AD B2C will use the originator's `x-forwarded-for` as the user's IP address for [Conditional Access Evaluation](./conditional-access-identity-protection-overview.md) and the `{Context:IPAddress}` [claims resolver](./claim-resolver-overview.md).
+
 ### Can I use a third-party Web Application Firewall (WAF) with B2C?
 
 Yes, Azure AD B2C supports BYO-WAF (Bring Your Own Web Application Firewall). However, you must test WAF to ensure that it doesn't block or alert legitimate requests to Azure AD B2C user flows or custom policies. Learn how to configure [Akamai WAF](partner-akamai.md) and [Cloudflare WAF](partner-cloudflare.md) with Azure AD B2C.

articles/active-directory-b2c/index.yml

@@ -116,12 +116,6 @@ conceptualContent:
             url: session-behavior.md
             itemType: how-to-guide
 
-          - text: Authenticate users in a Node.js web app(Quick course)
-            url: /training/modules/authenticate-users-node-web-app-use-azure-active-directory-b2c/
-            itemType: learn
-          # - text: 'Quickstart: Single-page app'
-            # url: configure-authentication-sample-spa-app.md
-            # itemType: quickstart
       ## CARD 4 ######################
     - title: 'Authorize: Call and secure your APIs'
       links:

articles/ai-services/speech-service/regions.md

@@ -2,14 +2,13 @@
 title: Regions - Speech service
 titleSuffix: Azure AI services
 description: A list of available regions and endpoints for the Speech service, including speech to text, text to speech, and speech translation.
-services: cognitive-services
 author: eric-urban
 manager: nitinme
 ms.service: azure-ai-speech
 ms.topic: conceptual
-ms.date: 09/16/2022
+ms.date: 10/27/2023
 ms.author: eur
-ms.custom: references_regions, ignite-fall-2021
+ms.custom: references_regions
 ---
 
 # Speech service supported regions
@@ -45,6 +44,7 @@ The following regions are supported for Speech service features such as speech t
 | Europe | France Central | `francecentral` |
 | Europe | Germany West Central | `germanywestcentral` |
 | Europe | Norway East | `norwayeast` |
+| Europe | Sweden Central | `swedentcentral` |
 | Europe | Switzerland North | `switzerlandnorth` <sup>6</sup>|
 | Europe | Switzerland West | `switzerlandwest` |
 | Europe | UK South | `uksouth` <sup>1,2,3,4,7</sup>|

articles/app-service/configure-common.md

@@ -510,6 +510,9 @@ Set-AzWebApp $webapp
 
 By default, App Service starts your app from the root directory of your app code. But certain web frameworks don't start in the root directory. For example, [Laravel](https://laravel.com/) starts in the `public` subdirectory. Such an app would be accessible at `http://contoso.com/public`, for example, but you typically want to direct `http://contoso.com` to the `public` directory instead. If your app's startup file is in a different folder, or if your repository has more than one application, you can edit or add virtual applications and directories.
 
+> [!IMPORTANT]
+> Virtual directory to a physical path feature is only available on Windows apps.
+
 # [Azure portal](#tab/portal)
 
 1. In the [Azure portal], search for and select **App Services**, and then select your app. 

articles/azure-monitor/app/azure-web-apps-nodejs.md

@@ -17,8 +17,11 @@ Monitoring of your Node.js web applications running on [Azure App Services](../.
 The easiest way to enable application monitoring for Node.js applications running on Azure App Services is through Azure portal.
 Turning on application monitoring in Azure portal will automatically instrument your application with Application Insights, and doesn't require any code changes.
 
+>[!NOTE]
+> You can configure the automatically attached agent using the APPLICATIONINSIGHTS_CONFIGURATION_CONTENT environment variable in the App Service Environment variable blade. For details on the configuration options that can be passed via this environment variable, see [Node.js Configuration](https://github.com/microsoft/ApplicationInsights-node.js#Configuration).
+
 > [!NOTE]
-> If both autoinstrumentation monitoring and manual SDK-based instrumentation are detected, only the manual instrumentation settings will be honored. This is to prevent duplicate data from being sent. To learn more about this, check out the [troubleshooting section](#troubleshooting) in this article.
+> If both automatic instrumentation and manual SDK-based instrumentation are detected, only the manual instrumentation settings are honored. This is to prevent duplicate data from being sent. For more information, see the [troubleshooting section](#troubleshooting) in this article.
 
 ### Autoinstrumentation through Azure portal
 
@@ -106,7 +109,6 @@ Below is our step-by-step troubleshooting guide for extension/agent based monito
 
     If `SDKPresent` is true this indicates that the extension detected that some aspect of the SDK is already present in the Application, and will back-off.
 
-
 # [Linux](#tab/linux)
 
 1. Check that `ApplicationInsightsAgent_EXTENSION_VERSION` app setting is set to a value of "~3".
@@ -134,6 +136,8 @@ Below is our step-by-step troubleshooting guide for extension/agent based monito
     ```
 
     If `SDKPresent` is true this indicates that the extension detected that some aspect of the SDK is already present in the Application, and will back-off.
+
+
 ---
 
 [!INCLUDE [azure-web-apps-troubleshoot](../../../includes/azure-monitor-app-insights-azure-web-apps-troubleshoot.md)]
@@ -152,3 +156,4 @@ For the latest updates and bug fixes, [consult the release notes](web-app-extens
 * [Receive alert notifications](../alerts/alerts-overview.md) whenever operational events happen or metrics cross a threshold.
 * Use [Application Insights for JavaScript apps and web pages](javascript.md) to get client telemetry from the browsers that visit a web page.
 * [Availability overview](availability-overview.md)
+

articles/cosmos-db/continuous-backup-restore-introduction.md

@@ -132,7 +132,7 @@ Currently the point in time restore functionality has the following limitations:
 
 * Multi-regions write accounts aren't supported.
 
-* Currently Azure Synapse Link can be enabled, in preview, in continuous backup database accounts. The opposite situation isn't supported yet, it is not possible to turn on continuous backup in Synapse Link enabled database accounts. And analytical store isn't included in backups. For more information about backup and analytical store, see [analytical store backup](analytical-store-introduction.md#backup).
+* Currently Azure Synapse Link can be enabled in continuous backup database accounts. But the opposite situation isn't supported yet, it is not possible to turn on continuous backup in Synapse Link enabled database accounts. And analytical store isn't included in backups. For more information about backup and analytical store, see [analytical store backup](analytical-store-introduction.md#backup).
 
 * The restored account is created in the same region where your source account exists. You can't restore an account into a region where the source account didn't exist.
 

articles/cosmos-db/postgresql/TOC.yml

@@ -62,6 +62,9 @@
         - name: Design a real-time dashboard
           href: tutorial-design-database-realtime.md
           displayName: tutorial, real-time
+        - name: Design for microservices
+          href: tutorial-design-database-microservices.md
+          displayName: tutorial, microservices
     - name: Administer
       items:
         - name: Set up private access
@@ -71,6 +74,8 @@
   items:
     - name: Clusters
       href: concepts-cluster.md
+    - name: Sharding models
+      href: concepts-sharding-models.md
     - name: Distributed data
       items:
         - name: Nodes and tables

articles/cosmos-db/postgresql/concepts-colocation.md

@@ -7,7 +7,7 @@ ms.service: cosmos-db
 ms.subservice: postgresql
 ms.custom: ignite-2022
 ms.topic: conceptual
-ms.date: 05/06/2019
+ms.date: 10/01/2023
 ---
 
 # Table colocation in Azure Cosmos DB for PostgreSQL
@@ -18,13 +18,13 @@ Colocation means storing related information together on the same nodes. Queries
 
 ## Data colocation for hash-distributed tables
 
-In Azure Cosmos DB for PostgreSQL, a row is stored in a shard if the hash of the value in the distribution column falls within the shard's hash range. Shards with the same hash range are always placed on the same node. Rows with equal distribution column values are always on the same node across tables.
+In Azure Cosmos DB for PostgreSQL, a row is stored in a shard if the hash of the value in the distribution column falls within the shard's hash range. Shards with the same hash range are always placed on the same node. Rows with equal distribution column values are always on the same node across tables. The concept of hash-distributed tables is also known as [row-based sharding](concepts-sharding-models.md#row-based-sharding). In [schema-based sharding](concepts-sharding-models.md#schema-based-sharding), tables within a distributed schema are always colocated.
 
 :::image type="content" source="media/concepts-colocation/colocation-shards.png" alt-text="Diagram shows shards with the same hash range placed on the same node for events shards and page shards." border="false":::
 
 ## A practical example of colocation
 
-Consider the following tables that might be part of a multi-tenant web
+Consider the following tables that might be part of a multitenant web
 analytics SaaS:
 
 ```sql
@@ -153,4 +153,4 @@ In some cases, queries and table schemas must be changed to include the tenant I
 
 ## Next steps
 
-- See how tenant data is colocated in the [multi-tenant tutorial](tutorial-design-database-multi-tenant.md).
+- See how tenant data is colocated in the [multitenant tutorial](tutorial-design-database-multi-tenant.md).

articles/cosmos-db/postgresql/concepts-distributed-data.md

@@ -6,7 +6,7 @@ author: jonels-msft
 ms.service: cosmos-db
 ms.subservice: postgresql
 ms.topic: conceptual
-ms.date: 10/26/2022
+ms.date: 09/29/2023
 ---
 
 # Nodes and tables in Azure Cosmos DB for PostgreSQL
@@ -25,23 +25,22 @@ allows the database to scale by adding more nodes to the cluster.
 
 Every cluster has a coordinator node and multiple workers. Applications
 send their queries to the coordinator node, which relays it to the relevant
-workers and accumulates their results. Applications are not able to connect
-directly to workers.
+workers and accumulates their results.
 
-Azure Cosmos DB for PostgreSQL allows the database administrator to *distribute* tables,
-storing different rows on different worker nodes. Distributed tables are the
-key to Azure Cosmos DB for PostgreSQL performance. Failing to distribute tables leaves them entirely
-on the coordinator node and cannot take advantage of cross-machine parallelism.
+Azure Cosmos DB for PostgreSQL allows the database administrator to *distribute* tables and/or schemas,
+storing different rows on different worker nodes. Distributed tables and/or schemas are the
+key to Azure Cosmos DB for PostgreSQL performance. Failing to distribute tables and/or schemas leaves them entirely
+on the coordinator node and can't take advantage of cross-machine parallelism.
 
 For each query on distributed tables, the coordinator either routes it to a
 single worker node, or parallelizes it across several depending on whether the
-required data lives on a single node or multiple. The coordinator decides what
+required data lives on a single node or multiple. With [schema-based sharding](concepts-sharding-models.md#schema-based-sharding), the coordinator routes the queries directly to the node that hosts the schema. In both schema-based sharding and [row-based sharding](concepts-sharding-models.md#row-based-sharding), the coordinator decides what
 to do by consulting metadata tables. These tables track the DNS names and
 health of worker nodes, and the distribution of data across nodes.
 
 ## Table types
 
-There are three types of tables in a cluster, each
+There are five types of tables in a cluster, each
 stored differently on nodes and used for different purposes.
 
 ### Type 1: Distributed tables
@@ -77,7 +76,15 @@ values like order statuses or product categories.
 
 When you use Azure Cosmos DB for PostgreSQL, the coordinator node you connect to is a regular PostgreSQL database. You can create ordinary tables on the coordinator and choose not to shard them.
 
-A good candidate for local tables would be small administrative tables that don't participate in join queries. An example is a users table for application sign-in and authentication.
+A good candidate for local tables would be small administrative tables that don't participate in join queries. An example is a `users` table for application sign-in and authentication.
+
+### Type 4: Local managed tables
+
+Azure Cosmos DB for PostgreSQL might automatically add local tables to metadata if a foreign key reference exists between a local table and a reference table. Additionally locally managed tables can be manually created by executing [create_reference_table](reference-functions.md#citus_add_local_table_to_metadata) citus_add_local_table_to_metadata function on regular local tables. Tables present in metadata are considered managed tables and can be queried from any node, Citus knows to route to the coordinator to obtain data from the local managed table. Such tables are displayed as local in [citus_tables](reference-metadata.md#distributed-tables-view) view.
+
+### Type 5: Schema tables
+
+With [schema-based sharding](concepts-sharding-models.md#schema-based-sharding) introduced in Citus 12.0, distributed schemas are automatically associated with individual colocation groups. Tables created in those schemas are automatically converted to colocated distributed tables without a shard key. Such tables are considered schema tables and are displayed as schema in [citus_tables](reference-metadata.md#distributed-tables-view) view.
 
 ## Shards