@ -3253,10 +3253,7 @@ The table below shows the applicability of Windows:
<!--/Scope-->
<!--Description-->
> [!NOTE]
> This policy is available on Windows 10 Pro, Windows 10 Enterprise, and Windows 10 Education.
Enables the IT admin to schedule the time of the update installation.
Enables the IT admin to schedule the time of the update installation. Note that there is a window of approximately 30 minutes to allow for higher success rates of installation.
1. IT admin identifies devices to be managed by the Windows Autopatch service.
2. IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group.
3. The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.
1. Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:
1. AzureADDeviceID
2. OperatingSystem
3. DisplayName (Device name)
4. AccountEnabled
5. RegistrationDateTime
6. ApproximateLastSignInDateTime
2. In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.
4. The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:
1. **Serial number, model, and manufacturer.**
1. Checks if the serial number already exists in the Windows Autopatch’s managed device database.
2. **If the device is Intune-managed or not**.
1. Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.
1. If **yes**, it means this device is enrolled into Intune.
2. If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.
2. **If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.
1. Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.
2. A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with anymore. To remediate, [clean up any stale Azure AD device records from your tenant](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).
3. **If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.
3. **If the device is a Windows device or not**.
1. If it’s a Windows device, Windows Autopatch evaluates the following requirements:
1. Whether the **Windows OS version** is **greater or equal to 10**.
2. The **OS build** is **greater or equal to 1809**.
3. The **architecture** is **x64**.
4. **Windows Autopatch checks the Windows SKU family**. The SKU must be either:
1. **Enterprise**
2. **Pro**
3. **Pro Workstation**
5. If the device meets the operating system requirements, Windows Autopatch checks whether the device is either:
1. **Only managed by Intune**
1. If the device is only managed by Intune, the device is marked as **Passed all prerequisites**.
2. **Co-managed by both Configuration Manager and Intune**
1. If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state.
1. The required co-management workloads evaluated in this step are:
1. **Windows Updates Policies**
2. **Device Configuration**
3. **Office Click to Run**
2. If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.
5. Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:
1. If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.
2. If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.
6. Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:
1. The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-First). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.
7. Windows Autopatch also assigns devices to the following Azure AD groups:
1. **Modern Workplace Devices - All**
1. This group has all devices managed by Windows Autopatch.
2. **Modern Workplace Devices Dynamic - Windows 10**
1. This group has all devices managed by Windows Autopatch and that have Windows 10 installed.
3. **Modern Workplace Devices Dynamic - Windows 11**
1. This group has all devices managed by Windows Autopatch and that have Windows 11 installed.
4. **Modern Workplace Devices - Virtual Machine**
1. This group has all virtual devices managed by Windows Autopatch.
8. In post-device registration, three actions occur:
1. Windows Autopatch adds devices to its managed database.
2. Flags devices as **Active** in the **Ready** tab.
3. The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.
1. The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.
9. IT admins review the device registration status in both the **Ready** and **Not ready** tabs.
1. If the device was successfully registered, the device shows up in the **Ready** tab.
2. If not, the device shows up in the **Not ready** tab.
10. This is the end of the Windows Autopatch device registration workflow.
| Step | Description |
| ----- | ----- |
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
| **Step 2: Add devices** | IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group. |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.</li></ol> |
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.</li></ol></ol></ol>|
| **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:<ol><li>If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.</li><li>If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.</li></ol> |
| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-Test). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li></ol> |
| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:<ol><li>**Modern Workplace Devices - All**</li><ol><li>This group has all devices managed by Windows Autopatch.</li></ol><li>When registering **Windows 10 devices**, use **Modern Workplace Devices Dynamic - Windows 10**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 10 installed.</li></ol><li>When registering **Windows 11 devices**, use **Modern Workplace Devices Dynamic - Windows 11**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 11 installed.</li></ol><li>When registering **virtual devices**, use **Modern Workplace Devices - Virtual Machine**</li><ol><li>This group has all virtual devices managed by Windows Autopatch.</li></ol> |
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Ready** tab.</li><li>The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.</li><ol><li>The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.</li></ol> |
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not ready** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not ready** tab.</li></ol> |
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
10. Choose **Apply to this Service** and select **Internet Connection Sharing (ICS) Shared Access**.
- question:|
How can I disable portions of ICS without breaking Application Guard?
How can I disable portions of Internet Connection Service (ICS) without breaking Application Guard?
answer:|
ICS is enabled by default in Windows, and ICS must be enabled in order for Application Guard to function correctly. We do not recommend disabling ICS; however, you can disable ICS in part by using a Group Policy and editing registry keys.
ICS is enabled by default in Windows, and ICS must be enabled for Application Guard to function correctly. We do not recommend disabling ICS, this will stop Application Guard from working; however, you can disable ICS in part by using a Group Policy and editing registry keys.
1. In the Group Policy setting, **Prohibit use of Internet Connection Sharing on your DNS domain network**, set it to **Disabled**.
@ -58,7 +58,7 @@ Windows 10 mitigations that you can configure are listed in the following two ta
| **Credential Guard**<br> helps keep attackers<br>from gaining access through<br>Pass-the-Hash or<br>Pass-the-Ticket attacks | Credential Guard uses virtualization-based security to isolate secrets, such as NTLM password hashes and Kerberos Ticket Granting Tickets, so that only privileged system software can access them.<br>Credential Guard is included in Windows 10 Enterprise and Windows Server 2016.<br><br>**More information**: [Protect derived domain credentials with Credential Guard](/windows/access-protection/credential-guard/credential-guard) |
| **Enterprise certificate pinning**<br> helps prevent <br>man-in-the-middle attacks<br>that use PKI | Enterprise certificate pinning enables you to protect your internal domain names from chaining to unwanted certificates or to fraudulently issued certificates. With enterprise certificate pinning, you can "pin" (associate) an X.509 certificate and its public key to its Certification Authority, either root or leaf. <br><br>**More information**: [Enterprise Certificate Pinning](/windows/access-protection/enterprise-certificate-pinning) |
| **Device Guard**<br> helps keep a device<br>from running malware or<br>other untrusted apps | Device Guard includes a Code Integrity policy that you create; an allowlist of trusted apps—the only apps allowed to run in your organization. Device Guard also includes a powerful system mitigation called hypervisor-protected code integrity (HVCI), which uses virtualization-based security (VBS) to protect Windows' kernel-mode code integrity validation process. HVCI has specific hardware requirements, and works with Code Integrity policies to help stop attacks even if they gain access to the kernel.<br>Device Guard is included in Windows 10 Enterprise and Windows Server 2016.<br><br>**More information**: [Introduction to Device Guard](/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies) |
| **Microsoft Defender Antivirus**,<br>which helps keep devices<br>free of viruses and other<br>malware | Windows 10 includes Microsoft Defender Antivirus, a robust inbox anti-malware solution. Microsoft Defender Antivirus has been improved to a considerable extent since it was introduced in Windows 8.<br><br>**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic |
| **Microsoft Defender Antivirus**,<br>which helps keep devices<br>free of viruses and other<br>malware | Windows 10 includes Microsoft Defender Antivirus, a robust inbox anti-malware solution. Microsoft Defender Antivirus has been improved significantly since it was introduced in Windows 8.<br><br>**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic |
| **Blocking of untrusted fonts**<br> helps prevent fonts<br>from being used in<br>elevation-of-privilege attacks | Block Untrusted Fonts is a setting that allows you to prevent users from loading fonts that are "untrusted" onto your network, which can mitigate elevation-of-privilege attacks associated with the parsing of font files. However, as of Windows 10, version 1703, this mitigation is less important, because font parsing is isolated in an [AppContainer sandbox](/windows/win32/secauthz/appcontainer-isolation) (for a list describing this and other kernel pool protections, see [Kernel pool protections](#kernel-pool-protections), later in this topic).<br><br>**More information**: [Block untrusted fonts in an enterprise](/windows/threat-protection/block-untrusted-fonts-in-enterprise) |
| **Memory protections**<br> help prevent malware<br>from using memory manipulation<br>techniques such as buffer<br>overruns | These mitigations, listed in [Table 2](#table-2), help to protect against memory-based attacks, where malware or other code manipulates memory to gain control of a system (for example, malware that attempts to use buffer overruns to inject malicious executable code into memory. Note:<br>A subset of apps will not be able to run if some of these mitigations are set to their most restrictive settings. Testing can help you maximize protection while still allowing these apps to run.<br><br>**More information**: [Table 2](#table-2), later in this topic |
| **UEFI Secure Boot**<br> helps protect<br>the platform from<br>boot kits and rootkits | Unified Extensible Firmware Interface (UEFI) Secure Boot is a security standard for firmware built in to PCs by manufacturers beginning with Windows 8. It helps to protect the boot process and firmware against tampering, such as from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup.<br><br>**More information**: [UEFI and Secure Boot](/windows/device-security/bitlocker/bitlocker-countermeasures#uefi-and-secure-boot)</a> |
@ -103,14 +103,15 @@ Audit-only mode configures the SAMRPC protocol to do the access check against th
|Setting|RestrictRemoteSamAuditOnlyMode|
|Data Type|REG_DWORD|
|Value|1|
|Notes|This setting can't be added or removed by using predefined Group Policy settings. <br>Administrators may create a custom policy to set the registry value if needed. <br>SAM responds dynamically to changes in this registry value without a reboot.|
|Notes|This setting can't be added or removed by using predefined Group Policy settings. Administrators may create a custom policy to set the registry value if needed. SAM responds dynamically to changes in this registry value without a reboot.|
### Related events
There are corresponding events that indicate when remote calls to the SAM are restricted, what accounts attempted to read from the SAM database, and more. The following workflow is recommended to identify applications that may be affected by restricting remote calls to SAM:
1. Dump event logs to a common share.
1. Review Event IDs 16962 to 16969, as listed in the following table, in the System log with event source Directory-Service-SAM.
1. Right click the System log, select **Filter Current Log**, and specify `16962-16969` in the Event IDs field.
1. Review Event IDs 16962 to 16969, as listed in the following table, with event source **Directory-Service-SAM**.
1. Identify which security contexts are enumerating users or groups in the SAM database.
1. Prioritize the callers, determine if they should be allowed or not, then include the allowed callers in the SDDL string.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aaron Czechowski