mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-28 13:17:23 +00:00
Merge branch 'main' of github.com:MicrosoftDocs/windows-docs-pr into pm-20220912-WinSE-documentation
This commit is contained in:
Paolo Matarazzo
commit
4a295c89ca
@ -138,7 +138,7 @@ Table 3. Settings in the Security node in the Google Admin Console
|
||||
|Set up single sign-on (SSO)|This section is used to configure SSO for Google web-based apps (such as Google Apps Gmail or Google Apps Calendar). While you don’t need to migrate any settings in this section, you probably will want to configure Azure Active Directory synchronization to replace Google-based SSO.|
|
||||
|Advanced settings|This section is used to configure administrative access to user data and to configure the Google Secure Data Connector (which allows Google Apps to access data on your local network). You don’t need to migrate any settings in this section.|
|
||||
|
||||
**Identify locally-configured settings to migrate**
|
||||
**Identify locally configured settings to migrate**
|
||||
|
||||
In addition to the settings configured in the Google Admin Console, users may have locally configured their devices based on their own personal preferences (as shown in Figure 2). Table 4 lists the Chromebook user and device settings that you can locally configure. Review the settings and determine which settings you'll migrate to Windows. Some of the settings listed in Table 4 can only be seen when you click the **Show advanced settings** link (as shown in Figure 2).
|
||||
|
||||
@ -146,7 +146,7 @@ In addition to the settings configured in the Google Admin Console, users may ha
|
||||
|
||||
Figure 2. Locally configured settings on Chromebook
|
||||
|
||||
Table 4. Locally-configured settings
|
||||
Table 4. Locally configured settings
|
||||
|
||||
| Section | Settings |
|
||||
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|
||||
@ -116,8 +116,6 @@ You can configure a dedicated testing account through MDM or Configuration Manag
|
||||
- **Custom OMA-DM URI** = ./Vendor/MSFT/SecureAssessment/LaunchURI
|
||||
- **String value** = *assessment URL*
|
||||
|
||||
See [Assessment URLs](#assessment-urls) for more information.
|
||||
|
||||
4. Create a policy that associates the assessment URL to the account using the following values:
|
||||
|
||||
- **Custom OMA-DM URI** = ./Vendor/MSFT/SecureAssessment/TesterAccount
|
||||
@ -265,12 +263,6 @@ You can also distribute the test link by creating a shortcut. To create the shor
|
||||
|
||||
Once the shortcut is created, you can copy it and distribute it to students.
|
||||
|
||||
|
||||
## Assessment URLs
|
||||
This assessment URL uses our lockdown API:
|
||||
- SBAC/AIR: [https://mobile.tds.airast.org/launchpad/](https://mobile.tds.airast.org/launchpad/).
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
[Take tests in Windows](take-tests-in-windows-10.md)
|
||||
|
||||
@ -102,7 +102,7 @@ The following applications can also run on Windows 11 SE, and can be deployed us
|
||||
| eTests | 4.0.25 | Win32 | CASAS |
|
||||
| FortiClient | 7.0.1.0083 | Win32 | Fortinet |
|
||||
| Free NaturalReader | 16.1.2 | Win32 | Natural Soft |
|
||||
| Ghotit | 10.14.2.3 | Win32 | Ghotit Ltd |
|
||||
| Ghotit Real Writer & Reader | 10.14.2.3 | Win32 | Ghotit Ltd |
|
||||
| GoGuardian | 1.4.4 | Win32 | GoGuardian |
|
||||
| Google Chrome | 102.0.5005.115 | Win32 | Google |
|
||||
| Illuminate Lockdown Browser | 2.0.5 | Win32 | Illuminate Education |
|
||||
|
||||
@ -4,61 +4,62 @@ description: VAMT enables administrators to automate and centrally manage the Wi
|
||||
ms.reviewer:
|
||||
manager: dougeby
|
||||
ms.author: aaroncz
|
||||
ms.prod: w10
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-deploy
|
||||
author: aczechowski
|
||||
ms.date: 04/25/2017
|
||||
ms.topic: article
|
||||
ms.date: 09/16/2022
|
||||
ms.topic: overview
|
||||
---
|
||||
|
||||
# Introduction to VAMT
|
||||
|
||||
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office®, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has one of the following Windows operating systems: Windows® 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 R2, or Windows Server 2012.
|
||||
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows, Office, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has a supported Windows OS version.
|
||||
|
||||
> [!NOTE]
|
||||
> VAMT can be installed on, and can manage, physical or virtual instances. VAMT cannot detect whether or not the remote products are virtual. As long as the products can respond to Windows Management Instrumentation (WMI) calls, they will be discovered and activated.
|
||||
> VAMT can be installed on, and can manage, physical or virtual instances. VAMT can't detect whether or not the remote products are virtual. As long as the products can respond to Windows Management Instrumentation (WMI) calls, they will be discovered and activated.
|
||||
|
||||
## In this Topic
|
||||
|
||||
- [Managing Multiple Activation Key (MAK) and Retail Activation](#bkmk-managingmak)
|
||||
- [Managing Key Management Service (KMS) Activation](#bkmk-managingkms)
|
||||
- [Enterprise Environment](#bkmk-enterpriseenvironment)
|
||||
- [VAMT User Interface](#bkmk-userinterface)
|
||||
|
||||
## <a href="" id="bkmk-managingmak"></a>Managing Multiple Activation Key (MAK) and Retail Activation
|
||||
## <a href="" id="bkmk-managingmak"></a>Managing MAK and retail activation
|
||||
|
||||
You can use a MAK or a retail product key to activate Windows, Windows Server, or Office on an individual computer or a group of computers. VAMT enables two different activation scenarios:
|
||||
|
||||
- **Online activation.** Many enterprises maintain a single Windows system image or Office installation package for deployment across the enterprise. Occasionally there is also a need to use retail product keys in special situations. Online activation enables you to activate over the Internet any products installed with MAK, KMS host, or retail product keys on one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
|
||||
- **Proxy activation.** This activation method enables you to perform volume activation for products installed on client computers that do not have Internet access. The VAMT host computer distributes a MAK, KMS Host key (CSVLK), or retail product key to one or more client products and collects the installation ID (IID) from each client product. The VAMT host sends the IIDs to Microsoft on behalf of the client products and obtains the corresponding Confirmation IDs (CIDs). The VAMT host then installs the CIDs on the client products to complete the activation. Using this method, only the VAMT host computer needs Internet access. You can also activate products installed on computers in a workgroup that is isolated from any larger network, by installing a second instance of VAMT on a computer within the workgroup. Then, use removable media to transfer activation data between this new instance of VAMT and the Internet-connected VAMT host.
|
||||
- **Online activation**: Many organizations maintain a single Windows system image or Office installation package for deployment across the organization. Occasionally there's also a need to use retail product keys in special situations. Online activation enables you to activate over the internet any products installed with MAK, KMS host, or retail product keys on one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
|
||||
|
||||
## <a href="" id="bkmk-managingkms"></a>Managing Key Management Service (KMS) Activation
|
||||
- **Proxy activation**: This activation method enables you to perform volume activation for products installed on client computers that don't have internet access. The VAMT host computer distributes a MAK, KMS host key (CSVLK), or retail product key to one or more client products and collects the installation ID (IID) from each client product. The VAMT host sends the IIDs to Microsoft on behalf of the client products and obtains the corresponding Confirmation IDs (CIDs). The VAMT host then installs the CIDs on the client products to complete the activation. Using this method, only the VAMT host computer needs internet access. You can also activate products installed on computers in a workgroup that's isolated from any larger network, by installing a second instance of VAMT on a computer within the workgroup. Then, use removable media to transfer activation data between this new instance of VAMT and the internet-connected VAMT host.
|
||||
|
||||
In addition to MAK or retail activation, you can use VAMT to perform volume activation using the Key Management Service (KMS). VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by Volume License editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 and Microsoft Office 2010.\
|
||||
VAMT treats a KMS Host key (CSVLK) product key identically to a retail-type product key; therefore, the experience for product key entry and activation management are identical for both these product key types.
|
||||
## <a href="" id="bkmk-managingkms"></a>Managing KMS activation
|
||||
|
||||
## <a href="" id="bkmk-enterpriseenvironment"></a>Enterprise Environment
|
||||
In addition to MAK or retail activation, you can use VAMT to perform volume activation using the KMS. VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by volume license editions of Windows, Windows Server, and Office.
|
||||
|
||||
VAMT is commonly implemented in enterprise environments. The following screenshot illustrates three common environments—Core Network, Secure Zone, and Isolated Lab.
|
||||
VAMT treats a KMS host key (CSVLK) product key identically to a retail-type product key. The experience for product key entry and activation management are identical for both these product key types.
|
||||
|
||||
## <a href="" id="bkmk-enterpriseenvironment"></a>Enterprise environment
|
||||
|
||||
VAMT is commonly implemented in enterprise environments. The following screenshot illustrates three common environments: core network, secure zone, and isolated lab.
|
||||
|
||||
|
||||
|
||||
In the Core Network environment, all computers are within a common network managed by Active Directory® Domain Services (AD DS). The Secure Zone represents higher-security Core Network computers that have extra firewall protection.
|
||||
The Isolated Lab environment is a workgroup that is physically separate from the Core Network, and its computers do not have Internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the Isolated Lab.
|
||||
- In the core network environment, all computers are within a common network managed by Active Directory Domain Services (AD DS).
|
||||
- The secure zone represents higher-security core network computers that have extra firewall protection.
|
||||
- The isolated lab environment is a workgroup that is physically separate from the core network, and its computers don't have internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the isolated lab.
|
||||
|
||||
## <a href="" id="bkmk-userinterface"></a>VAMT User Interface
|
||||
## <a href="" id="bkmk-userinterface"></a>VAMT user interface
|
||||
|
||||
The following screenshot shows the VAMT graphical user interface.
|
||||
The following screenshot shows the VAMT graphical user interface:
|
||||
|
||||
|
||||
|
||||
VAMT provides a single, graphical user interface for managing activations, and for performing other activation-related tasks such as:
|
||||
|
||||
- **Adding and removing computers.** You can use VAMT to discover computers in the local environment. VAMT can discover computers by querying AD DS, workgroups, by individual computer name or IP address, or via a general LDAP query.
|
||||
- **Discovering products.** You can use VAMT to discover Windows, Windows Server, Office, and select other products installed on the client computers.
|
||||
- **Monitoring activation status.** You can collect activation information about each product, including the last five characters of the product key being used, the current license state (such as Licensed, Grace, Unlicensed), and the product edition information.
|
||||
- **Managing product keys.** You can store multiple product keys and use VAMT to install these keys to remote client products. You can also determine the number of activations remaining for MAKs.
|
||||
- **Managing activation data.** VAMT stores activation data in a SQL database. VAMT can export this data to other VAMT hosts or to an archive in XML format.
|
||||
- **Adding and removing computers**: You can use VAMT to discover computers in the local environment. VAMT can discover computers by querying AD DS, workgroups, by individual computer name or IP address, or via a general LDAP query.
|
||||
|
||||
## Related topics
|
||||
- **Discovering products**: You can use VAMT to discover Windows, Windows Server, Office, and select other products installed on the client computers.
|
||||
|
||||
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
|
||||
- **Monitoring activation status**: You can collect activation information about each product, including the last five characters of the product key being used, the current license state (such as Licensed, Grace, Unlicensed), and the product edition information.
|
||||
|
||||
- **Managing product keys**: You can store multiple product keys and use VAMT to install these keys to remote client products. You can also determine the number of activations remaining for MAKs.
|
||||
|
||||
- **Managing activation data**: VAMT stores activation data in a SQL database. VAMT can export this data to other VAMT hosts or to an archive in XML format.
|
||||
|
||||
## Next steps
|
||||
|
||||
[VAMT step-by-step scenarios](vamt-step-by-step.md)
|
||||
|
||||
@ -1,40 +1,36 @@
|
||||
---
|
||||
title: Volume Activation Management Tool (VAMT) Technical Reference (Windows 10)
|
||||
title: VAMT technical reference
|
||||
description: The Volume Activation Management Tool (VAMT) enables network administrators to automate and centrally manage volume activation and retail activation.
|
||||
manager: dougeby
|
||||
ms.author: aaroncz
|
||||
ms.prod: w10
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-deploy
|
||||
author: aczechowski
|
||||
ms.date: 04/25/2017
|
||||
ms.topic: article
|
||||
ms.date: 09/16/2022
|
||||
ms.topic: overview
|
||||
ms.custom: seo-marvel-apr2020
|
||||
ms.collection: highpri
|
||||
---
|
||||
|
||||
# Volume Activation Management Tool (VAMT) Technical Reference
|
||||
# Volume Activation Management Tool (VAMT) technical reference
|
||||
|
||||
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office, and select other Microsoft products volume and retail-activation process.
|
||||
VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in that requires the Microsoft Management Console (MMC) 3.0. VAMT can be installed on any computer that has one of the following Windows operating systems:
|
||||
- Windows® 7 or above
|
||||
- Windows Server 2008 R2 or above
|
||||
The Volume Activation Management Tool (VAMT) lets you automate and centrally manage the Windows, Office, and select other Microsoft products volume and retail-activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in. VAMT can be installed on any computer that has a supported Windows OS version.
|
||||
|
||||
|
||||
**Important**
|
||||
VAMT is designed to manage volume activation for: Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 (or later), Microsoft Office 2010 (or above).
|
||||
> [!IMPORTANT]
|
||||
> VAMT is designed to manage volume activation for supported versions of Windows, Windows Server, and Office.
|
||||
|
||||
VAMT is only available in an EN-US (x86) package.
|
||||
|
||||
## In this section
|
||||
|
||||
|Topic |Description |
|
||||
|Article |Description |
|
||||
|------|------------|
|
||||
|[Introduction to VAMT](introduction-vamt.md) |Provides a description of VAMT and common usages. |
|
||||
|[Active Directory-Based Activation Overview](active-directory-based-activation-overview.md) |Describes Active Directory-Based Activation scenarios. |
|
||||
|[Install and Configure VAMT](install-configure-vamt.md) |Describes how to install VAMT and use it to configure client computers on your network. |
|
||||
|[Add and Manage Products](add-manage-products-vamt.md) |Describes how to add client computers into VAMT. |
|
||||
|[Manage Product Keys](manage-product-keys-vamt.md) |Describes how to add and remove a product key from VAMT. |
|
||||
|[Manage Activations](manage-activations-vamt.md) |Describes how to activate a client computer by using a variety of activation methods. |
|
||||
|[Manage VAMT Data](manage-vamt-data.md) |Describes how to save, import, export, and merge a Computer Information List (CILX) file using VAMT. |
|
||||
|[VAMT Step-by-Step Scenarios](vamt-step-by-step.md) |Provides step-by-step instructions for using VAMT in typical environments. |
|
||||
|[VAMT Known Issues](vamt-known-issues.md) |Lists known issues in VAMT. |
|
||||
|
||||
|[Active Directory-based activation overview](active-directory-based-activation-overview.md) |Describes Active Directory-based activation scenarios. |
|
||||
|[Install and configure VAMT](install-configure-vamt.md) |Describes how to install VAMT and use it to configure client computers on your network. |
|
||||
|[Add and manage products](add-manage-products-vamt.md) |Describes how to add client computers into VAMT. |
|
||||
|[Manage product keys](manage-product-keys-vamt.md) |Describes how to add and remove a product key from VAMT. |
|
||||
|[Manage activations](manage-activations-vamt.md) |Describes how to activate a client computer by using various activation methods. |
|
||||
|[Manage VAMT data](manage-vamt-data.md) |Describes how to save, import, export, and merge a Computer Information List (CILX) file using VAMT. |
|
||||
|[VAMT step-by-step scenarios](vamt-step-by-step.md) |Provides step-by-step instructions for using VAMT in typical environments. |
|
||||
|[VAMT known issues](vamt-known-issues.md) |Lists known issues in VAMT. |
|
||||
|
||||
@ -32,6 +32,8 @@
|
||||
href: deploy/windows-autopatch-device-registration-overview.md
|
||||
- name: Register your devices
|
||||
href: deploy/windows-autopatch-register-devices.md
|
||||
- name: Post-device registration readiness checks
|
||||
href: deploy/windows-autopatch-post-reg-readiness-checks.md
|
||||
- name: Operate
|
||||
href: operate/index.md
|
||||
items:
|
||||
|
||||
@ -0,0 +1,99 @@
|
||||
---
|
||||
title: Post-device registration readiness checks
|
||||
description: This article details how post-device registration readiness checks are performed in Windows Autopatch
|
||||
ms.date: 09/15/2022
|
||||
ms.prod: w11
|
||||
ms.technology: windows
|
||||
ms.topic: conceptual
|
||||
ms.localizationpriority: medium
|
||||
author: tiaraquan
|
||||
ms.author: tiaraquan
|
||||
manager: dougeby
|
||||
msreviewer: andredm7
|
||||
---
|
||||
|
||||
# Post-device registration readiness checks
|
||||
|
||||
One of the most expensive aspects of the software update management process is to make sure devices are always healthy to receive and report software updates for each software update release cycle.
|
||||
|
||||
Having a way of measuring, quickly detecting and remediating when something goes wrong with on-going change management processes is important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results.
|
||||
|
||||
Windows Autopatch provides proactive device readiness information about devices that are and aren't ready to be fully managed by the service. IT admins can easily detect and fix device-related issues that are preventing them from achieving their update management compliance report goals.
|
||||
|
||||
## Device readiness scenarios
|
||||
|
||||
Device readiness in Windows Autopatch is divided into two different scenarios:
|
||||
|
||||
| Scenario | Description |
|
||||
| ----- | ----- |
|
||||
| Prerequisite checks | Ensures devices follow software-based requirements before being registered with the service. |
|
||||
| Post-device registration readiness checks | Provides continuous monitoring of device health for registered devices.<p>IT admins can easily detect and remediate configuration mismatches in their environments or issues that prevent devices from having one or more software update workloads (Windows quality, feature updates, Microsoft Office, Microsoft Teams, or Microsoft Edge) fully managed by the Windows Autopatch service. Configuration mismatches can leave devices in a vulnerable state, out of compliance and exposed to security threats.</p>|
|
||||
|
||||
### Device readiness checks available for each scenario
|
||||
|
||||
| Required device readiness (prerequisite checks) prior to device registration (powered by Intune Graph API) | Required post-device registration readiness checks (powered by Microsoft Cloud Managed Desktop Extension) |
|
||||
| ----- | ----- |
|
||||
| <ul><li>Windows OS (build, architecture and edition)</li></li><li>Managed by either Intune or ConfigMgr co-management</li><li>ConfigMgr co-management workloads</li><li>Last communication with Intune</li><li>Personal or non-Windows devices</li></ul> | <ul><li>Windows OS (build, architecture and edition)</li><li>Windows updates & Office Group Policy Object (GPO) versus Intune mobile device management (MDM) policy conflict</li><li>Bind network endpoints (Microsoft Defender, Microsoft Teams, Microsoft Edge, Microsoft Office)</li><li>Internet connectivity</li></ul> |
|
||||
|
||||
The status of each post-device registration readiness check is shown in the Windows Autopatch’s Devices blade under the **Not ready** tab. You can take appropriate action(s) on devices that aren't ready to be fully managed by the Windows Autopatch service.
|
||||
|
||||
## About the three tabs in the Devices blade
|
||||
|
||||
You deploy software updates to secure your environment, but these deployments only reach healthy and active devices. Unhealthy or not ready devices affect the overall software update compliance. Figuring out device health can be challenging and disruptive to the end user when IT can’t obtain proactive data sent by the device to the service for IT admins to proactively detect, troubleshoot, and fix issues.
|
||||
|
||||
Windows Autopatch has three tabs within its Devices blade. Each tab is designed to provide a different set of device readiness statuses so IT admins know where to go to monitor, and troubleshoot potential device health issues:
|
||||
|
||||
| Tab | Description |
|
||||
| ----- | ----- |
|
||||
| Ready | This tab only lists devices with the **Active** status. Devices with the **Active** status successfully:<ul><li>Passed the prerequisite checks.</li><li>Registered with Windows Autopatch.</li></ul>This tab also lists devices that have passed all postdevice registration readiness checks. |
|
||||
| Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status.<ul><li>**Readiness failed status**: Devices that didn’t pass one or more post-device registration readiness checks.</li><li>**Inactive**: Devices that haven’t communicated with the Microsoft Endpoint Manager-Intune service in the last 28 days.</li></ul> |
|
||||
| Not registered | Only lists devices with the **Prerequisite failed** status in it. Devices with the **Prerequisite failed** status didn’t pass one or more prerequisite checks during the device registration process. |
|
||||
|
||||
## Details about the post-device registration readiness checks
|
||||
|
||||
A healthy or active device in Windows Autopatch is:
|
||||
|
||||
- Online
|
||||
- Actively sending data
|
||||
- Passes all post-device registration readiness checks
|
||||
|
||||
The post-device registration readiness checks are powered by the **Microsoft Cloud Managed Desktop Extension**. It's installed right after devices are successfully registered with Windows Autopatch. The **Microsoft Cloud Managed Desktop Extension** has the Device Readiness Check Plugin responsible for performing the readiness checks in devices and report back to the service. The **Microsoft Cloud Managed Desktop Extension** is a subcomponent of the overall Windows Autopatch service.
|
||||
|
||||
The following list of post-device registration readiness checks is performed in Windows Autopatch:
|
||||
|
||||
| Check | Description |
|
||||
| ----- | ----- |
|
||||
| **Windows OS build, architecture, and edition** | Checks to see if devices support Windows 1809+ build (10.0.17763), 64-bit architecture and either Pro or Enterprise SKUs. |
|
||||
| **Windows update policies managed via Microsoft Endpoint Manager-Intune** | Checks to see if devices have Windows Updates policies managed via Microsoft Endpoint Manager-Intune (MDM). |
|
||||
| **Windows update policies managed via Group Policy Object (GPO)** | Checks to see if devices have Windows update policies managed via GPO. Windows Autopatch doesn’t support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Endpoint Manager-Intune. |
|
||||
| **Microsoft Office update policy managed via Group Policy Object (GPO)** | Checks to see if devices have Microsoft Office updates policies managed via GPO. Windows Autopatch doesn’t support Microsoft Office update policies managed via GPOs. Office updates must be managed via Microsoft Endpoint Manager-Intune or another Microsoft Office policy management method where Office update bits are downloaded directly from the Office Content Delivery Network (CDN). |
|
||||
| **Windows Autopatch network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that Windows Autopatch services must be able to reach for the various aspects of the Windows Autopatch service. |
|
||||
| **Microsoft Teams network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Teams must be able to reach for software updates management. |
|
||||
| **Microsoft Edge network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Edge must be able to reach for software updates management. |
|
||||
| **Internet connectivity** | Checks to see if a device has internet connectivity to communicate with Microsoft cloud services. Windows Autopatch uses the PingReply class. Windows Autopatch tries to ping at least three different Microsoft’s public URLs two times each, to confirm that ping results aren't coming from the device’s cache. |
|
||||
|
||||
## Daily operations in Windows Autopatch
|
||||
|
||||
See the following end-to-end IT admin operation workflow:
|
||||
|
||||
:::image type="content" source="../media/windows-autopatch-post-device-registration-readiness-checks.png" alt-text="Post-device registration readiness checks" lightbox="../media/windows-autopatch-post-device-registration-readiness-checks.png":::
|
||||
|
||||
| Step | Description |
|
||||
| ----- | ----- |
|
||||
| **Steps 1-7** | For more information, see the [Device registration overview diagram](windows-autopatch-device-registration-overview.md).|
|
||||
| **Step 8: Perform readiness checks** |<ol><li>Once devices are successfully registered with Windows Autopatch, the devices are added to the **Ready** tab.</li><li>The Microsoft Cloud Managed Desktop Extension agent performs readiness checks against devices in the **Ready** tab every 24 hours.</li></ol> |
|
||||
| **Step 9: Check readiness status** |<ol><li>The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.</li><li>The readiness results are sent from the Microsoft Cloud Managed Desktop Extension service component to the Device Readiness component within the Windows Autopatch’s service.</li></ol>|
|
||||
| **Step 10: Add devices to the Not ready** | When devices don’t pass one or more readiness checks, even if they’re registered with Windows Autopatch, they’re added to the **Not ready** tab so IT admins can remediate devices based on Windows Autopatch recommendations. |
|
||||
| **Step 11: IT admin understands what the issue is and remediates** | The IT admin checks and remediates issues in the Devices blade (**Not ready** tab). It can take up to 24 hours for devices to show back up into the **Ready** tab. |
|
||||
|
||||
## FAQ
|
||||
|
||||
| Question | Answer |
|
||||
| ----- | ----- |
|
||||
| **How frequent are the post-device registration readiness checks performed?** |<ul><li>The **Microsoft Cloud Managed Desktop Extension** agent collects device readiness statuses when it runs (once a day).</li><li>Once the agent collects results for the post-device registration readiness checks, it generates readiness results in the device in the `%programdata%\Microsoft\CMDExtension\Plugins\DeviceReadinessPlugin\Logs\DRCResults.json.log`.</li><li>The readiness results are sent over to the **Microsoft Cloud Managed Desktop Extension service**.</li><li>The **Microsoft Cloud Managed Desktop Extension** service component sends the readiness results to the Device Readiness component. The results appear in the Windows Autopatch Devices blade (**Not ready** tab).</li></ul>|
|
||||
| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don’t meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch will provide information about the failure and how to potentially remediate devices.<p>Once devices are remediated, it can take up to **24 hours** to show up in the **Ready** tab.</p>|
|
||||
|
||||
## Additional resources
|
||||
|
||||
- [Device registration overview](windows-autopatch-device-registration-overview.md)
|
||||
- [Register your devices](windows-autopatch-register-devices.md)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 443 KiB |
@ -27,3 +27,7 @@ After you've completed enrollment in Windows Autopatch, some management settings
|
||||
| Setting | Description |
|
||||
| ----- | ----- |
|
||||
| Update rings for Windows 10 or later | For any update rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign update rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).<p>Windows Autopatch will also have created some update ring policies. all of which The policies will have "**Modern Workplace**" in the name. For example:</p><ul><li>Modern Workplace Update Policy [Broad]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [Fast]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [First]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [Test]-[Windows Autopatch]</li></ul><p>When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.</p><p>**To resolve the Not ready result:**</p><p>After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).</p><p>**To resolve the Advisory result:**</p><ol><li>Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.</li> <li>If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).</li></ol><p>For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).</p> |
|
||||
|
||||
## Windows Autopatch configurations
|
||||
|
||||
Windows Autopatch deploys, manages and maintains all configurations related to the operation of the service, as described in [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). Don't make any changes to any of the Windows Autopatch configurations.
|
||||
|
||||
@ -99,7 +99,7 @@ sections:
|
||||
No, you can't customize update scheduling. However, you can specify [active hours](../operate/windows-autopatch-wqu-end-user-exp.md#servicing-window) to prevent users from updating during business hours.
|
||||
- question: Does Autopatch support include and exclude groups, or dynamic groups to define deployment ring membership?
|
||||
answer: |
|
||||
Windows autopatch doesn't support managing update deployment ring membership using your Azure AD groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
|
||||
Windows Autopatch doesn't support managing update deployment ring membership using your Azure AD groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
|
||||
- question: Does Autopatch have two release cadences per update or are there two release cadences per-ring?
|
||||
answer: |
|
||||
The release cadences are defined based on the update type. For example, a [regular cadence](../operate/windows-autopatch-wqu-overview.md#windows-quality-update-releases) (for a Windows quality update would be a gradual rollout from the Test ring to the Broad ring over 14 days whereas an [expedited release](../operate/windows-autopatch-wqu-overview.md#expedited-releases) would roll out more rapidly.
|
||||
|
||||
@ -14,6 +14,11 @@ msreviewer: hathind
|
||||
|
||||
# Changes made at tenant enrollment
|
||||
|
||||
The following configuration details are provided as information to help you understand the changes made to your tenant when enrolling into the Windows Autopatch service.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The service manages and maintains the following configuration items. Don't change, edit, add to, or remove any of the configurations. Doing so might cause unintended configuration conflicts and impact the Windows Autopatch service.
|
||||
|
||||
## Service principal
|
||||
|
||||
Windows Autopatch will create a service principal in your tenant allowing the service to establish an identity and restrict access to what resources the service has access to within the tenant. For more information, see [Application and service principal objects in Azure Active Directory](/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object). The service principal created by Windows Autopatch is:
|
||||
|
||||
@ -78,7 +78,7 @@ To allow facial recognition, you must have devices with integrated special infra
|
||||
- Effective, real world FRR with Anti-spoofing or liveness detection: <10%
|
||||
|
||||
> [!NOTE]
|
||||
>Windows Hello face authentication does not currently support wearing a mask during enrollment or authentication. Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock you device. The product group is aware of this behavior and is investigating this topic further. Please remove a mask if you are wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn’t allow you to remove a mask temporarily, please consider unenrolling from face authentication and only using PIN or fingerprint.
|
||||
>Windows Hello face authentication does not currently support wearing a mask during enrollment or authentication. Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this topic further. Please remove a mask if you are wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn’t allow you to remove a mask temporarily, please consider unenrolling from face authentication and only using PIN or fingerprint.
|
||||
|
||||
|
||||
## Related topics
|
||||
|
||||
@ -38,7 +38,7 @@ The table shows the minimum requirements for each deployment. For key trust in a
|
||||
| **Domain and Forest Functional Level** | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |Windows Server 2008 R2 Domain/Forest functional level |
|
||||
| **Domain Controller Version** | Windows Server 2016 or later | Windows Server 2016 or later | Windows Server 2008 R2 or later | Windows Server 2008 R2 or later |
|
||||
| **Certificate Authority**| N/A | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority |
|
||||
| **AD FS Version** | N/A | N/A | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) (hybrid Azure AD joined clients),<br> and<br/>Windows Server 2012 or later Network Device Enrollment Service (Azure AD joined) | Windows Server 2012 or later Network Device Enrollment Service |
|
||||
| **AD FS Version** | N/A | N/A | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) (hybrid Azure AD joined clients managed by Group Policy),<br> and<br/>Windows Server 2012 or later Network Device Enrollment Service (hybrid Azure AD joined & Azure AD joined managed by MDM) | Windows Server 2012 or later Network Device Enrollment Service |
|
||||
| **MFA Requirement** | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter |
|
||||
| **Azure AD Connect** | N/A | Required | Required | Required |
|
||||
| **Azure AD License** | Azure AD Premium, optional | Azure AD Premium, optional | Azure AD Premium, needed for device write-back | Azure AD Premium, optional. Intune license required |
|
||||
|
||||
@ -1,21 +1,15 @@
|
||||
---
|
||||
title: Understanding Windows Defender Application Control (WDAC) secure settings
|
||||
description: Learn about secure settings in Windows Defender Application Control.
|
||||
keywords: security, malware
|
||||
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
|
||||
ms.prod: m365-security
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-security
|
||||
ms.localizationpriority: medium
|
||||
audience: ITPro
|
||||
ms.collection: M365-security-compliance
|
||||
author: jgeurten
|
||||
ms.reviewer: jgeurten
|
||||
ms.author: dansimp
|
||||
manager: dansimp
|
||||
ms.reviewer: vinpa
|
||||
ms.author: jogeurte
|
||||
manager: aaroncz
|
||||
ms.date: 10/11/2021
|
||||
ms.technology: mde
|
||||
---
|
||||
|
||||
# Understanding WDAC Policy Settings
|
||||
|
||||
@ -84,3 +84,38 @@ As Windows 10 boots, a series of integrity measurements are taken by Windows Def
|
||||
|
||||
After the system boots, Windows Defender System Guard signs and seals these measurements using the TPM. Upon request, a management system like Intune or Microsoft Endpoint Configuration Manager can acquire them for remote analysis. If Windows Defender System Guard indicates that the device lacks integrity, the management system can take a series of actions, such as denying the device access to resources.
|
||||
|
||||
## System requirements for System Guard
|
||||
|
||||
|For Intel® vPro™ processors starting with Intel® Coffeelake, Whiskeylake, or later silicon|Description|
|
||||
|--------|-----------|
|
||||
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more information about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|
||||
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs aren't supported, except Intel chips that support Platform Trust Technology (PTT), which is a type of integrated hardware TPM that meets the TPM 2.0 spec.|
|
||||
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|
||||
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|
||||
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>Must allow ONLY that TSEG pages can be marked executable and the memory map must report TSEG EfiReservedMemoryType. <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|
||||
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|
||||
|TPM AUX Index|Platform must set up a AUX index with index, attributes, and policy that exactly corresponds to the AUX index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data). (NameAlg = SHA256) <br/> Platforms must set up a PS (Platform Supplier) index with: <ul><li> Exactly the "TXT PS2" style Attributes on creation as follows: <ul><li>AuthWrite</li><li>PolicyDelete</li><li>WriteLocked</li><li>WriteDefine</li><li>AuthRead</li><li>WriteDefine</li><li>NoDa</li><li>Written</li><li>PlatformCreate</li></ul> <li>A policy of exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)</li><li> Size of exactly 70 bytes </li><li> NameAlg = SHA256 </li><li> Also, it must have been initialized and locked (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) at time of OS launch. </li></ul> PS index data DataRevocationCounters, SINITMinVersion, and PolicyControl must all be 0x00 |
|
||||
|AUX Policy|The required AUX policy must be as follows: <ul><li> A = TPM2_PolicyLocality (Locality 3 & Locality 4) </li><li>B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)</li><li>authPolicy = \{A} OR {{A} AND \{B}}</li><li>authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24</li></ul>|
|
||||
|TPM NV Index|Platform firmware must set up a TPM NV index for use by the OS with: <ul><li>Handle: 0x01C101C0 </li><li>Attributes: <ul><li>TPMA_NV_POLICYWRITE</li><li>TPMA_NV_PPREAD </li><li>TPMA_NV_OWNERREAD</li><li>TPMA_NV_AUTHREAD</li><li>TPMA_NV_POLICYREAD</li><li>TPMA_NV_NO_DA</li><li>TPMA_NV_PLATFORMCREATE</li><li>TPMA_NV_POLICY_DELETE</li></ul> <li>A policy of: </li><ul><li>A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)</li><li>B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial) </li><li> authPolicy = \{A} OR {{A} AND \{B}} </li><li> Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1 </li></ul></ul> |
|
||||
|Platform firmware|Platform firmware must carry all code required to execute an Intel® Trusted Execution Technology secure launch: <ul><li>Intel® SINIT ACM must be carried in the OEM BIOS</li><li>Platforms must ship with a production ACM signed by the correct production Intel® ACM signer for the platform</li></ul>|
|
||||
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
|
||||
|
||||
|For AMD® processors starting with Zen2 or later silicon|Description|
|
||||
|--------|-----------|
|
||||
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more information about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|
||||
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0 OR Microsoft Pluton TPM.|
|
||||
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|
||||
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|
||||
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|
||||
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|
||||
|TPM NV Index|Platform firmware must set up a TPM NV index for use by the OS with: <ul><li>Handle: 0x01C101C0 </li><li>Attributes: <ul><li>TPMA_NV_POLICYWRITE</li><li>TPMA_NV_PPREAD </li><li>TPMA_NV_OWNERREAD</li><li>TPMA_NV_AUTHREAD</li><li>TPMA_NV_POLICYREAD</li><li>TPMA_NV_NO_DA</li><li>TPMA_NV_PLATFORMCREATE</li><li>TPMA_NV_POLICY_DELETE</li></ul> <li>A policy of: </li><ul><li>A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)</li><li>B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial) </li><li> authPolicy = \{A} OR {{A} AND \{B}} </li><li> Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1 </li></ul></ul> |
|
||||
|Platform firmware|Platform firmware must carry all code required to execute Secure Launch: <ul><li>AMD® Secure Launch platforms must ship with AMD® DRTM driver devnode exposed and the AMD® DRTM driver installed</li></ul><br/>Platform must have AMD® Secure Processor Firmware Anti-Rollback protection enabled <br/> Platform must have AMD® Memory Guard enabled.|
|
||||
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
|
||||
|
||||
|For Qualcomm® processors with SD850 or later chipsets|Description|
|
||||
|--------|-----------|
|
||||
|Monitor Mode Communication|All Monitor Mode communication buffers must be implemented in either EfiRuntimeServicesData (recommended), data sections of EfiRuntimeServicesCode as described by the Memory Attributes Table, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types|
|
||||
|Monitor Mode Page Tables|All Monitor Mode page tables must: <ul><li>NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory) </li><li>They must NOT have execute and write permissions for the same page </li><li>Platforms must only allow Monitor Mode pages marked as executable </li><li>The memory map must report Monitor Mode as EfiReservedMemoryType</li><li>Platforms must provide mechanism to protect the Monitor Mode page tables from modification</li></ul> |
|
||||
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|
||||
|Platform firmware|Platform firmware must carry all code required to launch.|
|
||||
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
|
||||
|
||||
@ -72,43 +72,7 @@ To verify that Secure Launch is running, use System Information (MSInfo32). Clic
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> To enable System Guard Secure launch, the platform must meet all the baseline requirements for [Device Guard](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md), [Credential Guard](../../identity-protection/credential-guard/credential-guard-requirements.md), and [Virtualization Based Security](/windows-hardware/design/device-experiences/oem-vbs).
|
||||
|
||||
## System requirements for System Guard
|
||||
|
||||
|For Intel® vPro™ processors starting with Intel® Coffeelake, Whiskeylake, or later silicon|Description|
|
||||
|--------|-----------|
|
||||
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more information about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|
||||
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs aren't supported, except Intel chips that support Platform Trust Technology (PTT), which is a type of integrated hardware TPM that meets the TPM 2.0 spec.|
|
||||
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|
||||
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|
||||
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>Must allow ONLY that TSEG pages can be marked executable and the memory map must report TSEG EfiReservedMemoryType. <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|
||||
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|
||||
|TPM AUX Index|Platform must set up a AUX index with index, attributes, and policy that exactly corresponds to the AUX index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data). (NameAlg = SHA256) <br/> Platforms must set up a PS (Platform Supplier) index with: <ul><li> Exactly the "TXT PS2" style Attributes on creation as follows: <ul><li>AuthWrite</li><li>PolicyDelete</li><li>WriteLocked</li><li>WriteDefine</li><li>AuthRead</li><li>WriteDefine</li><li>NoDa</li><li>Written</li><li>PlatformCreate</li></ul> <li>A policy of exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)</li><li> Size of exactly 70 bytes </li><li> NameAlg = SHA256 </li><li> Also, it must have been initialized and locked (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) at time of OS launch. </li></ul> PS index data DataRevocationCounters, SINITMinVersion, and PolicyControl must all be 0x00 |
|
||||
|AUX Policy|The required AUX policy must be as follows: <ul><li> A = TPM2_PolicyLocality (Locality 3 & Locality 4) </li><li>B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)</li><li>authPolicy = \{A} OR {{A} AND \{B}}</li><li>authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24</li></ul>|
|
||||
|TPM NV Index|Platform firmware must set up a TPM NV index for use by the OS with: <ul><li>Handle: 0x01C101C0 </li><li>Attributes: <ul><li>TPMA_NV_POLICYWRITE</li><li>TPMA_NV_PPREAD </li><li>TPMA_NV_OWNERREAD</li><li>TPMA_NV_AUTHREAD</li><li>TPMA_NV_POLICYREAD</li><li>TPMA_NV_NO_DA</li><li>TPMA_NV_PLATFORMCREATE</li><li>TPMA_NV_POLICY_DELETE</li></ul> <li>A policy of: </li><ul><li>A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)</li><li>B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial) </li><li> authPolicy = \{A} OR {{A} AND \{B}} </li><li> Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1 </li></ul></ul> |
|
||||
|Platform firmware|Platform firmware must carry all code required to execute an Intel® Trusted Execution Technology secure launch: <ul><li>Intel® SINIT ACM must be carried in the OEM BIOS</li><li>Platforms must ship with a production ACM signed by the correct production Intel® ACM signer for the platform</li></ul>|
|
||||
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
|
||||
|
||||
|For AMD® processors starting with Zen2 or later silicon|Description|
|
||||
|--------|-----------|
|
||||
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more information about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more information about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|
||||
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0 OR Microsoft Pluton TPM.|
|
||||
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|
||||
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|
||||
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|
||||
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|
||||
|TPM NV Index|Platform firmware must set up a TPM NV index for use by the OS with: <ul><li>Handle: 0x01C101C0 </li><li>Attributes: <ul><li>TPMA_NV_POLICYWRITE</li><li>TPMA_NV_PPREAD </li><li>TPMA_NV_OWNERREAD</li><li>TPMA_NV_AUTHREAD</li><li>TPMA_NV_POLICYREAD</li><li>TPMA_NV_NO_DA</li><li>TPMA_NV_PLATFORMCREATE</li><li>TPMA_NV_POLICY_DELETE</li></ul> <li>A policy of: </li><ul><li>A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)</li><li>B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial) </li><li> authPolicy = \{A} OR {{A} AND \{B}} </li><li> Digest value of 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23, 0x1c, 0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1 </li></ul></ul> |
|
||||
|Platform firmware|Platform firmware must carry all code required to execute Secure Launch: <ul><li>AMD® Secure Launch platforms must ship with AMD® DRTM driver devnode exposed and the AMD® DRTM driver installed</li></ul><br/>Platform must have AMD® Secure Processor Firmware Anti-Rollback protection enabled <br/> Platform must have AMD® Memory Guard enabled.|
|
||||
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
|
||||
|
||||
|For Qualcomm® processors with SD850 or later chipsets|Description|
|
||||
|--------|-----------|
|
||||
|Monitor Mode Communication|All Monitor Mode communication buffers must be implemented in either EfiRuntimeServicesData (recommended), data sections of EfiRuntimeServicesCode as described by the Memory Attributes Table, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types|
|
||||
|Monitor Mode Page Tables|All Monitor Mode page tables must: <ul><li>NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory) </li><li>They must NOT have execute and write permissions for the same page </li><li>Platforms must only allow Monitor Mode pages marked as executable </li><li>The memory map must report Monitor Mode as EfiReservedMemoryType</li><li>Platforms must provide mechanism to protect the Monitor Mode page tables from modification</li></ul> |
|
||||
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|
||||
|Platform firmware|Platform firmware must carry all code required to launch.|
|
||||
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
|
||||
> To enable System Guard Secure launch, the platform must meet all the baseline requirements for [System Guard](../windows-defender-system-guard/system-guard-how-hardware-based-root-of-trust-helps-protect-windows.md), [Device Guard](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md), [Credential Guard](../../identity-protection/credential-guard/credential-guard-requirements.md), and [Virtualization Based Security](/windows-hardware/design/device-experiences/oem-vbs).
|
||||
|
||||
> [!NOTE]
|
||||
> For more information around AMD processors, see [Microsoft Security Blog: Force firmware code to be measured and attested by Secure Launch on Windows 10](https://www.microsoft.com/security/blog/2020/09/01/force-firmware-code-to-be-measured-and-attested-by-secure-launch-on-windows-10/).
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user