From 5b10942cce3eccae3a13f3c5e38f77773d9ce121 Mon Sep 17 00:00:00 2001 From: justingross-msft <110203253+justingross-msft@users.noreply.github.com> Date: Mon, 31 Mar 2025 21:55:46 -0400 Subject: [PATCH 1/8] Update enable-virtualization-based-protection-of-code-integrity.md This is a known issue in Azure as shown here, https://supportability.visualstudio.com/AzureIaaSVM/_wiki/wikis/AzureIaaSVM/1763930/VBS-Enabled-But-Not-Running-After-Install-HyperV_Windows. Having this note will hopefully allow customers to set this correct or have us share this page when the issue is seen. --- .../enable-virtualization-based-protection-of-code-integrity.md | 1 + 1 file changed, 1 insertion(+) diff --git a/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md b/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md index 928f69bd65..b0810ce013 100644 --- a/windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md +++ b/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 From a090aa8c5658291e9dcea12669f1c69a1b42161b Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Tue, 1 Apr 2025 11:21:18 -0700 Subject: [PATCH 2/8] Hotpatch GA --- .../manage/windows-autopatch-hotpatch-updates.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md index 78799f5867..68013d96d5 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md +++ b/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. From 6a5a981a557721571a872bd2018755109cf0f529 Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Tue, 1 Apr 2025 13:27:08 -0700 Subject: [PATCH 3/8] Arm 64 devices are still in preview --- .../manage/windows-autopatch-hotpatch-updates.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md index 68013d96d5..13c164c255 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md @@ -51,6 +51,9 @@ VBS must be turned on for a device to be offered Hotpatch updates. For informati ### Arm 64 devices must disable compiled hybrid PE usage (CHPE) (Arm 64 CPU Only) +> [!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` DWORD key value: HotPatchRestrictions=1 From 99dc7c35c0284cb86acd2f25e5007ba7225a4e3c Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Tue, 1 Apr 2025 13:28:23 -0700 Subject: [PATCH 4/8] Tweaked the Arm 42 devices preview note and section --- .../manage/windows-autopatch-hotpatch-updates.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md b/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md index 13c164c255..a3eb3ff2fb 100644 --- a/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md +++ b/windows/deployment/windows-autopatch/manage/windows-autopatch-hotpatch-updates.md @@ -49,10 +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. +> **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` From 3c9d6f111d2c0f5ed52fa819173e567c995c68dd Mon Sep 17 00:00:00 2001 From: Andrei-George Stoica <5600871+andreiztm@users.noreply.github.com> Date: Wed, 2 Apr 2025 14:59:46 +0300 Subject: [PATCH 5/8] Update policy-csp-deliveryoptimization.md --- .../client-management/mdm/policy-csp-deliveryoptimization.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/windows/client-management/mdm/policy-csp-deliveryoptimization.md b/windows/client-management/mdm/policy-csp-deliveryoptimization.md index 080e775bf4..f5a49685d6 100644 --- a/windows/client-management/mdm/policy-csp-deliveryoptimization.md +++ b/windows/client-management/mdm/policy-csp-deliveryoptimization.md @@ -219,6 +219,8 @@ Specifies how your client(s) can discover Microsoft Connected Cache servers dyna > [!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. From c217f464703d2e39ccd27c83b022c4ea9f232940 Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Wed, 2 Apr 2025 08:56:26 -0700 Subject: [PATCH 6/8] Added 48hour note about registration time --- .../deploy/windows-autopatch-register-devices.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md index ac9de45be2..aaf372c8b1 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md @@ -17,6 +17,9 @@ ms.collection: # Register devices with Autopatch groups +> [!IMPORTANT] +> Device registration might take up to 48 hours to reflect in the system. During this 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. From f713bc2d8b22d1d967c1a597a344b5ec420342df Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Wed, 2 Apr 2025 09:04:22 -0700 Subject: [PATCH 7/8] Tweak --- .../deploy/windows-autopatch-device-registration-overview.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md index 4ac68eb702..dc115eb4c1 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md @@ -17,6 +17,9 @@ ms.collection: # Autopatch group registration overview +> [!IMPORTANT] +> Device registration might take up to 48 hours to reflect in the system. During this 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 From 2d6919a3133b4132973215e52565d2284a8daa50 Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Wed, 2 Apr 2025 09:19:01 -0700 Subject: [PATCH 8/8] another tweak --- .../deploy/windows-autopatch-device-registration-overview.md | 2 +- .../deploy/windows-autopatch-register-devices.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md index dc115eb4c1..0818a69802 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md @@ -18,7 +18,7 @@ ms.collection: # Autopatch group registration overview > [!IMPORTANT] -> Device registration might take up to 48 hours to reflect in the system. During this period, devices undergo the necessary onboarding processes before appearing as registered. +> 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. diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md index aaf372c8b1..d9567ba906 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md @@ -18,7 +18,7 @@ ms.collection: # Register devices with Autopatch groups > [!IMPORTANT] -> Device registration might take up to 48 hours to reflect in the system. During this period, devices undergo the necessary onboarding processes before appearing as registered. +> 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).