Merge branch 'main' into ADO-9517656-Update-for-Business

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

@@ -20,7 +20,7 @@ ms.collection:
 [!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)]
 
 > [!IMPORTANT]
-> This feature is in public preview. It is 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 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 are [Monthly B release security updates](/windows/deployment/update/release-cycle#monthly-security-update-release) that can be installed without requiring you to restart the device. Hotpatch updates are designed to reduce downtime and disruptions. By minimizing the need to restart, these updates help ensure faster compliance, making it easier for organizations to maintain security while keeping workflows uninterrupted.
 
@@ -40,14 +40,14 @@ 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)
 
-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, set the following registry key:
-Path: `**HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management**`
-Key value: `**HotPatchRestrictions=1**`
+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
 
-> [!IMPORTANT:]
-> This setting is required because it forces the operating system to use the emulation x86-only binaries insetad of CHPE binaries on Arm 64 devices. CHPE binaries include native Arm 64 code to improve performance, excluding the CHPE binaries might affect performance or compatibility. Be sure to test application compatibility and performance before rolling out Hotpatch updates widely on Arm 64 CPU based devices.
+> [!IMPORTANT]
+> This setting is required because it forces the operating system to use the emulation x86-only binaries instead of CHPE binaries on Arm 64 devices. CHPE binaries include native Arm 64 code to improve performance, excluding the CHPE binaries might affect performance or compatibility. Be sure to test application compatibility and performance before rolling out Hotpatch updates widely on Arm 64 CPU based devices.
 
-If you choose to no longer use Hotpatch updates, clear the CHPE disasble flag (`HotPatchRestrictions=0`) then restart the device to turn on CHPE usage.  
+If you choose to no longer use Hotpatch updates, clear the CHPE disable flag (`HotPatchRestrictions=0`) then restart the device to turn on CHPE usage.  
 
 ## Eligible devices
 
@@ -76,7 +76,7 @@ For more information about the release calendar for Hotpatch updates, see [Relea
 ## Enroll devices to receive Hotpatch updates
 
 > [!NOTE]
-> If you're using Autopatch groups and want your devices to receive Hotpatch updates, you must create a Hotpatch policy and assign devices to it.  Turning on Hotpatch updates doesn't change the deferral setting applied to devices within an Autopatch group.
+> If you're using Autopatch groups and want your devices to receive Hotpatch updates, you must create a Hotpatch policy and assign devices to it. Turning on Hotpatch updates doesn't change the deferral setting applied to devices within an Autopatch group.
 
 **To enroll devices to receive Hotpatch updates:**
 
@@ -94,4 +94,4 @@ For more information about the release calendar for Hotpatch updates, see [Relea
 These steps ensure that targeted devices, which are [eligible](#eligible-devices) to receive Hotpatch updates, are configured properly. [Ineligible devices](#ineligible-devices) are offered the latest cumulative updates (LCU).
 
 > [!NOTE]
-> Turning on Hotpatch updates doesn't change the existing deadline-driven or scheduled install configurations on your managed devices.  Deferral and active hour settings will still apply.
+> Turning on Hotpatch updates doesn't change the existing deadline-driven or scheduled install configurations on your managed devices. Deferral and active hour settings still apply.

windows/deployment/windows-autopatch/manage/windows-autopatch-manage-autopatch-groups.md

@@ -78,6 +78,9 @@ Before you start managing Autopatch groups, ensure you meet the [Windows Autopat
 > [!IMPORTANT]
 > Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
 
+> [!CAUTION]
+> If a device that was previously added to an Autopatch group uses an Entra group (via Assigned groups or Dynamic distribution method) is removed from the Entra group, the device is removed and de-registered from the Autopatch service. The removed device no longer has any Autopatch service-created policies applied to it and the device won't appear in the Autopatch devices reports.
+
 ## Rename an Autopatch group
 
 **To rename an Autopatch group:**

windows/deployment/windows-autopatch/manage/windows-autopatch-manage-driver-and-firmware-updates.md

@@ -68,7 +68,7 @@ For deployment rings set to **Automatic**, you can choose the deferral period fo
 
 The deferral period allows you to delay the installation of driver and firmware updates on the devices in the specified deployment ring in case you want to test the update on a smaller group of devices first or avoid potential disruptions during a busy period.  
 
-The deferral period can be set from 0 to 14 days, and it can be different for each deployment ring.  
+The deferral period can be set from 0 to 30 days, and it can be different for each deployment ring.  
 
 > [!NOTE]
 > The deferral period only applies to automatically approved driver and firmware updates. An admin must specify the date to start offering a driver with any manual approval.

windows/deployment/windows-autopatch/prepare/windows-autopatch-configure-network.md

@@ -63,7 +63,7 @@ The following URLs must be on the allowed list of your proxy and firewall so tha
 
 | Microsoft service | URLs required on allowlist |
 | ----- | ----- |
-| Windows Autopatch | <ul><li>mmdcustomer.microsoft.com</li><li>mmdls.microsoft.com</li><li>logcollection.mmd.microsoft.com</li><li>support.mmd.microsoft.com</li><li>devicelistenerprod.microsoft.com</li><li>login.windows.net</li><li>payloadprod*.blob.core.windows.net</li><li>device.autopatch.microsoft.com</li></ul>|
+| Windows Autopatch | <ul><li>mmdcustomer.microsoft.com</li><li>mmdls.microsoft.com</li><li>logcollection.mmd.microsoft.com</li><li>support.mmd.microsoft.com</li><li>devicelistenerprod.microsoft.com</li><li>login.windows.net</li><li>device.autopatch.microsoft.com</li></ul>|
 
 ## Delivery Optimization