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

Author: halkazwini

articles/backup/backup-blobs-storage-account-ps.md

@@ -206,8 +206,8 @@ To update the backup instance, run the following cmdlets:
    1. Fetch the backup instance that needs to be updated.
 
          ```azurepowershell
-         C:\Users\dapatil> $instance = Search-AzDataProtectionBackupInstanceInAzGraph -Subscription "Demosub" -ResourceGroup Demo-BCDR-RG -Vault BCDR-BV-EastUS -DatasourceType AzureBlob
-         PS C:\Users\dapatil> $instance
+         C:\Users\testuser> $instance = Search-AzDataProtectionBackupInstanceInAzGraph -Subscription "Demosub" -ResourceGroup Demo-BCDR-RG -Vault BCDR-BV-EastUS -DatasourceType AzureBlob
+         PS C:\Users\testuser> $instance
                         Output
          Name                                                                     BackupInstanceName
          ----                                                                     ------------------
@@ -226,12 +226,12 @@ To update the backup instance, run the following cmdlets:
    1. Update the backup instance with new list of container (the existing backed up containers & new containers).       
 
          ```azurepowershell
-         PS C:\Users\dapatil> $updateBI = Update-AzDataProtectionBackupInstance -ResourceGroupName Daya-BCDR-RG -VaultName DPBCDR-BV-EastUS -BackupInstanceName $instance[0].Name -SubscriptionId "ef4ab5a7-c2c0-4304-af80-af49f48af3d1"  -PolicyId $updatePolicy.id -VaultedBackupContainer $targetContainers.name
+         PS C:\Users\testuser> $updateBI = Update-AzDataProtectionBackupInstance -ResourceGroupName Daya-BCDR-RG -VaultName DPBCDR-BV-EastUS -BackupInstanceName $instance[0].Name -SubscriptionId "ef4ab5a7-c2c0-4304-af80-af49f48af3d1"  -PolicyId $updatePolicy.id -VaultedBackupContainer $targetContainers.name
          
          
-         PS C:\Users\dapatil> $updateBI.Property.PolicyInfo.PolicyId
+         PS C:\Users\testuser> $updateBI.Property.PolicyInfo.PolicyId
          /subscriptions/ef4ab5a7-c2c0-4304-af80-af49f48af3d1/resourceGroups/Daya-BCDR-RG/providers/Microsoft.DataProtection/backupVaults/DPBCDR-BV-EastUS/backupPolicies/continerdeltest-1
-         PS C:\Users\dapatil> $updateBI.Property.PolicyInfo.PolicyParameter.BackupDatasourceParametersList[0].ContainersList
+         PS C:\Users\testuser> $updateBI.Property.PolicyInfo.PolicyParameter.BackupDatasourceParametersList[0].ContainersList
          cont-01
          cont-02
          cont-03

articles/cdn/migrate-cdn-to-front-door-retain-edge-domain.md

@@ -125,7 +125,13 @@ This article provides you with instructions for migrating to Azure Front Door fr
     - AFD endpoint hostname (for example, `contoso.azurefd.net`)
     - Azure CDN from Edgio endpoint hostname (for example, `contoso.azureedge.net`)
 
-1. The Azure support team makes the necessary DNS changes. Traffic will now start being served by the Azure Front Door service.
+1. The Azure support team makes the necessary DNS changes within 24-48 hours of filing the ticket. Traffic will now start being served by the Azure Front Door service.
+1. If you face any issues and need to rollback the DNS changes, you can reopen the support ticket and request for rollback.
+
+    > [!NOTE]
+    > - Most of the traffic will immediately switch to Azure Front Door. You may see a small portion of the traffic still served by Edgio. The DNS changes takes time to propagate and some DNS servers have high TTL for DNS record expiry. Wait for 24-48 hours for all the traffic to switch.
+    > - After the changes, under AFD Domains blade, the 'Certificate state' field may show the value as 'issuing' and the 'DNS state' field may show the value as 'Certificate needed'. This is just a portal bug that will be fixed by January 31st. The bug doesn't impact your certificates or traffic in any manner as the Certificate and DNS State for *.azureedge.net domains are completely managed by AFD.
+   
 
 ## Next step
 

articles/defender-for-iot/organizations/release-notes.md

@@ -42,6 +42,7 @@ Cloud features may be dependent on a specific sensor version. Such features are
 | Version / Patch |  Release date | Scope     | Supported until |
 | ------- |  ------------ | ----------- | ------------------- |
 | **24.1** | | | |
+| 24.1.8  |12/2024 | Minor |12/2025 |
 | 24.1.7  |12/2024 | Minor |12/2025 |
 | 24.1.6  |11/2024 | Minor |12/2025 |
 | 24.1.5  |09/2024 | Minor |09/2025 |
@@ -96,6 +97,14 @@ To understand whether a feature is supported in your sensor version, check the r
 
 ## Versions 24.1.x
 
+### 24.1.8
+
+**Release date**: 12/2024
+
+**Supported until**: 12/2025
+
+This version includes bug fixes for stability improvements.
+
 ### 24.1.7
 
 **Release date**: 12/2024

articles/defender-for-iot/organizations/whats-new.md

@@ -22,6 +22,16 @@ Features released earlier than nine months ago are described in the [What's new
 
 The legacy on-premises management console won't be available for download after **January 1st, 2025**. We recommend transitioning to the new architecture using the full spectrum of on-premises and cloud APIs before this date. For more information, see [on-premises management console retirement](ot-deploy/on-premises-management-console-retirement.md).
 
+## December 2024
+
+|Service area  |Updates  |
+|---------|---------|
+| **OT networks** | - [Support Multiple Source Devices in DDoS Attack Alerts](#support-multiple-source-devices-in-ddos-attack-alerts) |
+
+### Support Multiple Source Devices in DDoS Attack Alerts
+
+Alert details now display up to 10 source devices involved in DDoS attack.
+
 ## October 2024
 
 |Service area  |Updates  |

articles/virtual-network/ip-services/default-outbound-access.md

@@ -55,7 +55,7 @@ If you deploy a virtual machine in Azure and it doesn't have explicit outbound c
 
 Some examples of configurations that won't work when using default outbound access:
 - When you have multiple NICs on the same VM, default outbound IPs won't consistently be the same across all NICs.
-- When scaling up/down Virtual Machine Scale sets, default outbound IPs assigned to individual instances can and  change.
+- When scaling up/down Virtual Machine Scale sets, default outbound IPs assigned to individual instances can change.
 - Similarly, default outbound IPs aren't consistent or contiguous across VM instances in a Virtual Machine Scale Set.
 
 ## How can I transition to an explicit method of public connectivity (and disable default outbound access)?