resolve merge conflict

Author: b-ahibbard

.openpublishing.publish.config.json

@@ -542,6 +542,12 @@
       "branch": "main",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "azure-cosmos-db-mongodb-mern-web-app",
+      "url": "https://github.com/Azure-samples/msdocs-azure-cosmos-db-mongodb-mern-web-app/",
+      "branch": "main",
+      "branch_mapping": {}
+    },
     {
       "path_to_root": "azure-cosmos-spark",
       "url": "https://github.com/Azure/azure-cosmosdb-spark",

.openpublishing.redirection.json

@@ -11503,6 +11503,11 @@
             "redirect_url": "/azure/firewall/ftp-support",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/firewall/firewall-network-rule-logging.md",
+            "redirect_url": "/azure/firewall/firewall-diagnostics",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/security/governance-in-azure.md",
             "redirect_url": "/azure/governance/",

articles/active-directory/develop/msal-client-application-configuration.md

@@ -87,7 +87,7 @@ Using MSAL in your code, you specify the audience by using one of the following
 
 MSAL will throw a meaningful exception if you specify both the Azure AD authority audience and the tenant ID.
 
-If you don't specify an audience, your app will target Azure AD and personal Microsoft accounts as an audience. (That is, it will behave as though `common` were specified.)
+It is recommended to specify an audience, as many tenants, and the applications deployed in them will have guest users. If your application will have external users, the endpoints of `common` and `organization` are best avoided. If you don't specify an audience, your app will target Azure AD and personal Microsoft accounts as an audience and will behave as though `common` were specified.
 
 ### Effective audience
 

articles/azure-monitor/logs/analyze-usage.md

@@ -114,7 +114,7 @@ Event
 ```
 
 ## Data volume by computer
-You can analyze the amount of billable data collected from a virtual machine or a set of virtual machines. The **Usage** table doesn't include information about data collected from virtual machines, so these queries use the [find operator](/azure/data-explorer/kusto/query/findoperator) to search all tables that include a computer name. The **Usage** type is omitted because this query is only for analytics of data trends.
+You can analyze the amount of billable data collected from a virtual machine or a set of virtual machines. The **Usage** table doesn't have the granularity to show data volumes for specific virtual machines, so these queries use the [find operator](/azure/data-explorer/kusto/query/findoperator) to search all tables that include a computer name. The **Usage** type is omitted because this query is only for analytics of data trends.
 
 > [!WARNING]
 > Use [find](/azure/data-explorer/kusto/query/findoperator?pivots=azuremonitor) queries sparingly because scans across data types are [resource intensive](./query-optimization.md#query-details-pane) to execute. If you don't need results per subscription, resource group, or resource name, use the [Usage](/azure/azure-monitor/reference/tables/usage) table as in the preceding queries.

articles/azure-vmware/vmware-hcx-mon-guidance.md

@@ -3,14 +3,14 @@ title: VMware HCX Mobility Optimized Networking (MON) guidance
 description: Learn about Azure VMware Solution-specific use cases for Mobility Optimized Networking (MON).  
 ms.topic: reference
 ms.service: azure-vmware
-ms.date: 3/10/2023
+ms.date: 3/24/2023
 ---
 
 # VMware HCX Mobility Optimized Networking (MON) guidance
 
 >[!NOTE]
 >
->HCX Mobility Optimized Networking is officially supported by VMware and Azure VMware Solutions from HCX version 4.1.0. 
+> VMware HCX Mobility Optimized Networking is officially supported by VMware and Azure VMware Solutions from HCX version 4.1.0. 
 
 >[!IMPORTANT] 
 >
@@ -20,7 +20,7 @@ ms.date: 3/10/2023
 > 
 >[Limitations for any HCX deployment including MON](https://docs.vmware.com/en/VMware-HCX/4.2/hcx-user-guide/GUID-BEC26054-D560-46D0-98B4-7FF09501F801.html)
 >
->VMware HCX Mobility Optimized Networkign (MON) is not supported with the use of a 3rd party gateway. It may only be used with the T1 gateway directly connected to the T0 gateway with no network virtual appliance (NVA). It may be able to make this configuration function, but we do not support it. 
+>VMware HCX Mobility Optimized Networking (MON) is not supported with the use of a 3rd party gateway. It may only be used with the T1 gateway directly connected to the T0 gateway with no network virtual appliance (NVA). You may be able to make this configuration function, but we do not support it. 
 
 [HCX Mobility Optimized Networking (MON)](https://docs.vmware.com/en/VMware-HCX/4.2/hcx-user-guide/GUID-0E254D74-60A9-479C-825D-F373C41F40BC.html) is an optional feature to enable when using [HCX Network Extensions (NE)](configure-hcx-network-extension.md). MON provides optimal traffic routing under certain scenarios to prevent network tromboning between the on-premises and cloud-based resources on extended networks. 
 
@@ -32,10 +32,8 @@ Throughout the migration cycle, MON optimizes application mobility for:
 
 - Optimizing and avoiding asymmetric traffic flows between on-premises, Azure VMware Solution, and Azure
 
-
 In this article, you'll learn about the Azure VMware Solution-specific use cases for MON.
 
-
 ## Optimize traffic flows across standard and stretched segments on the private cloud side 
 
 In this scenario, VM1 is migrated to the cloud using the NE, which provides optimal VM to VM latency. As a result, VM1 needs low latency to VM3 on the local Azure VMware Solution segment. We migrate the VM1 gateway from on-premises to Azure VMware Solution (cloud) to ensure an optimal path for traffic (blue line). If the gateway remains on-premises (red line), a tromboning effect and higher latency are observed. 
@@ -45,8 +43,6 @@ In this scenario, VM1 is migrated to the cloud using the NE, which provides opti
 
 :::image type="content" source="media/tutorial-vmware-hcx/hcx-mon-user-case-diagram-1.png" alt-text="Diagram showing the optimization for VM to VM L2 communication when using stretched networks." border="false":::
 
-
-
 ## Optimize and avoid asymmetric traffic flows 
 
 In this scenario, we assume a VM from on-premises has been migrated to Azure VMware Solution and participates in L2, and L3 traffic flows back to on-premises to access services. We also assume some VM communication from Azure (in the Azure VMware Solution connected vNET) could reach down into the Azure VMware Solution private cloud.
@@ -63,12 +59,10 @@ If choosing the NE path for example, the MON policy routes have to specifically
 Policy routes are evaluated only if the VM gateway is migrated to the cloud. The effect of this configuration is that any matching subnets for the destination get tunneled over the NE appliance.  If not matched, they get routed through the T0 gateway.
 
 >[!NOTE]
->Special consideration for using MON in Azure VMware Solution is to give the /32 routes advertised over BGP to its peers; this includes on-premises and Azure over the ExpressRoute connection. For example, a VM in Azure learns the path to an Azure VMware Solution VM on an Azure VMware Solution MON enabled segment. Once the return traffic is sent back to the T0 as expected, if the return subnet is an RFC1918 match, traffic is forced over the NE instead of the T0.  Then egresses over the ExpressRoute back to Azure on the on-premises side.  This can cause confusion for stateful firewalls in the middle and asymmetric routing behavior. It's also a good idea to determine how VMs on NE MON segments will need to access the internet, either via the T0 in Azure VMware Solution or only through the NE back to on-premises.
+>Special consideration for using MON in Azure VMware Solution is to give the /32 routes advertised over BGP to its peers; this includes on-premises and Azure over the ExpressRoute connection. For example, a VM in Azure learns the path to an Azure VMware Solution VM on an Azure VMware Solution MON enabled segment. Once the return traffic is sent back to the T0 gateway as expected, if the return subnet is an RFC1918 match, traffic is forced over the NE instead of the T0. Then egresses over the ExpressRoute back to Azure on the on-premises side. This can cause confusion for stateful firewalls in the middle and asymmetric routing behavior. It's also a good idea to determine how VMs on NE MON segments will need to access the internet, either via the T0 in Azure VMware Solution or only through the NE back to on-premises. In general, all of the default policy routes should be removed to avoid asymmetric traffic. Only enable policy routes if the network infrastructure as been configured in such a way to account for and prevent asymmetric traffic.
 
 :::image type="content" source="media/tutorial-vmware-hcx/hcx-mon-user-case-diagram-3.png" alt-text="Diagram showing the RFC1918 egress and egress traffic flow." border="false":::
 
 As outlined in the above diagram, the importance is to match a policy route to each required subnet. Otherwise, the traffic gets routed over the T0 and not the NE.
 
- 
 To learn more about policy routes, see [Mobility Optimized Networking Policy Routes](https://docs.vmware.com/en/VMware-HCX/4.1/hcx-user-guide/GUID-F45B1DB5-C640-4A75-AEC5-45C58B1C9D63.html).
-

articles/cosmos-db/includes/appliesto-mongodb-vcore.md

@@ -0,0 +1,12 @@
+---
+author: seesharprun
+ms.author: sidandrews
+ms.reviewer: mjbrown
+ms.service: cosmos-db
+ms.topic: include
+ms.date: 03/07/2023
+---
+
+APPLIES TO:
+:::image type="icon" source="media/applies-to/yes-icon.svg" border="false":::
+MongoDB vCore