Merge pull request #10741 from MicrosoftDocs/main

Published main to live, Wednesday 10:30 AM PST, 04/02

windows/client-management/mdm/policy-csp-deliveryoptimization.md

@@ -219,6 +219,8 @@ Specifies how your client(s) can discover Microsoft Connected Cache servers dyna
 <!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
 > [!NOTE]
 > If the DHCP Option ID is formatted incorrectly, the client will fall back to the [Cache Server Hostname](#docachehost) policy value if that value has been set.
+> 
+> If [LocalPolicyMerge](/windows/security/operating-system-security/network-security/windows-firewall/rules#local-policy-merge-and-application-rules) setting is configured (e.g. as part of security baselines) it can impact DHCP client and prevent it from retrieving this DHCP option, especially in Autopilot scenarios.
 <!-- DOCacheHostSource-Editable-End -->
 
 <!-- DOCacheHostSource-DFProperties-Begin -->

windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md

@@ -17,6 +17,9 @@ ms.collection:
 
 # Autopatch group registration overview
 
+> [!IMPORTANT]
+> If you're new to Autopatch, it might take up to 48 hours for devices to appear as Registered in the [Autopatch groups membership report](../deploy/windows-autopatch-register-devices.md#autopatch-groups-membership-report). During this 48 hour period, devices undergo the necessary onboarding processes before appearing as registered.
+
 When you assign a Microsoft Entra Group to an Autopatch policy or [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group), the device is registered with the Autopatch Service.
 
 ## Prerequisites for device registration

windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md

@@ -17,6 +17,9 @@ ms.collection:
 
 # Register devices with Autopatch groups
 
+> [!IMPORTANT]
+> If you're new to Autopatch, it might take up to 48 hours for devices to appear as Registered in the [Autopatch groups membership report](../deploy/windows-autopatch-register-devices.md#autopatch-groups-membership-report). During this 48 hour period, devices undergo the necessary onboarding processes before appearing as registered
+
 An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/entra/fundamentals/groups-view-azure-portal), and software update policies. For more information, see [Windows Autopatch groups](../deploy/windows-autopatch-groups-overview.md).
 
 When you [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group), the device-based Microsoft Entra groups you use are scanned on an ongoing basis to see if new devices need to be added to the Autopatch group.

windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md

@@ -1,7 +1,7 @@
 ---
 title: Hotpatch updates
 description: Use Hotpatch updates to receive security updates without restarting your device
-ms.date: 03/31/2025
+ms.date: 04/02/2025
 ms.service: windows-client
 ms.subservice: autopatch
 ms.topic: how-to
@@ -15,10 +15,7 @@ ms.collection:
   - tier1
 ---
 
-# Hotpatch updates (public preview)
-
-> [!IMPORTANT]
-> This feature is in public preview. It's being actively developed and might not be complete. They're made available on a "Preview" basis. You can test and use these features in production environments and scenarios and provide feedback.
+# Hotpatch updates
 
 Hotpatch updates are designed to reduce downtime and disruptions. Hotpatch updates are [Monthly B release security updates](/windows/deployment/update/release-cycle#monthly-security-update-release) that install and take effect without requiring you to restart the device. By minimizing the need to restart, these updates help ensure faster compliance, making it easier for organizations to maintain security while keeping workflows uninterrupted.
 
@@ -52,7 +49,10 @@ To prepare a device to receive Hotpatch updates, configure the following operati
 
 VBS must be turned on for a device to be offered Hotpatch updates. For information on how to set and detect if VBS is enabled, see [Virtualization-based Security (VBS)](/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity?tabs=security).
 
-### Arm 64 devices must disable compiled hybrid PE usage (CHPE) (Arm 64 CPU Only)
+### Arm 64 devices must disable compiled hybrid PE usage (CHPE) (Arm 64 CPU Only) (Public preview)
+
+> [!IMPORTANT]
+> **Arm 64 devices are in public preview**. It's being actively developed and might not be complete. They're made available on a "Preview" basis. You can test and use these features in production environments and scenarios and provide feedback.
 
 This requirement only applies to Arm 64 CPU devices when using Hotpatch updates. Hotpatch updates aren't compatible with servicing CHPE OS binaries located in the `%SystemRoot%\SyChpe32` folder. To ensure all the Hotpatch updates are applied, you must set the CHPE disable flag and restart the device to disable CHPE usage. You only need to set this flag one time. The registry setting remains applied through updates. To disable CHPE, create and/or set the following DWORD registry key:
 Path: `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management`

windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md

@@ -22,6 +22,7 @@ appliesto:
 >
 > - Memory integrity is sometimes referred to as *hypervisor-protected code integrity (HVCI)* or *hypervisor enforced code integrity*, and was originally released as part of *Device Guard*. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.
 > - Memory integrity works better with Intel Kabylake and higher processors with *Mode-Based Execution Control*, and AMD Zen 2 and higher processors with *Guest Mode Execute Trap* capabilities. Older processors rely on an emulation of these features, called *Restricted User Mode*, and will have a bigger impact on performance. When nested virtualization is enabled, memory integrity works better when the VM is version >= 9.3.
+> - Azure VMs do not support memory integrity where **Secure Boot with DMA** is selected. If this is selected, VBS will show as enabled but not running. For this reason, please make sure to choose **Secure Boot** only using one of the methods below.
 
 ## Memory integrity features