Merge pull request #310518 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-15 12:00 UTC

Author: learn-build-service-prod[bot]

articles/defender-for-iot/organizations/how-to-manage-individual-sensors.md

@@ -251,7 +251,7 @@ For more information, see [ERSPAN ports](best-practices/traffic-mirroring-method
 > [!NOTE]
 > This procedure restarts your sensor software to implement any changes made.
 >
-> Defender for IoT ERSPAN monitoring is tested, certified, and supported **only when the ERSPAN tunnel originates from Cisco devices.**
+> Defender for IoT ERSPAN monitoring is tested, certified, and supported **only when the ERSPAN tunnel originates from Cisco equipment.**
 >
 > ERSPAN tunnels from non-Cisco vendors are **not supported** and might fail due to differences in ERSPAN implementations.
 

articles/sentinel/includes/connector-details.md

@@ -2,7 +2,7 @@
 author: EdB-MSFT
 ms.author: edbayansh
 ms.topic: include
-ms.date: 01/14/2026
+ms.date: 01/15/2026
 
 # This file is auto-generated . Do not edit manually. Changes will be overwritten.
 ---
@@ -1896,6 +1896,23 @@ a. Users must have a valid Dataminr Pulse API **client ID** and **secret** to us
 
  ---
 
+<a name="datawiza-dap"></a><details><summary>**Datawiza DAP**</summary>
+
+**Supported by:** [Datawiza Technology Inc.](https://www.datawiza.com/contact-us/)
+
+Connects the Datawiza DAP logs to Azure Log Analytics via the REST API interface
+
+**Log Analytics table(s):**  
+
+|Table|DCR support|Lake-only ingestion|
+|---|---|---|
+|`datawizaserveraccess_CL`|No|No|
+
+**Data collection rule support:** Not currently supported<br><br>
+</details> 
+
+ ---
+   
 <a name="derdack-signl4"></a><details><summary>**Derdack SIGNL4**</summary>
 
 **Supported by:** [Derdack](https://signl4.zendesk.com/hc/en-us)

articles/vpn-gateway/site-to-site-high-bandwidth-tunnel.md

@@ -87,7 +87,26 @@ When using IPsec tunnels that transit ExpressRoute private peering, you must adv
 
 To ensure all traffic between Azure and your on-premises network is encrypted, configure routing so that only the VPN device tunnel IPs are advertised over ExpressRoute. The actual on-premises network prefixes should be routed through the VPN Gateway, either using static routes or BGP. This approach ensures that on-premises to Azure traffic is always encrypted inside the VPN tunnel before it enters the ExpressRoute data path.
 
-If you advertise on-premises network prefixes to ExpressRoute through BGP, those routes can bypass the VPN Gateway, resulting in unencrypted traffic. To prevent this issue, use a user-defined route (UDR) on your Azure virtual network to direct traffic to the VPN Gateway as the next hop. This configuration guarantees that all traffic is encrypted before transiting ExpressRoute.
+## <a name="Selective traffic encryption"></a>Selective traffic encryption between on-premises networks and Azure VNets
+
+In scenarios where only a portion of the traffic between your on-premises networks and an Azure Virtual Network (VNet) requires encryption, you can choose from the following configuration options.
+
+**Option 1 – Steering encrypted traffic via IPsec tunnels only**
+
+To ensure predictable routing, advertise different on-premises IP network prefixes over ExpressRoute and over the IPsec tunnels. Advertise only the on-premises prefixes that do not require encryption through the ExpressRoute circuit, and configure the IPsec tunnels to advertise only the prefixes that do require encryption.
+
+**Option 2 – Route precedence using more specific network prefixes**
+
+Advertise more specific (longer subnet masks) on‑premises IP network prefixes over the IPsec tunnels than the on-premises prefixes you advertise over the ExpressRoute circuit. Because Azure and on‑premises devices both select routes based on longest prefix match (LPM), these more specific prefixes learned through the IPsec tunnel will take precedence over the less specific prefixes learned through ExpressRoute. This ensures that traffic destined for those networks follows the encrypted IPsec path rather than the unencrypted ExpressRoute path.
+
+These considerations apply regardless of whether static or dynamic routing is used for the IPsec tunnels.
+
+Avoid advertising the same on-premises IP network prefixes simultaneously over both ExpressRoute circuit and IPsec tunnels. If the on-premises routing policies give to the IPsec tunnels higher priority, outbound traffic from on-premises to Azure will prefer the IPsec path. However, Azure typically prefers routes learned from ExpressRoute Gateway when identical prefixes are received from both connections. 
+This mismatch results in asymmetric routing, where traffic flows outbound through one path (IPsec) but returns through another (ExpressRoute). Flows with asymmetric transit can lead to packet drops, especially on stateful on-premises devices.
+
+> [!NOTE]
+> Do not use User Defined Routes (UDRs) with a next-hop type **Virtual Network Gateway** to force traffic through the VPN Gateway. This approach is not supported and does not work.
+
 
 ## <a name="VNetGateway"></a>Create a VPN gateway High Bandwidth tunnel