From 990bb42d449203eeecda2c72255244c4154c7d76 Mon Sep 17 00:00:00 2001 From: itsrlyAria <82474610+itsrlyAria@users.noreply.github.com> Date: Thu, 28 Jul 2022 23:46:20 -0700 Subject: [PATCH 01/10] Update policy-csp-update.md Added a detail about the policy behavior with respect to scan time. --- windows/client-management/mdm/policy-csp-update.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/windows/client-management/mdm/policy-csp-update.md b/windows/client-management/mdm/policy-csp-update.md index 69a315b2b4..aff7ce985b 100644 --- a/windows/client-management/mdm/policy-csp-update.md +++ b/windows/client-management/mdm/policy-csp-update.md @@ -3253,10 +3253,7 @@ The table below shows the applicability of Windows: -> [!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. Noting that there is a +/- 30 minute window to allow for higher success rates of installation. The supported data type is an integer. From eca3e156cbc3d33eadddead0e7b505c3abe6b4e2 Mon Sep 17 00:00:00 2001 From: Salman Hossain Saif Date: Fri, 29 Jul 2022 15:26:00 +0600 Subject: [PATCH 02/10] Update overview-of-threat-mitigations-in-windows-10.md Updated the file with a cleaner phrase on line 61. Regarding the issue: https://github.com/MicrosoftDocs/windows-itpro-docs/issues/10490 --- .../overview-of-threat-mitigations-in-windows-10.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md b/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md index 436d94ab00..b4ab4b2171 100644 --- a/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md +++ b/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md @@ -58,7 +58,7 @@ Windows 10 mitigations that you can configure are listed in the following two ta | **Credential Guard**
helps keep attackers
from gaining access through
Pass-the-Hash or
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.
Credential Guard is included in Windows 10 Enterprise and Windows Server 2016.

**More information**: [Protect derived domain credentials with Credential Guard](/windows/access-protection/credential-guard/credential-guard) | | **Enterprise certificate pinning**
helps prevent
man-in-the-middle attacks
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.

**More information**: [Enterprise Certificate Pinning](/windows/access-protection/enterprise-certificate-pinning) | | **Device Guard**
helps keep a device
from running malware or
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.
Device Guard is included in Windows 10 Enterprise and Windows Server 2016.

**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**,
which helps keep devices
free of viruses and other
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.

**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic | +| **Microsoft Defender Antivirus**,
which helps keep devices
free of viruses and other
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.

**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic | | **Blocking of untrusted fonts**
helps prevent fonts
from being used in
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).

**More information**: [Block untrusted fonts in an enterprise](/windows/threat-protection/block-untrusted-fonts-in-enterprise) | | **Memory protections**
help prevent malware
from using memory manipulation
techniques such as buffer
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:
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.

**More information**: [Table 2](#table-2), later in this topic | | **UEFI Secure Boot**
helps protect
the platform from
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.

**More information**: [UEFI and Secure Boot](/windows/device-security/bitlocker/bitlocker-countermeasures#uefi-and-secure-boot) | From 50be04dc5eb2f78fc4a4825c270d7aa4a4439d68 Mon Sep 17 00:00:00 2001 From: Andre Della Monica Date: Fri, 29 Jul 2022 08:19:21 -0500 Subject: [PATCH 03/10] Latest updates --- ...windows-autopatch-device-registration-overview.md | 12 ++++++------ .../deploy/windows-autopatch-register-devices.md | 2 +- .../prepare/windows-autopatch-prerequisites.md | 9 +++++---- 3 files changed, 12 insertions(+), 11 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 cf47404f87..a4df2a5a86 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 @@ -59,7 +59,7 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto 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). + 2. 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/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: @@ -85,17 +85,17 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto 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. **Modern Workplace Devices-Windows Autopatch-First** - 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. + 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-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. 2. **Modern Workplace Devices-Windows Autopatch-Fast** 3. **Modern Workplace Devices-Windows Autopatch-Broad** -7. Windows Autopatch also assigns devices to the following Azure AD groups: +7. Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply: 1. **Modern Workplace Devices - All** 1. This group has all devices managed by Windows Autopatch. - 2. **Modern Workplace Devices Dynamic - Windows 10** + 2. When registering Windows 10 devices - **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** + 3. When registering Windows 11 devices - **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** + 4. When registering virtual devices - **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. 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 1d44162fb9..14e592ed12 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md @@ -65,7 +65,7 @@ It's recommended to detect and clean up stale devices in Azure AD before registe To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites: -- [Supported Windows 10/11 Enterprise and Professional edition versions](/windows/release-health/supported-versions-windows-client) +- Windows 10 (1809+)/11 Enterprise and Professional edition versions (only x64 architecture). - Either [Hybrid Azure AD-Joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Azure AD-joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported). - Managed by Microsoft Endpoint Manager. - [Microsoft Intune](https://www.microsoft.com/cloud-platform/microsoft-intune) and/or [Configuration Manager Co-management](/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites#configuration-manager-co-management-requirements). diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md index e5755ced5e..2d7ad54d04 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md @@ -39,11 +39,12 @@ Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. The fol | [Windows 10/11 Enterprise E5](/azure/active-directory/enterprise-users/licensing-service-plan-reference) | WIN10_VDA_E5 | 488ba24a-39a9-4473-8ee5-19291e71b002 | | [Windows 10/11 Enterprise VDA](/windows/deployment/deploy-enterprise-licenses#virtual-desktop-access-vda) | E3_VDA_only | d13ef257-988a-46f3-8fce-f47484dd4550 | -The following Windows 64-bit editions are required for Windows Autopatch: +The following Windows OS editions, builds and architecture are supported in Windows Autopatch: -- Windows 10/11 Pro -- Windows 10/11 Enterprise -- Windows 10/11 Pro for Workstations +- x64 architecture +- Windows 10 (1809+)/11 Pro +- Windows 10 (1809+)/11 Enterprise +- Windows 10 (1809+)/11 Pro for Workstations ## Configuration Manager Co-management requirements From a02a2982f5ed1b61d6da7528e0668ebcc19a3c71 Mon Sep 17 00:00:00 2001 From: Sunny Zankharia <67922512+sazankha@users.noreply.github.com> Date: Fri, 29 Jul 2022 07:39:07 -0700 Subject: [PATCH 04/10] Update faq-md-app-guard.yml --- .../microsoft-defender-application-guard/faq-md-app-guard.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml index b641427ea4..4e72f94860 100644 --- a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml +++ b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml @@ -169,9 +169,9 @@ sections: 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**. From cbd0c71910b25f076bffc746036682f662c6b3bf Mon Sep 17 00:00:00 2001 From: Tiara Quan <95256667+tiaraquan@users.noreply.github.com> Date: Fri, 29 Jul 2022 08:25:20 -0700 Subject: [PATCH 05/10] Update windows-autopatch-prerequisites.md Added OS 10 and 1809 build as per Andre --- .../prepare/windows-autopatch-prerequisites.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md b/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md index 2d7ad54d04..2f4d13cfe0 100644 --- a/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md +++ b/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md @@ -39,7 +39,7 @@ Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. The fol | [Windows 10/11 Enterprise E5](/azure/active-directory/enterprise-users/licensing-service-plan-reference) | WIN10_VDA_E5 | 488ba24a-39a9-4473-8ee5-19291e71b002 | | [Windows 10/11 Enterprise VDA](/windows/deployment/deploy-enterprise-licenses#virtual-desktop-access-vda) | E3_VDA_only | d13ef257-988a-46f3-8fce-f47484dd4550 | -The following Windows OS editions, builds and architecture are supported in Windows Autopatch: +The following Windows OS 10 editions, 1809 builds and architecture are supported in Windows Autopatch: - x64 architecture - Windows 10 (1809+)/11 Pro From 52b10ad8fe85089021d1f4314b33a65a58f6dbdd Mon Sep 17 00:00:00 2001 From: Tiara Quan <95256667+tiaraquan@users.noreply.github.com> Date: Fri, 29 Jul 2022 08:27:38 -0700 Subject: [PATCH 06/10] Update windows-autopatch-device-registration-overview.md --- .../windows-autopatch-device-registration-overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 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 a4df2a5a86..30c9b47f12 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 @@ -91,11 +91,11 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto 7. Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply: 1. **Modern Workplace Devices - All** 1. This group has all devices managed by Windows Autopatch. - 2. When registering Windows 10 devices - **Modern Workplace Devices Dynamic - Windows 10** + 2. When registering Windows 10 devices, use **Modern Workplace Devices Dynamic - Windows 10** 1. This group has all devices managed by Windows Autopatch and that have Windows 10 installed. - 3. When registering Windows 11 devices - **Modern Workplace Devices Dynamic - Windows 11** + 3. When registering Windows 11 devices, use **Modern Workplace Devices Dynamic - Windows 11** 1. This group has all devices managed by Windows Autopatch and that have Windows 11 installed. - 4. When registering virtual devices - **Modern Workplace Devices - Virtual Machine** + 4. When registering virtual devices, use **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. From f9530554f985a650162d989bf81b9fd35e217640 Mon Sep 17 00:00:00 2001 From: Aaron Czechowski Date: Fri, 29 Jul 2022 11:31:14 -0400 Subject: [PATCH 07/10] Update windows/client-management/mdm/policy-csp-update.md Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- windows/client-management/mdm/policy-csp-update.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/client-management/mdm/policy-csp-update.md b/windows/client-management/mdm/policy-csp-update.md index aff7ce985b..53012c6503 100644 --- a/windows/client-management/mdm/policy-csp-update.md +++ b/windows/client-management/mdm/policy-csp-update.md @@ -3253,7 +3253,7 @@ The table below shows the applicability of Windows: -Enables the IT admin to schedule the time of the update installation. Noting that there is a +/- 30 minute window to allow for higher success rates of 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. The supported data type is an integer. From 1a7fe7381f1882d09eece61c3af0da84c535b829 Mon Sep 17 00:00:00 2001 From: Vinay Pamnani <37223378+vinaypamnani-msft@users.noreply.github.com> Date: Fri, 29 Jul 2022 11:33:55 -0400 Subject: [PATCH 08/10] Update BC again --- windows/security/breadcrumb/toc.yml | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/windows/security/breadcrumb/toc.yml b/windows/security/breadcrumb/toc.yml index 56a1f207bc..6c5b49c520 100644 --- a/windows/security/breadcrumb/toc.yml +++ b/windows/security/breadcrumb/toc.yml @@ -9,8 +9,4 @@ items: items: - name: Security tocHref: /windows/security/ - topicHref: /windows/security/ - items: - - name: User security - tocHref: /windows-server/security/credentials-protection-and-management/ - topicHref: /windows/security/identity + topicHref: /windows/security/ From 4ab66d679d662bddd4e99141c862978955e9380d Mon Sep 17 00:00:00 2001 From: Vinay Pamnani <37223378+vinaypamnani-msft@users.noreply.github.com> Date: Fri, 29 Jul 2022 13:34:53 -0400 Subject: [PATCH 09/10] Remove reference to broken script --- ...lients-allowed-to-make-remote-sam-calls.md | 92 ++++++++++--------- 1 file changed, 47 insertions(+), 45 deletions(-) diff --git a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md index 3193b11f86..3494cc9cc3 100644 --- a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md +++ b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md @@ -8,7 +8,7 @@ ms.pagetype: security ms.localizationpriority: medium author: dansimp ms.date: 09/17/2018 -ms.reviewer: +ms.reviewer: manager: dansimp ms.author: dansimp ms.technology: windows-sec @@ -17,47 +17,47 @@ ms.technology: windows-sec # Network access: Restrict clients allowed to make remote calls to SAM **Applies to** -- Windows 10, version 1607 and later -- Windows 10, version 1511 with [KB 4103198](https://support.microsoft.com/help/4013198) installed -- Windows 10, version 1507 with [KB 4012606](https://support.microsoft.com/help/4012606) installed -- Windows 8.1 with [KB 4102219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed -- Windows 7 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed -- Windows Server 2019 -- Windows Server 2016 -- Windows Server 2012 R2 with[KB 4012219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed -- Windows Server 2012 with [KB 4012220](https://support.microsoft.com/help/4012220/march-2017-preview-of-monthly-quality-rollup-for-windows-server-2012) installed -- Windows Server 2008 R2 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed +- Windows 10, version 1607 and later +- Windows 10, version 1511 with [KB 4103198](https://support.microsoft.com/help/4013198) installed +- Windows 10, version 1507 with [KB 4012606](https://support.microsoft.com/help/4012606) installed +- Windows 8.1 with [KB 4102219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed +- Windows 7 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed +- Windows Server 2019 +- Windows Server 2016 +- Windows Server 2012 R2 with[KB 4012219](https://support.microsoft.com/help/4012219/march-2017-preview-of-monthly-quality-rollup-for-windows-8-1-and-windows-server-2012-r2) installed +- Windows Server 2012 with [KB 4012220](https://support.microsoft.com/help/4012220/march-2017-preview-of-monthly-quality-rollup-for-windows-server-2012) installed +- Windows Server 2008 R2 with [KB 4012218](https://support.microsoft.com/help/4012218/march-2017-preview-of-monthly-quality-rollup-for-windows-7-sp1-and-windows-server-2008-r2-sp1) installed -The **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting controls which users can enumerate users and groups in the local Security Accounts Manager (SAM) database and Active Directory. -The setting was first supported by Windows 10 version 1607 and Windows Server 2016 (RTM) and can be configured on earlier Windows client and server operating systems by installing updates from the KB articles listed in **Applies to** section of this topic. +The **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting controls which users can enumerate users and groups in the local Security Accounts Manager (SAM) database and Active Directory. +The setting was first supported by Windows 10 version 1607 and Windows Server 2016 (RTM) and can be configured on earlier Windows client and server operating systems by installing updates from the KB articles listed in **Applies to** section of this topic. This topic describes the default values for this security policy setting in different versions of Windows. -By default, computers beginning with Windows 10 version 1607 and Windows Server 2016 are more restrictive than earlier versions of Windows. +By default, computers beginning with Windows 10 version 1607 and Windows Server 2016 are more restrictive than earlier versions of Windows. This restrictive characteristic means that if you have a mix of computers, such as member servers that run both Windows Server 2016 and Windows Server 2012 R2, the servers that run Windows Server 2016 may fail to enumerate accounts by default where the servers that run Windows Server 2012 R2 succeed. -This topic also covers related events, and how to enable audit mode before constraining the security principals that are allowed to remotely enumerate users and groups so that your environment remains secure without impacting application compatibility. +This topic also covers related events, and how to enable audit mode before constraining the security principals that are allowed to remotely enumerate users and groups so that your environment remains secure without impacting application compatibility. > [!NOTE] > Implementation of this policy [could affect offline address book generation](/troubleshoot/windows-server/group-policy/authz-fails-access-denied-error-application-access-check) on servers running Microsoft Exchange 2016 or Microsoft Exchange 2013. ## Reference -The SAMRPC protocol makes it possible for a low privileged user to query a machine on a network for data. -For example, a user can use SAMRPC to enumerate users, including privileged accounts such as local or domain administrators, or to enumerate groups and group memberships from the local SAM and Active Directory. -This information can provide important context and serve as a starting point for an attacker to compromise a domain or networking environment. +The SAMRPC protocol makes it possible for a low privileged user to query a machine on a network for data. +For example, a user can use SAMRPC to enumerate users, including privileged accounts such as local or domain administrators, or to enumerate groups and group memberships from the local SAM and Active Directory. +This information can provide important context and serve as a starting point for an attacker to compromise a domain or networking environment. -To mitigate this risk, you can configure the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting to force the security accounts manager (SAM) to do an access check against remote calls. -The access check allows or denies remote RPC connections to SAM and Active Directory for users and groups that you define. +To mitigate this risk, you can configure the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting to force the security accounts manager (SAM) to do an access check against remote calls. +The access check allows or denies remote RPC connections to SAM and Active Directory for users and groups that you define. -By default, the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting isn't defined. -If you define it, you can edit the default Security Descriptor Definition Language (SDDL) string to explicitly allow or deny users and groups to make remote calls to the SAM. -If the policy setting is left blank after the policy is defined, the policy isn't enforced. +By default, the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting isn't defined. +If you define it, you can edit the default Security Descriptor Definition Language (SDDL) string to explicitly allow or deny users and groups to make remote calls to the SAM. +If the policy setting is left blank after the policy is defined, the policy isn't enforced. -The default security descriptor on computers beginning with Windows 10 version 1607 and Windows Server 2016 allows only the local (built-in) Administrators group remote access to SAM on non-domain controllers, and allows Everyone access on domain controllers. +The default security descriptor on computers beginning with Windows 10 version 1607 and Windows Server 2016 allows only the local (built-in) Administrators group remote access to SAM on non-domain controllers, and allows Everyone access on domain controllers. You can edit the default security descriptor to allow or deny other users and groups, including the built-in Administrators. -The default security descriptor on computers that run earlier versions of Windows doesn't restrict any remote calls to SAM, but an administrator can edit the security descriptor to enforce restrictions. +The default security descriptor on computers that run earlier versions of Windows doesn't restrict any remote calls to SAM, but an administrator can edit the security descriptor to enforce restrictions. This less restrictive default allows for testing the impact of enabling restrictions on existing applications. ## Policy and Registry Names @@ -71,21 +71,22 @@ This less restrictive default allows for testing the impact of enabling restrict | **Registry type** | REG_SZ | | **Registry value** | A string that will contain the SDDL of the security descriptor to be deployed. | -The Group Policy setting is only available on computers that run Windows Server 2016 or Windows 10, version 1607 and later. +The Group Policy setting is only available on computers that run Windows Server 2016 or Windows 10, version 1607 and later. These computers are the only option to configure this setting by using a user interface (UI). -On computers that run earlier versions of Windows, you need to edit the registry setting directly or use Group Policy Preferences. -To avoid setting it manually in this case, you can configure the GPO itself on a computer that runs Windows Server 2016 or Windows 10, version 1607 or later and have it apply to all computers within the scope of the GPO because the same registry key exists on every computer after the corresponding KB is installed. +On computers that run earlier versions of Windows, you need to edit the registry setting directly or use Group Policy Preferences. +To avoid setting it manually in this case, you can configure the GPO itself on a computer that runs Windows Server 2016 or Windows 10, version 1607 or later and have it apply to all computers within the scope of the GPO because the same registry key exists on every computer after the corresponding KB is installed. > [!NOTE] -> This policy is implemented similarly to other "Network access" policies in that there is a single policy element at the registry path listed. There is no notion of a local policy versus an enterprise policy; there is just one policy setting and whichever writes last wins. -> -> For example, suppose a local administrator configures this setting as part of a local policy using the Local Security Policy snap-in (Secpol.msc), which edits that same registry path. If an enterprise administrator configures this setting as part of an enterprise GPO, that enterprise GPO will overwrite the same registry path. +> This policy is implemented similarly to other "Network access" policies in that there is a single policy element at the registry path listed. There is no notion of a local policy versus an enterprise policy; there is just one policy setting and whichever writes last wins. +> +> For example, suppose a local administrator configures this setting as part of a local policy using the Local Security Policy snap-in (Secpol.msc), which edits that same registry path. If an enterprise administrator configures this setting as part of an enterprise GPO, that enterprise GPO will overwrite the same registry path. ## Default values -Beginning with Windows 10, version 1607 and Windows Server 2016, computers have hard-coded and more restrictive default values than earlier versions of Windows. -The different default values help strike a balance where recent Windows versions are more secure by default and older versions don’t undergo any disruptive behavior changes. -Administrators can test whether applying the same restriction earlier versions of Windows will cause compatibility problems for existing applications before implementing this security policy setting in a production environment. + +Beginning with Windows 10, version 1607 and Windows Server 2016, computers have hard-coded and more restrictive default values than earlier versions of Windows. +The different default values help strike a balance where recent Windows versions are more secure by default and older versions don’t undergo any disruptive behavior changes. +Administrators can test whether applying the same restriction earlier versions of Windows will cause compatibility problems for existing applications before implementing this security policy setting in a production environment. In other words, the hotfix in each KB article provides the necessary code and functionality, but you need to configure the restriction after you install the hotfix—no restrictions are enabled by default after the hotfix is installed on earlier versions of Windows. @@ -110,16 +111,17 @@ 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.
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.
You can use the [Events 16962 - 16969 Reader](https://gallery.technet.microsoft.com/Events-16962-16969-Reader-2eae5f1d) script to parse the event logs, as explained in the next section.| +|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. -2. Parse them with the [Events 16962 - 16969 Reader](https://gallery.technet.microsoft.com/Events-16962-16969-Reader-2eae5f1d) script. -3. Review Event IDs 16962 to 16969, as listed in the following table, in the System log with event source Directory-Service-SAM. -4. Identify which security contexts are enumerating users or groups in the SAM database. -5. Prioritize the callers, determine if they should be allowed or not, then include the allowed callers in the SDDL string. + +1. Dump event logs to a common share. +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. |Event ID|Event Message Text|Explanation | |---|---|---| @@ -127,12 +129,12 @@ There are corresponding events that indicate when remote calls to the SAM are re |16963|Message Text: "Remote calls to the SAM database are being restricted using the configured registry security descriptor: %1.%n"

%1 - "Registry SD String:" |Emit event when a new SDDL is read from the registry (either on startup or change) and is considered valid. The event includes the source and a copy of the queried SDDL. |16964|"The registry security descriptor is malformed: %1.%n Remote calls to the SAM database are being restricted using the default security descriptor: %2.%n"

%1- "Malformed SD String:"
%2- "Default SD String:"|Emit event when registry SDDL is mal-formed, causing fallback to default hard-coded SDDL (event should include a copy of the default SDDL). |16965|Message Text: "A remote call to the SAM database has been denied.%nClient SID: %1%n Network address: %2%n"

%1- "Client SID:" %2- "Client Network Address | Emit event when access is denied to a remote client. Event should include identity and network address of the client. -|16966|Audit Mode is enabled-

Message Text: "Audit only mode is now enabled for remote calls to the SAM database. SAM will log an event for clients who would have been denied access in normal mode. %n"|Emit event whenever training mode (see 16968) is enabled or disabled. +|16966|Audit Mode is enabled-

Message Text: "Audit only mode is now enabled for remote calls to the SAM database. SAM will log an event for clients who would have been denied access in normal mode. %n"|Emit event whenever training mode (see 16968) is enabled or disabled. |16967|Audit Mode is disabled-

Message Text: "Audit only mode is now disabled for remote calls to the SAM database.%n For more information"|Emit event whenever training mode (see 16968) is enabled or disabled. |16968| Message Text: "Audit only mode is currently enabled for remote calls to the SAM database.%n The following client would have been normally denied access:%nClient SID: %1 from network address: %2. %n"
%1- "Client SID:"
%2- "Client Network Address:"|Emit event when access would have been denied to a remote client, but was allowed through due to training mode being enabled. Event should include identity and network address of the client.| |16969|Message Text: "%2 remote calls to the SAM database have been denied in the past %1-seconds throttling window.%n
"%1- "Throttle window:"
%2- "Suppressed Message Count:"| Throttling may be necessary for some events due to expected high volume on some servers causing the event log to wrap.

Note: There's no throttling of events when audit mode is enabled. Environments with a large number of low-privilege and anonymous querying of the remote database may see large numbers of events logged to the System log. For more info, see the [Event Throttling](#event-throttling) section. -Compare the security context attempting to remotely enumerate accounts with the default security descriptor. Then edit the security descriptor to add accounts that require remote access. +Compare the security context attempting to remotely enumerate accounts with the default security descriptor. Then edit the security descriptor to add accounts that require remote access. ### Event Throttling A busy server can flood event logs with events related to the remote enumeration access check. To prevent this, access-denied events are logged once every 15 minutes by default. The length of this period is controlled by the following registry value. @@ -153,18 +155,18 @@ Restarts aren't required to enable, disable or modify the **Network access: Rest This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. -### Vulnerability +### Vulnerability The SAMRPC protocol has a default security posture that makes it possible for low-privileged attackers to query a machine on the network for data that is critical to their further hacking and penetration plans.

The following example illustrates how an attacker might exploit remote SAM enumeration: 1. A low-privileged attacker gains a foothold on a network. -2. The attacker then queries all machines on the network to determine which ones have a highly privileged domain user configured as a local administrator on that machine. +2. The attacker then queries all machines on the network to determine which ones have a highly privileged domain user configured as a local administrator on that machine. 3. If the attacker can, then find any other vulnerability on that machine that allows taking it over, the attacker can then squat on the machine waiting for the high-privileged user to sign in and then steal or impersonate those credentials. ### Countermeasure You can mitigate this vulnerability by enabling the **Network access: Restrict clients allowed to make remote calls** to SAM security policy setting and configuring the SDDL for only those accounts that are explicitly allowed access. ### Potential impact -If the policy is defined, admin tools, scripts and software that formerly enumerated users, groups and group membership may fail. To identify accounts that may be affected, test this setting in [audit only mode](#audit-only-mode). +If the policy is defined, admin tools, scripts and software that formerly enumerated users, groups and group membership may fail. To identify accounts that may be affected, test this setting in [audit only mode](#audit-only-mode). ## Related Topics [Security Options](./security-options.md) From 118df2ce9498b394c700602319165fc355e2cf9a Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Fri, 29 Jul 2022 13:42:20 -0700 Subject: [PATCH 10/10] Reformatted steps into a table to make it easier to read. --- ...-autopatch-device-registration-overview.md | 79 +++---------------- 1 file changed, 12 insertions(+), 67 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 30c9b47f12..1d55fce3d7 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 @@ -39,73 +39,18 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto :::image type="content" source="../media/windows-autopatch-device-registration-workflow-diagram.png" alt-text="Detailed device registration workflow diagram" lightbox="../media/windows-autopatch-device-registration-workflow-diagram.png"::: -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 it 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. **Modern Workplace Devices-Windows Autopatch-First** - 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-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. - 2. **Modern Workplace Devices-Windows Autopatch-Fast** - 3. **Modern Workplace Devices-Windows Autopatch-Broad** -7. Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply: - 1. **Modern Workplace Devices - All** - 1. This group has all devices managed by Windows Autopatch. - 2. When registering Windows 10 devices, use **Modern Workplace Devices Dynamic - Windows 10** - 1. This group has all devices managed by Windows Autopatch and that have Windows 10 installed. - 3. When registering Windows 11 devices, use **Modern Workplace Devices Dynamic - Windows 11** - 1. This group has all devices managed by Windows Autopatch and that have Windows 11 installed. - 4. When registering virtual devices, use **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.
  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.
| +| **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:
  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 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).
    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. 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.
  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. 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.
| +| **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:
  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%)**.
| +| **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:
  1. **Modern Workplace Devices-Windows Autopatch-First**
    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-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.
  2. **Modern Workplace Devices-Windows Autopatch-Fast**
  3. **Modern Workplace Devices-Windows Autopatch-Broad**
| +| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:
  1. **Modern Workplace Devices - All**
    1. This group has all devices managed by Windows Autopatch.
  2. When registering **Windows 10 devices**, use **Modern Workplace Devices Dynamic - Windows 10**
    1. This group has all devices managed by Windows Autopatch and that have Windows 10 installed.
  3. When registering **Windows 11 devices**, use **Modern Workplace Devices Dynamic - Windows 11**
    1. This group has all devices managed by Windows Autopatch and that have Windows 11 installed.
  4. When registering **virtual devices**, use **Modern Workplace Devices - Virtual Machine**
    1. This group has all virtual devices managed by Windows Autopatch.
    | +| **Step 8: Post-device registration** | 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.
      | +| **Step 9: Review device registration status** | 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.
      | +| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. | ## Detailed prerequisite check workflow diagram