Merge pull request #290303 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/firewall/protect-azure-kubernetes-service.md

@@ -146,6 +146,11 @@ When the previous command has succeeded, save the firewall frontend IP address f
 
 FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
 FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)
+
+
+# set fw as vnet dns server so dns queries are visible in fw logs
+
+az network vnet update -g $RG --name $VNET_NAME --dns-servers $FWPRIVATE_IP
 ```
 
 > [!NOTE]
@@ -191,6 +196,11 @@ az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aks
 
 ```azurecli
 az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
+
+# set fw application rule to allow kubernettes to reach storage and image resources
+
+az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwarweb' -n 'storage' --source-addresses '10.42.1.0/24' --protocols 'https=443' --target-fqdns '*.blob.storage.azure.net' '*.blob.core.windows.net' --action allow --priority 101
+az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwarweb' -n 'website' --source-addresses '10.42.1.0/24' --protocols 'https=443' --target-fqdns 'ghcr.io' '*.docker.io' '*.docker.com' '*.githubusercontent.com' 
 ```
 
 See [Azure Firewall documentation](overview.md) to learn more about the Azure Firewall service.

articles/migrate/migrate-servers-to-azure-using-private-link.md

@@ -235,7 +235,7 @@ With discovery completed, you can begin replication of Hyper-V VMs to Azure.
     > You can update replication settings any time before replication starts, **Manage** > **Replicating machines**. Settings can't be changed after replication starts. 
 
     Next, follow the instructions to [perform migrations](tutorial-migrate-hyper-v.md#migrate-vms). 
-]
+
 ### Grant access permissions to the Recovery Services vault
 
 You must grant the permissions to the Recovery Services vault for authenticated access to the cache/replication storage account.

articles/migrate/vmware/prepare-for-agentless-migration.md

@@ -16,7 +16,7 @@ ms.custom: vmware-scenario-422, engagement-fy23, linux-related-content
 
 This article provides an overview of the changes performed when you [migrate VMware VMs to Azure via the agentless migration](./tutorial-migrate-vmware.md) method using the Migration and modernization tool.
 
-Before you migrate your on-premises VM to Azure, you may require a few changes to make the VM ready for Azure. These changes are important to ensure that the migrated VM can boot successfully in Azure and connectivity to the Azure VM can be established-.
+Before you migrate your on-premises VM to Azure, you may require a few changes to make the VM ready for Azure. These changes are important to ensure that the migrated VM can boot successfully in Azure and connectivity to the Azure VM can be established.
 Azure Migrate automatically handles these configuration changes for the following operating system versions for both Linux and Windows. This process is called *Hydration*.
 
 **Operating system versions supported for hydration**

articles/site-recovery/tutorial-prepare-azure.md

@@ -87,7 +87,7 @@ On-premises machines are replicated to Azure managed disks. When failover occurs
     1. After deleting the pre-existing address range, select **Add an IP address space**.
 
        :::image type="Protection state" source="media/tutorial-prepare-azure/add-ip-address-space.png" alt-text="Screenshot of the adding IP.":::
-    1. In **Starting address** enter **10.0.0.**
+    1. In **Starting address** enter **10.0.0.0**
     1. Under **Address space size**, select **/24 (256 addresses)**.
     1. Select **Add**.
 

articles/storage/elastic-san/elastic-san-scale-targets.md

@@ -57,7 +57,7 @@ The following regions are regions with higher base storage capacity available, a
 ##### Lower available base storage capacity
 
 
-The following regions are regions with higher base storage capacity available, and the table following the regions outlines their scale targets: East Asia, Korea Central, South Africa North, France Central, Southeast Asia, West US 3, Sweden Central, Switzerland North.
+The following regions are regions with lower base storage capacity available, and the table following the regions outlines their scale targets: East Asia, Korea Central, South Africa North, France Central, Southeast Asia, West US 3, Sweden Central, Switzerland North.
 
 
 |Resource  |Values  |

articles/virtual-network/virtual-network-test-latency.md

@@ -21,7 +21,7 @@ Many other common network latency test tools, such as Ping, don't measure TCP or
 
 Latte and SockPerf measure only TCP or UDP payload delivery times. These tools use the following approach to measure network latency between two physical or virtual computers:
 
-1. Create a two-way communications channel between the computers by designating one as sender and one as receiver.
+1. Create a two-way communication channel between the computers by designating one as sender and one as receiver.
 1. Send and receive packets in both directions and measure the round-trip time (RTT).
 
 ## Tips and best practices to optimize network latency
@@ -39,7 +39,7 @@ Use the following best practices to test and analyze network latency:
 
 1. Test the effects on network latency of changing any of the following components:
    - Operating system (OS) or network stack software, including configuration changes.
-   - VM deployment method, such as deploying to an availability zone or proximity placement group (PPG).
+   - VM deployment methods, such as deploying to an availability zone or proximity placement group (PPG).
    - VM properties, such as Accelerated Networking or size changes.
    - Virtual network configuration, such as routing or filtering changes.
 
@@ -49,13 +49,13 @@ Use the following best practices to test and analyze network latency:
 
 ## Test VMs with Latte or SockPerf
 
-Use the following procedures to install and test network latency with [Latte](https://github.com/mellanox/sockperf) for Windows or [SockPerf](https://github.com/mellanox/sockperf) for Linux.
+Use the following procedures to install and test network latency with [Latte](https://github.com/microsoft/latte) for Windows or [SockPerf](https://github.com/mellanox/sockperf) for Linux.
 
 # [Windows](#tab/windows)
 
 ### Install Latte and configure VMs
 
-1. [Download the latest version of latte.exe](https://github.com/microsoft/latte/releases/download/v0/latte.exe) to both VMs, into a separate folder such as *c:\\tools*.
+1. [Download the latest version of latte.exe](https://github.com/microsoft/latte/releases/latest/download/latte.exe) to both VMs and put it in a separate folder such as *c:/tools*.
 
 1. On the *receiver* VM, create a Windows Defender Firewall `allow` rule to allow the Latte traffic to arrive. It's easier to allow the *latte.exe* program by name than to allow specific inbound TCP ports. In the command, replace the `<path>` placeholder with the path you downloaded *latte.exe* to, such as *c:\\tools\\*.
 
@@ -78,7 +78,7 @@ Run *latte.exe* from the Windows command line, not from PowerShell.
 
    The following example shows the command for a VM with an IP address of `10.0.0.4`:<br><br>`latte -a 10.0.0.4:5005 -i 65100`
 
-1. On the *sender* VM, run the same command as on the receiver, except with `-c` added to indicate the *client* or sender VM. Again replace the `<receiver IP address>`, `<port>`, and `<iterations>` placeholders with your own values.
+1. On the *sender* VM, run the same command as on the receiver, except with `-c` added to indicate the *client* or sender VM. Again, replace the `<receiver IP address>`, `<port>`, and `<iterations>` placeholders with your own values.
 
    ```cmd
    latte -c -a <receiver IP address>:<port> -i <iterations>