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

Author: Hal-Zucati

articles/synapse-analytics/sql/query-cosmos-db-analytical-store.md

@@ -19,9 +19,6 @@ For querying Azure Cosmos DB, the full [SELECT](/sql/t-sql/queries/select-transa
 
 This article explains how to write a query with a serverless SQL pool that queries data from Azure Cosmos DB containers that are enabled with Azure Synapse Link. You can then learn more about building serverless SQL pool views over Azure Cosmos DB containers and connecting them to Power BI models in [this tutorial](./tutorial-data-analyst.md). This tutorial uses a container with an [Azure Cosmos DB well-defined schema](/azure/cosmos-db/analytical-store-introduction#schema-representation). You can also check out the Learn module on how to [Query Azure Cosmos DB with SQL Serverless for Azure Synapse Analytics](/training/modules/query-azure-cosmos-db-with-sql-serverless-for-azure-synapse-analytics/).
 
->[!NOTE]
-> You can't use managed identity to access an Azure Cosmos DB container from serverless SQL pool.
-
 ## Prerequisites
 
 - Make sure that you prepare the analytical store:
@@ -37,10 +34,11 @@ This article explains how to write a query with a serverless SQL pool that queri
 ## Overview
 
 Serverless SQL pool enables you to query Azure Cosmos DB analytical storage using `OPENROWSET` function. 
+- `OPENROWSET` that uses workspace managed identity to access the analytical store.
 - `OPENROWSET` with inline key. This syntax can be used to query Azure Cosmos DB collections without the need to prepare credentials.
 - `OPENROWSET` that references a credential that contains the Azure Cosmos DB account key. This syntax can be used to create views on Azure Cosmos DB collections.
 
-### [OPENROWSET with key](#tab/openrowset-key)
+### [OPENROWSET with key or managed identity](#tab/openrowset-key)
 
 To support querying and analyzing data in an Azure Cosmos DB analytical store, a serverless SQL pool is used. The serverless SQL pool uses the `OPENROWSET` SQL syntax, so you must first convert your Azure Cosmos DB connection string to this format:
 
@@ -67,6 +65,11 @@ The SQL connection string has the following format:
 ```
 
 The region is optional. If omitted, the container's primary region is used.
+You can use workspace managed identity instead fo the CosmosDB account key:
+
+```sql
+'account=<databases account name>;database=<database_name>;authtype=ManagedIdentity'
+```
 
 > [!IMPORTANT]
 > There's another optional parameter in connection string called `endpoint`. The `endpoint` param is needed for accounts that don't match the standard `*.documents.azure.com` format. For example, if your Azure Cosmos DB account ends with `.documents.azure.us`, make sure that you add `endpoint=<account name>.documents.azure.us` in the connection string.

articles/virtual-wan/how-to-network-virtual-appliance-inbound.md

@@ -70,7 +70,6 @@ The following table describes known issues related to the internet inbound/DNAT
 |Issue | Description| Mitigation|
 |--|--|--|
 | DNAT traffic isn't forwarded to the NVA after associating an additional IP address.| After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic isn't forwarded properly to the NVA due to a code defect. | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity. |
-|Inbound security rule configuration scalability| Inbound security rule configuration might fail when a large number (approximately 100)  rules are configured.| No mitigation, reach out to Azure Support for fix timelines.|
 
 ### Limitations
 
@@ -86,7 +85,7 @@ The following table describes known issues related to the internet inbound/DNAT
 
 ### Considerations
 
-* Inbound Traffic is automatically load-balanced across all healthy instances of the Network Virtual Appliance.
+* Inbound traffic is automatically load-balanced across all healthy instances of the Network Virtual Appliance. Virtual WAN uses five-tuple hashing algorithm to distribute flows for backend NVA instances. For certain use cases such as File Transfer Protocol (FTP) where a single application session might have   multiple five-tuple flows (e.g. FTP control and data plane packets on different ports), Virtual WAN does not guarantee that all flows in that session are distributed to the same NVA instance.
 * In most cases, NVAs must perform source-NAT to the Firewall private IP in addition to  destination-NAT to ensure flow symmetry. Certain NVA types might not require source-NAT. Contact your NVA provider for best practices around source-NAT.
 * Timeout for idle flows is automatically set to 4 minutes.
 * You can assign individual IP address resources generated from an IP address prefix to the NVA as internet inbound IPs. Assign each IP address from the prefix individually.

articles/virtual-wan/roles-permissions.md

@@ -182,7 +182,7 @@ NVAs (Network Virtual Appliances) in Virtual WAN are typically deployed through
 
 |Resource | Required Azure permissions due to resource references |
 |---|---|
-| networkVirtualAppliances  | Microsoft.Network/virtualHubs/read  |
+| networkVirtualAppliances  | Microsoft.Network/virtualHubs/read   <br? Microsoft.Network/publicIPAddresses/join|
 | networkVirtualAppliances/networkVirtualApplianceConnections  | Microsoft.Network/virtualHubs/routeMaps/read <br>Microsoft.Network/virtualHubs/hubRouteTables/read |