Merge pull request #7628 from paolomatarazzo/pm-20221208-whfb

[WHFB] includes updates
2025-05-12 13:27:23 +00:00 · 2022-12-15 10:56:11 -06:00 · 2022-12-15 10:56:11 -06:00 · 0ffb7222df
commit 0ffb7222df
parent 4e4ce8e664 834b408f2d
81 changed files with 1397 additions and 1548 deletions
--- a/windows/security/identity-protection/access-control/access-control.md
+++ b/windows/security/identity-protection/access-control/access-control.md
@ -6,7 +6,7 @@ ms.topic: article
 ms.date: 11/22/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.technology: itpro-security
 ---
--- a/windows/security/identity-protection/access-control/local-accounts.md
+++ b/windows/security/identity-protection/access-control/local-accounts.md
@ -7,7 +7,7 @@ ms.collection:
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.technology: itpro-security
 ---
--- a/windows/security/identity-protection/credential-guard/additional-mitigations.md
+++ b/windows/security/identity-protection/credential-guard/additional-mitigations.md
@ -5,7 +5,7 @@ ms.date: 08/17/2017
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Additional mitigations
--- a/windows/security/identity-protection/credential-guard/credential-guard-considerations.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-considerations.md
@ -5,7 +5,7 @@ ms.date: 08/31/2017
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Considerations when using Windows Defender Credential Guard
--- a/windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-how-it-works.md
@ -5,7 +5,7 @@ ms.date: 08/17/2017
 ms.topic: conceptual
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # How Windows Defender Credential Guard works
--- a/windows/security/identity-protection/credential-guard/credential-guard-known-issues.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-known-issues.md
@ -5,7 +5,7 @@ ms.topic: article
 ms.date: 11/28/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Windows Defender Credential Guard: Known issues
--- a/windows/security/identity-protection/credential-guard/credential-guard-manage.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-manage.md
@ -7,7 +7,7 @@ ms.collection:
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Manage Windows Defender Credential Guard
--- a/windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-not-protected-scenarios.md
@ -5,7 +5,7 @@ ms.topic: article
 ms.date: 08/17/2017
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Windows Defender Credential Guard protection limits and mitigations
--- a/windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-protection-limits.md
@ -5,7 +5,7 @@ ms.date: 08/17/2017
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Windows Defender Credential Guard protection limits
--- a/windows/security/identity-protection/credential-guard/credential-guard-requirements.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-requirements.md
@ -5,7 +5,7 @@ ms.date: 12/27/2021
 ms.topic: article
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Windows Defender Credential Guard requirements
--- a/windows/security/identity-protection/credential-guard/credential-guard-scripts.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard-scripts.md
@ -5,7 +5,7 @@ ms.date: 11/22/2022
 ms.topic: reference
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Windows Defender Credential Guard: scripts for certificate authority issuance policies
--- a/windows/security/identity-protection/credential-guard/credential-guard.md
+++ b/windows/security/identity-protection/credential-guard/credential-guard.md
@ -7,7 +7,7 @@ ms.collection:
  - highpri
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Protect derived domain credentials with Windows Defender Credential Guard
--- a/windows/security/identity-protection/credential-guard/dg-readiness-tool.md
+++ b/windows/security/identity-protection/credential-guard/dg-readiness-tool.md
@ -5,7 +5,7 @@ ms.date: 11/22/2022
 ms.topic: reference
 appliesto:
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool
--- a/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
+++ b/windows/security/identity-protection/hello-for-business/hello-aad-join-cloud-only-deploy.md
@ -1,12 +1,12 @@
 ---
-title: Azure Active Directory join cloud only deployment
+title: Windows Hello for Business cloud-only deployment
-description: Use this deployment guide to successfully use Azure Active Directory to join a Windows 10 or Windows 11 device.
+description: Learn how to configure Windows Hello for Business in a cloud-only deployment scenario.
 ms.date: 06/23/2021
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.topic: article
 ---
-# Azure Active Directory join cloud only deployment
+# Cloud-only deployment
 [!INCLUDE [hello-hybrid-key-trust](../../includes/hello-cloud.md)]
@ -17,7 +17,7 @@ When you Azure Active Directory (Azure AD) join a Windows device, the system pro
 You may wish to disable the automatic Windows Hello for Business enrollment prompts if you aren't ready to use it in your environment. Instructions on how to disable Windows Hello for Business enrollment in a cloud only environment are included below.
 > [!NOTE]
-> During the out-of-box experience (OOBE) flow of an Azure AD join, you will see a provisioning PIN when you don’t have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
+> During the out-of-box experience (OOBE) flow of an Azure AD join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts.
 ## Prerequisites
@ -25,7 +25,7 @@ Cloud only deployments will use Azure AD multi-factor authentication (MFA) durin
 The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](hello-identity-verification.md#azure-ad-cloud-only-deployment).
-Also note that it's possible for federated domains to enable the “Supports MFA” flag in your federated domain settings. This flag tells Azure AD that the federated IDP will perform the MFA challenge.
+Also note that it's possible for federated domains to enable the *Supports MFA* flag in your federated domain settings. This flag tells Azure AD that the federated IDP will perform the MFA challenge.
 Check and view this setting with the following MSOnline PowerShell command:
--- a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
+++ b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md
@ -4,7 +4,7 @@ description: Guide for planning to have an adequate number of Windows Server 201
 ms.date: 08/20/2018
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: article
 ---
 # Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-adfs.md
@ -1,487 +1,263 @@
 ---
-title: Prepare and Deploy Windows AD FS certificate trust (Windows Hello for Business)
+title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust
-description: Learn how to Prepare and Deploy Windows Server 2016 Active Directory Federation Services (AD FS) for Windows Hello for Business, using certificate trust.
+description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business certificate trust model.
-ms.date: 01/14/2021
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# Prepare and Deploy Active Directory Federation Services (AD FS)
+# Prepare and deploy Active Directory Federation Services - on-premises certificate trust
-Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS).  The on-premises certificate trust deployment uses Active Directory Federation Services roles for key registration, device registration, and as a certificate registration authority.
+[!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using the Windows Information Database as the configuration database, which is ideal for environments with no more than 30 federation servers and no more than 100 relying party trusts.
+Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises certificate trust deployment model uses AD FS for *certificate enrollment* and *device registration*.
-If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay detection, or needs Active Directory Federation Services to operate in a federated provider role, then your deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation Services using SQL as its configuration database, please review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
+The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
 WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
 To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
-If your environment has an existing instance of Active Directory Federation Services, then you’ll need to upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update.  If your environment uses Windows Internal Database (WID) for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 using a WID database](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) to upgrade your environment.  If your environment uses SQL for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 with SQL Server](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016-sql) to upgrade your environment.
+A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
-Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully completed the upgrade. 
+Prepare the AD FS deployment by installing and **updating** two Windows Servers.
-A new Active Directory Federation Services farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with an external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
+## Enroll for a TLS server authentication certificate
-Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server 2016 Servers.  Ensure the update listed below is applied to each server before continuing.
+Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
-> [!NOTE]
+The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
-> For AD FS 2019, if Windows Hello for Business with a Hybrid Certificate trust is performed, a known PRT issue exists. You may encounter this error in ADFS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'. To remediate this error:
+ - **Subject Name**: the internal FQDN of the federation server
->
+ - **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
 > 1. Launch AD FS management console. Browse to "Services > Scope Descriptions".
 > 2. Right click "Scope Descriptions" and select "Add Scope Description".
 > 3. Under name type "ugs" and Click Apply > OK.
 > 4. Launch PowerShell as an administrator.
 > 5. Get the ObjectIdentifier of the application permission with the ClientRoleIdentifier parameter equal to "38aa3b87-a06d-4817-b275-7a316988d93b":
 > ```PowerShell
 > (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
 > ```
 > 6. Execute the command `Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'`.
 > 7. Restart the AD FS service.
 > 8. On the client: Restart the client. User should be prompted to provision Windows Hello for Business.
-## Update Windows Server 2016
+The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
-Sign-in the federation server with _local admin_ equivalent credentials.
+You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
 1. Ensure Windows Server 2016 is current by running **Windows Update** from **Settings**. Continue this process until no further updates are needed. If you’re not using Windows Update for updates, please advise the [Windows Server 2016 update history page](https://support.microsoft.com/help/4000825/windows-10-windows-server-2016-update-history) to make sure you have the latest updates available installed.
 2. Ensure the latest server updates to the federation server includes [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
->[!IMPORTANT]
+When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
 >The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid certificate trust deployments for domain joined computers.
-## Enroll for a TLS Server Authentication Certificate
+Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
 ### AD FS authentication certificate enrollment
-Windows Hello for Business on-premises deployments require a federation server for device registration, key registration, and authentication certificate enrollment.  Typically, a federation service is an edge facing role.  However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.  
+Sign-in the federation server with *domain administrator* equivalent credentials.
-The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate issued by your enterprise (internal) certificate authority.  The server authentication certificate should have the following names included in the certificate if you are requesting an individual certificate for each node in the federation farm:
+1. Start the Local Computer **Certificate Manager** (certlm.msc)
 1. Expand the **Personal** node in the navigation pane
 1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
 1. Select **Next** on the **Before You Begin** page
 1. Select **Next** on the **Select Certificate Enrollment Policy** page
 1. On the **Request Certificates** page, select the **Internal Web Server** check box
 1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
    :::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
 1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
 1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
 1. Select **Enroll**
- Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
+A server authentication certificate should appear in the computer's personal certificate store.
 - Subject Alternate Name: Your federation service name, such as *fs.corp.contoso.com* (or an appropriate wildcard entry such as *.corp.contoso.com)
 - Subject Alternate Name: Your device registration service name, such as *enterpriseregistration.contoso.com*
-You configure your federation service name when you configure the AD FS role. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server **adfs** and the federation service **fs**.  The FQDN of the host is adfs.corp.contoso.com and the FQDN of the federation service is fs.corp.contoso.com.
+## Deploy the AD FS role
-You can; however, issue one certificate for all hosts in the farm.  If you chose this option, then leave the subject name blank, and include all the names in the subject alternate name when creating the certificate request.  All names should include the FQDN of each host in the farm and the federation service name.  
+AD FS provides the following services to support Windows Hello for Business on-premises deployments in a certificate trust model:
 It’s recommended that you mark the private key as exportable so that the same certificate can be deployed across each federation server and web application proxy within your AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
 Be sure to enroll or import the certificate into the AD FS server’s computer certificate store.  Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
 ### Internal Web Server Authentication Certificate Enrollment
 Sign-in the federation server with domain administrator equivalent credentials.
 1. Start the Local Computer **Certificate Manager** (certlm.msc).
 2. Expand the **Personal** node in the navigation pane.
 3. Right-click **Personal**. Select **All Tasks** and **Request New Certificate**.
 4. Click **Next** on the **Before You Begin** page.
 5. Click **Next** on the **Select Certificate Enrollment Policy** page.
 6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
 7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link   
    ![Example of Certificate Properties Subject Tab - This is what shows when you click the above link.](images/hello-internal-web-server-cert.png)
 8. Under **Subject name**, select **Common Name** from the **Type** list.  Type the FQDN of the computer hosting the Active Directory Federation Services role and then click **Add**.  
 9. Under **Alternative name**, select **DNS** from the **Type** list.  Type the FQDN of the name you will use for your federation services (fs.corp.contoso.com). The name you use here MUST match the name you use when configuring the Active Directory Federation Services server role.  Click **Add**. Repeat the same to add device registration service name (*enterpriseregistration.contoso.com*) as another alternative name. Click **OK** when finished.
 10. Click **Enroll**.
 A server authentication certificate should appear in the computer’s Personal certificate store.
 ## Deploy the Active Directory Federation Service Role
 The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello for Business on-premises deployments:
 - Device registration
 - Key registration
- Certificate registration authority (certificate trust deployments)
+- Certificate registration authority (CRA)
 >[!IMPORTANT]
 > Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm.  Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
-Windows Hello for Business depends on proper device registration.  For on-premises deployments, Windows Server 2016 AD FS handles device registration.
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
 1. Select **Manage > Add Roles and Features**
 1. Select **Next** on the **Before you begin** page
 1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
 1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
 1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
 1. Select **Next** on the **Select features** page
 1. Select **Next** on the **Active Directory Federation Service** page
 1. Select **Install** to start the role installation
-1. Start **Server Manager**.  Click **Local Server** in the navigation pane.
+## Review to validate the AD FS deployment
 2. Click **Manage** and then click **Add Roles and Features**.
 3. Click **Next** on the **Before you begin** page.
 4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
 5. On the **Select destination server** page, choose **Select a server from the server pool**.  Select the federation server from the **Server Pool** list.  Click **Next**.
 6. On the **Select server roles** page, select **Active Directory Federation Services**.  Click **Next**.
 7. Click **Next** on the **Select features** page.
 8. Click **Next** on the **Active Directory Federation Service** page.
 9. Click **Install** to start the role installation.
 ## Review & validate
 [!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
- Confirm the AD FS farm uses the correct database configuration.
+> [!div class="checklist"]
- Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
+> * Confirm the AD FS farm uses the correct database configuration
- Confirm **all** AD FS servers in the farm have the latest updates.
+> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
- Confirm all AD FS servers have a valid server authentication certificate.
+> * Confirm **all** AD FS servers in the farm have the latest updates installed
-    - The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
+> * Confirm all AD FS servers have a valid server authentication certificate
    - The alternate name of the certificate contains a wildcard or the FQDN of the federation service.
-## Device Registration Service Account Prerequisite
+## Device registration service account prerequisites
-The service account used for the device registration server depends on the domain controllers in the environment.  
+The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
->[!NOTE]
+GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
 > Follow the procedures below based on the domain controllers deployed in your environment.  If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
-### Windows Server 2012 or later Domain Controllers
+### Create KDS Root Key
-Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred way to deploy service accounts for services that support them.  Group Managed Service Accounts, or GMSA have security advantages over normal user accounts because Windows handles password management.  This means the password is long, complex, and changes periodically.  The best part of GMSA is all this happens automatically.  AD FS supports GMSA and should be configured using them for additional defense in depth security.
+Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
-GMSA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain controllers.  Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the GMSA.  Before you can create a GMSA, you must first create a root key for the service.  You can skip this if your environment already uses GMSA.
+Start an elevated PowerShell console and execute the following command:
-
+```PowerShell
->[!NOTE]
+Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
-> If the [default object creation quota for security principles](/openspecs/windows_protocols/ms-adts/d55ca655-109b-4175-902a-3e9d60833012) is set, you will need to change it for the Group Managed Service Account in order to be able to register new devices. 
+```
 #### Create KDS Root Key
 Sign-in a domain controller with _Enterprise Admin_ equivalent credentials.
 1. Start an elevated Windows PowerShell console.
 2. Type `Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)`.
 ### Windows Server 2008 or 2008 R2 Domain Controllers
 Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor do they support Group Managed Service Accounts.  Therefore, you must use create a normal user account as a service account where you are responsible for changing the password on a regular basis.
 #### Create an AD FS Service Account
 Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
 1. Open **Active Directory Users and Computers**.
 2. Right-click the **Users** container, Click **New**. Click **User**.
 3. In the **New Object – User** window, type **adfssvc** in the **Full name** text box.  Type **adfssvc** in the **User logon name** text box.  Click **Next**.
 4. Enter and confirm a password for the **adfssvc** user. Clear the **User must change password at next logon** check box.
 5. Click **Next** and then click **Finish**.
 ## Configure the Active Directory Federation Service Role
->[!IMPORTANT]
+Use the following procedures to configure AD FS.
 > Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
-### Windows Server 2012 or later Domain Controllers
+Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2012 or later Domain Controllers**.  If you are not using Windows Server 2012 or later Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2 Domain Controllers)](#windows-server-2008-or-2008-r2-domain-controllers) section.
+1. Start **Server Manager**
-
+1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
-Sign-in the federation server with _domain administrator_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
+1. On the **Welcome** page, select **Create the first federation server farm > Next**
-
+1. On the **Connect to Active Directory Domain Services** page, select **Next**
-1. Start **Server Manager**.
+1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
-2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
+1. Select the federation service name from the **Federation Service Name** list
-![Example of pop-up notification as described above.](images/hello-adfs-configure-2012r2.png)
+1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
+1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
-4. Click **Next** on the **Connect to Active Directory Domain Services** page.
+1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
-5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list.  The certificate is likely named after your federation service, such as *fs.corp.contoso.com* or *fs.contoso.com*.
+1. On the **Review Options** page, select **Next**
-6. Select the federation service name from the **Federation Service Name** list.
+1. On the **Pre-requisite Checks** page, select **Configure**
-7. Type the Federation Service Display Name in the text box.  This is the name users see when signing in.  Click **Next**.
+1. When the process completes, select **Close**
 8. On the **Specify Service Account** page, select **Create a Group Managed Service Account**.  In the **Account Name** box, type **adfssvc**.
 9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
 10. On the **Review Options** page, click **Next**.
 11. On the **Pre-requisite Checks** page, click **Configure**.
 12. When the process completes, click **Close**.
 ### Windows Server 2008 or 2008 R2 Domain Controllers
 Use the following procedures to configure AD FS when your environment uses **Windows Server 2008 or 2008 R2 Domain Controllers**.  If you are not using Windows Server 2008 or 2008 R2 Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2012 or later Domain Controllers)](#windows-server-2012-or-later-domain-controllers) section.
 Sign-in the federation server with _domain administrator_ equivalent credentials.  These instructions assume you are configuring the first federation server in a federation server farm.
 1. Start **Server Manager**.
 2. Click the notification flag in the upper right corner.  Click **Configure federation services on this server**.
 ![Example of pop-up notification as described above.](images/hello-adfs-configure-2012r2.png)
 3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
 4. Click **Next** on the **Connect to Active Directory Domain Services** page.
 5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net or fs.mstepdemo.net.
 6. Select the federation service name from the **Federation Service Name** list.
 7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
 8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**.  In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
 9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
 10. On the **Review Options** page, click **Next**.
 11. On the **Pre-requisite Checks** page, click **Configure**.
 12. When the process completes, click **Close**.
 13. Do not restart the AD FS server. You will do this later.
 ### Add the AD FS Service account to the KeyCredential Admin group and the Windows Hello for Business Users group
 > [!NOTE]
-> If you have a Windows Server 2016 domain controller in your domain, you can use the **Key Admins** group instead of **KeyCredential Administrators** and skip the **Configure Permissions for Key Registration** step.
+> For AD FS 2019 and later in a certificate trust model, a known PRT issue exists. You may encounter this error in AD FS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'. To remediate this error:
 >
 > 1. Launch AD FS management console. Browse to ***Services > Scope Descriptions**
 > 2. Right-click **Scope Descriptions** and select **Add Scope Description**
 > 3. Under name type *ugs* and select **Apply > OK**
 > 4. Launch PowerShell as an administrator and execute the following commands:
 > ```PowerShell
 > $id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
 > Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'
 > ```
 > 7. Restart the AD FS service
 > 8. Restart the client. User should be prompted to provision Windows Hello for Business
-The **KeyCredential Administrators** global group provides the AD FS service with the permissions needed to perform key registration.  The Windows Hello for Business group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user.
+### Add the AD FS service account to the *Key Admins* group
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
-1. Open **Active Directory Users and Computers**.
+Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
 2. Click the **Users** container in the navigation pane.
 3. Right-click **KeyCredential Admins** in the details pane and click **Properties**.
 4. Click the **Members** tab and click **Add…**
 5. In the **Enter the object names to select** text box, type **adfssvc**.  Click **OK**.
 6. Click **OK** to return to **Active Directory Users and Computers**.
 7. Right-click **Windows Hello for Business Users** group
 8. Click the **Members** tab and click **Add…**
 9. In the **Enter the object names to select** text box, type **adfssvc**.  Click **OK**.
 10. Click **OK** to return to **Active Directory Users and Computers**.
 11. Change to server hosting the AD FS role and restart it.
-### Configure Permissions for Key Registration
+1. Open **Active Directory Users and Computers**
 1. Select the **Users** container in the navigation pane
 1. Right-click **Key Admins** in the details pane and select **Properties**
 1. Select the **Members > Add…**
 1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
 1. Select **OK** to return to **Active Directory Users and Computers**
 1. Change to server hosting the AD FS role and restart it
-Key Registration stores the Windows Hello for Business public key in Active Directory.  With on-premises deployments, the Windows Server 2016 AD FS server registers the public key with the on-premises Active Directory.
+Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
-The key-trust model needs Windows Server 2016 domain controllers, which configures the key registration permissions automatically; however, the certificate-trust model does not and requires you to add the permissions manually.
+1. Open the **AD FS management** console
 1. In the navigation pane, expand **Service**. Select **Device Registration**
 1. In the details pane, select **Configure device registration**
 1. In the **Configure Device Registration** dialog, Select **OK**
-Sign-in a domain controller or management workstations with _Domain Admin_ equivalent credentials.
+:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png" alt-text="AD FS device registration: configuration of the service connection point.":::
-1. Open **Active Directory Users and Computers**.
+Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
 2. Right-click your domain name from the navigation pane and click **Properties**.
 3. Click **Security** (if the Security tab is missing, turn on Advanced Features from the View menu).
 4. Click **Advanced**. Click **Add**. Click **Select a principal**.
 5. The **Select User, Computer, Service Account, or Group** dialog box appears. In the **Enter the object name to select** text box, type **KeyCredential Admins**.  Click **OK**.
 6. In the **Applies to** list box, select **Descendant User objects**.
 7. Using the scroll bar, scroll to the bottom of the page and click **Clear all**.
 8. In the **Properties** section, select **Read msDS-KeyCredentialLink** and **Write msDS-KeyCrendentialLink**.
 9. Click **OK** three times to complete the task.
-## Configure the Device Registration Service
+:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="AD FS device registration: service connection point object created by AD FS.":::
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
+## Review to validate the AD FS and Active Directory configuration
 1. Open the **AD FS management** console.
 2. In the navigation pane, expand **Service**. Click **Device Registration**.
 3. In the details pane, click **Configure Device Registration**.
 4. In the **Configure Device Registration** dialog, click **OK**.
 ## Review to validate
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm you followed the correct procedures based on the domain controllers used in your deployment. 
    * Windows Server 2012 or Windows Server 2012 R2
    * Windows Server 2008 or Windows Server 2008 R2
 * Confirm you have the correct service account based on your domain controller version.
 * Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of your federation, the number of relying parties, and database needs.
 * Confirm you used a certificate with the correct names as the server authentication certificate.
    * Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
        * Certificate serial number
        * Certificate thumbprint
        * Common name of the certificate
        * Subject alternate name of the certificate
        * Name of the physical host server
        * The issued date
        * The expiration date
        * Issuing CA Vendor (if a third-party certificate) 
 * Confirm you granted the AD FS service allow read and write permissions to the ms-DSKeyCredentialLink Active Directory attribute.
 * Confirm you enabled the Device Registration service.
-## Prepare and Deploy AD FS Registration Authority
+> [!div class="checklist"]
 > * Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
 > * Confirm you added the AD FS service account to the KeyAdmins group
 > * Confirm you enabled the Device Registration service
-A registration authority is a trusted authority that validates certificate request.  Once it validates the request, it presents the request to the certificate authority for issuance.  The certificate authority issues the certificate, returns it to the registration authority, which returns the certificate to the requesting user.  The Windows Hello for Business on-premises certificate-based deployment uses the Active Directory Federation Server (AD FS) as the certificate registration authority.
+## Configure the certificate registration authority
-### Configure Registration Authority template
+The Windows Hello for Business on-premises certificate-based deployment uses AD FS as the certificate registration authority (CRA). The registration authority is responsible for issuing certificates to users and devices. The registration authority is also responsible for revoking certificates when users or devices are removed from the environment.
-The certificate registration authority enrolls for an enrollment agent certificate. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The certificate authority only issues a certificate for that template if the registration authority signs the certificate request.
+Sign-in the AD FS server with *domain administrator* equivalent credentials.
-The registration authority template you configure depends on the AD FS service configuration, which depends on the domain controllers the environment uses for authentication.
+Open a **Windows PowerShell** prompt and type the following command:
 >[!IMPORTANT]
 >Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
 #### Windows 2012 or later domain controllers
 Sign-in a certificate authority or management workstations with _domain administrator_ equivalent credentials.
 1. Open the **Certificate Authority Management** console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Template Console**, right click on the **Exchange Enrollment Agent (Offline request)** template details pane and click **Duplicate Template**.
 4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
 5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise’s needs.
 6. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
   > [!NOTE]
   > The preceding step is very important.  Group Managed Service Accounts (GMSA) do not support the Build from this Active Directory information option and will result in the AD FS server failing to enroll the enrollment agent certificate.  You must configure the certificate template with Supply in the request to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
 7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.
 8. On the **Security** tab, click **Add**.
 9. Click **Object Types**.  Select the **Service Accounts** check box and click **OK**.
 10. Type **adfssvc** in the **Enter the object names to select** text box and click **OK**.
 11. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
 12. Close the console.
 #### Windows 2008 or 2008R2 domain controllers
 Sign-in a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
 1. Open the **Certificate Authority** management console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Template** console, right-click the **Exchange Enrollment Agent** template in the details pane and click **Duplicate Template**.
 4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
 5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise’s needs.
 6. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected.  Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
 7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.
 8. On the **Security** tab, click **Add**. Type **adfssvc** in the **Enter the object names to select text box** and click **OK**.
 9. Click the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission. Excluding the **adfssvc** user, clear the **Allow** check boxes for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
 10. Close the console.
 ### Configure the Windows Hello for Business Authentication Certificate template
 During Windows Hello for Business provisioning, the Windows 10, version 1703 client requests an authentication certificate from the Active Directory Federation Service, which requests the authentication certificate on behalf of the user.  This task configures the Windows Hello for Business authentication certificate template.  You use the name of the certificate template when configuring.
 Sign-in a certificate authority or management workstations with _domain administrator equivalent_ credentials.
 1. Open the **Certificate Authority** management console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**.
 4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
 5. On the **General** tab, type **WHFB Authentication** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise’s needs.
   > [!NOTE]
   > If you use different template names, you’ll need to remember and substitute these names in different portions of the deployment.
 6. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.  
 7. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**.
 8. On the **Issuance Requirements** tab, select the T**his number of authorized signatures** check box.  Type **1** in the text box.
   Select **Application policy** from the **Policy type required in signature**. Select **Certificate Request Agent** from in the **Application policy** list. Select the **Valid existing certificate** option.
 9. On the **Subject** tab, select the **Build from this Active Directory information** button if it is not already selected. Select **Fully distinguished name** from the **Subject name format** list if **Fully distinguished name** is not already selected. Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**.
 10. On the **Request Handling** tab, select the **Renew with same key** check box.
 11. On the **Security** tab, click **Add**. Type **Window Hello for Business Users** in the **Enter the object names to select** text box and click **OK**.
 12. Click the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section, select the **Allow** check box for the **Enroll** permission. Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared. Click **OK**.
 13. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template.
 14. Click on the **Apply** to save changes and close the console.
 #### Mark the template as the Windows Hello Sign-in template 
 Sign-in to an **AD FS Windows Server 2016** computer with _enterprise administrator_ equivalent credentials.
 1. Open an elevated command prompt.
 2. Run `certutil –dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY`.
 >[!NOTE]
 >If you gave your Windows Hello for Business Authentication certificate template a different name, then replace **WHFBAuthentication** in the above command with the name of your certificate template. It’s important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc).  Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on our Windows Server 2012 or later certificate authority.
 ### Publish Enrollment Agent and Windows Hello For Business Authentication templates to the Certificate Authority
 Sign-in a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
 1. Open the **Certificate Authority** management console.
 2. Expand the parent node from the navigation pane.
 3. Click **Certificate Templates** in the navigation pane.
 4. Right-click the **Certificate Templates** node.  Click **New**, and click **Certificate Template to issue**.
 5. In the **Enable Certificates Templates** window, select the **WHFB Enrollment Agent** template you created in the previous steps.  Click **OK** to publish the selected certificate templates to the certificate authority.
 6. Publish the **WHFB Authentication** certificate template using step 5.
 7. Close the console.
 ### Configure the Registration Authority
 Sign-in the AD FS server with domain administrator equivalent credentials.
 1. Open a **Windows PowerShell** prompt.
 2. Type the following command
   ```PowerShell
   Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
   ```
   >[!NOTE]
-   > If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace **WHFBEnrollmentAgent** and WHFBAuthentication in the above command with the name of your certificate templates.  It’s important that you use the template name rather than the template display name.  You can view the template name on the **General** tab of the certificate template using the **Certificate Template** management console (certtmpl.msc).  Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on a Windows Server 2012 or later certificate authority.
+   > If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates.
-### Enrollment Agent Certificate Enrollment
+### Enrollment agent certificate enrollment
-Active Directory Federation Server used for Windows Hello for Business certificate enrollment perform their own certificate lifecycle management.  Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
+AD FS performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts.
-Approximately 60 days prior to enrollment agent certificate’s expiration, the AD FS service attempts to renew the certificate until it is successful.  If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate.  You can view the AD FS event logs to determine the status of the enrollment agent certificate.
+Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
-### Service Connection Point (SCP) in Active Directory for ADFS Device Registration Service
+## Additional federation servers
 > [!NOTE]
 > Normally this script is not needed, as enabling Device Registration via the ADFS Management console already creates the objects. You can validate the SCP using the script below. For detailed information about the Device Registration Service, see [Configuring Device Registration](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn614658(v=ws.11)).
 Now you will add the Service connection Point to ADFS device registration Service for your Active directory by running the following script:
 > [!TIP]
 > Make sure to change the $enrollmentService and $configNC variables before running the script.
 ```powershell
 # Replace this with your Device Registration Service endpoint
 $enrollmentService = "enterpriseregistration.contoso.com"
 # Replace this with your Active Directory configuration naming context 
 $configNC = "CN=Configuration,DC=corp,DC=contoso,DC=org" 
 $de = New-Object System.DirectoryServices.DirectoryEntry
 $de.Path = "LDAP://CN=Device Registration Configuration,CN=Services," + $configNC
 $deSCP = $de.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
 $deSCP.Properties["keywords"].Add("enterpriseDrsName:" + $enrollmentService)
 $deSCP.CommitChanges()
 ```
 >[!NOTE]
 > You can save the modified script in notepad and save them as "add-scpadfs.ps1" and the way to run it is just navigating into the script path folder and running .\add-scpAdfs.ps1.
 >
 ## Additional Federation Servers
 Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
-### Server Authentication Certificate
+### Server authentication certificate
 Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
-### Install Additional Servers
+### Install additional servers
 Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
-## Load Balance AD FS Federation Servers
+## Load balance AD FS
 Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
 ### Install Network Load Balancing Feature on AD FS Servers
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
-1. Start **Server Manager**.  Click **Local Server** in the navigation pane.
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
-2. Click **Manage** and then click **Add Roles and Features**.
+1. Select **Manage** and then select **Add Roles and Features**
-3. Click **Next** On the **Before you begin** page.
+1. Select **Next** On the **Before you begin** page
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
+1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
-5. On the **Select destination server** page, choose **Select a server from the server pool**.  Select the federation server from the **Server Pool** list.  Click **Next**.
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
-6. On the **Select server roles** page, click **Next**.
+1. On the **Select server roles** page, select **Next**
-7. Select **Network Load Balancing** on the **Select features** page.
+1. Select **Network Load Balancing** on the **Select features** page
-8. Click **Install** to start the feature installation.
+1. Select **Install** to start the feature installation
   ![Feature selection screen with NLB selected.](images/hello-nlb-feature-install.png)
 ### Configure Network Load Balancing for AD FS
 Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
-Sign-in a node of the federation farm with _Admin_ equivalent credentials.
+Sign-in a node of the federation farm with *Administrator* equivalent credentials.
-1. Open **Network Load Balancing Manager** from **Administrative Tools**.
+1. Open **Network Load Balancing Manager** from **Administrative Tools**
-    ![NLB Manager user interface.](images/hello-nlb-manager.png)
+1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
-2. Right-click **Network Load Balancing Clusters**, and then click **New Cluster**.
+1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
-3. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then click **Connect**.
+1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
-    ![NLB Manager - Connect to new Cluster screen.](images/hello-nlb-connect.png)
+1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
-4. Select the interface that you want to use with the cluster, and then click **Next**. (The interface hosts the virtual IP address and receives the client traffic to load balance.)
+1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
-5. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Click **Next**.
+1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
-6. In **Cluster IP Addresses**, click **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Click **Next**.
+1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
-    ![NLB Manager - Add IP to New Cluster screen.](images/hello-nlb-add-ip.png)
+1. In Port Rules, select Edit to modify the default port rules to use port 443
 7. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster.
    ![NLB Manager - Cluster IP Configuration screen.](images/hello-nlb-cluster-ip-config.png)
 8. In **Cluster operation mode**, click **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Click **Next**.
 9. In Port Rules, click Edit to modify the default port rules to use port 443.
    ![NLB Manager - Add\Edit Port Rule screen.](images/hello-nlb-cluster-port-rule.png)
 ### Additional AD FS Servers
-1. To add more hosts to the cluster, right-click the new cluster, and then click **Add Host to Cluster**.
+1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
-2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same.
+1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
    ![NLB Manager - Cluster with nodes.](images/hello-nlb-cluster.png)
 ## Configure DNS for Device Registration
-Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.  You’ll need the Federation service name to complete this task.  You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
+Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
 You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
-1. Open the **DNS Management** console.
+1. Open the **DNS Management** console
-2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**.
+1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
-3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
+1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
-4. In the navigation pane, right-click the domain name node and click **New Host (A or AAAA)**.
+1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
-5. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Click **Add Host**.
+1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
-6. Close the DNS Management console.
+1. Right-click the `<domain_name>` node and select **New Alias (CNAME)**
 1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
 1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.<domain_name_fqdn`, and select OK
 1. Close the DNS Management console
 > [!NOTE]
 > If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.<upnsuffix_fqdn>` is present for each suffix.
 ## Configure the Intranet Zone to include the federation service
@ -489,78 +265,54 @@ The Windows Hello provisioning presents web pages from the federation service.
 ### Create an Intranet Zone Group Policy
-Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials:
+Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials
-
+1. Start the **Group Policy Management Console** (gpmc.msc)
-1. Start the **Group Policy Management Console** (gpmc.msc).
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. Right-click **Group Policy object** and select **New**
-3. Right-click **Group Policy object** and select **New**.
+1. Type **Intranet Zone Settings** in the name box and select **OK**
-4. Type **Intranet Zone Settings** in the name box and click **OK**.
+1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
-5. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and click **Edit**.
+1. In the navigation pane, expand **Policies** under **Computer Configuration**
-6. In the navigation pane, expand **Policies** under **Computer Configuration**.
+1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
-7. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel**, and select **Security Page**.
+1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
 8. In the content pane, double-click **Site to Zone Assignment List**. Click **Enable**.
 9. Click **Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**.  Click OK twice, then close the Group Policy Management Editor.
 ### Deploy the Intranet Zone Group Policy object
-1. Start the **Group Policy Management Console** (gpmc.msc).
+1. Start the **Group Policy Management Console** (gpmc.msc)
-2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO…**
+1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
-3. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
+1. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
-## Review
+## Review to validate the configuration
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm you configured the correct enrollment agent certificate template based on the type of AD FS service account.
 * Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template.
 * Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance. 
 * Confirm you properly configured the Windows Hello for Business authentication certificate template—to include:   
    * Issuance requirements of an authorized signature from a certificate request agent.
    * The certificate template was properly marked as a Windows Hello for Business certificate template using certutil.exe.
    * The Windows Hello for Business Users group, or equivalent has the allow enroll permissions.
 * Confirm all certificate templates were properly published to the appropriate issuing certificate authorities.
 * Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template.
 * Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet.
 * Confirm you restarted the AD FS service.
 * Confirm you properly configured load-balancing (hardware or software).
 * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
 * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
-## Validating your work
+> [!div class="checklist"]
-
+> * Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template
-You need to verify the AD FS service has properly enrolled for an enrollment agent certificate template.  You can verify this is a variety ways, depending on if your service account is a normal user account or if the service account is a group managed service account.
+> * Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance
-
+> * Confirm you properly configured the Windows Hello for Business authentication certificate template
-> [!IMPORTANT]
+> * Confirm all certificate templates were properly published to the appropriate issuing certificate authorities
-> After following the previous steps, if you are unable to validate that the devices are, in fact, being registered automatically, there is a Group Policy at:
+> * Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template
-> **Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration >** "Register Domain Joined Computers As Devices". Set the policy to **Enabled**
+> * Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet
-> and the registration will happen automatically.
+> Confirm you restarted the AD FS service
 > * Confirm you properly configured load-balancing (hardware or software)
 > * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
 > * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
 ### Event Logs
-Use the event logs on the AD FS service to confirm the service account enrolled for an enrollment agent certificate.  First, look for the AD FS event ID 443 that confirms certificate enrollment cycle has finished.  Once confirmed the AD FS certificate enrollment cycle completed review the CertificateLifecycle-User event log.  In this event log, look for event ID 1006, which indicates a new certificate was installed.  Details of the event log should show:
+Use the event logs on the AD FS service to confirm the service account enrolled for an enrollment agent certificate.  First, look for the AD FS event ID 443 that confirms certificate enrollment cycle has finished. Once confirmed the AD FS certificate enrollment cycle completed review the *CertificateLifecycle-User* event log. In this event log, look for event ID 1006, which indicates a new certificate was installed. Details of the event log should show:
-* The account name under which the certificate was enrolled.
+- The account name under which the certificate was enrolled
-* The action, which should read enroll.
+- The action, which should read enroll
-* The thumbprint of the certificate
+-_ The thumbprint of the certificate
-* The certificate template used to issue the certificate.
+- The certificate template used to issue the certificate
-### Normal Service Account
+You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts. Use the event log information to confirm the AD FS service account enrolled a certificate. Use certutil.exe to view the details of the certificate shown in the event log.
-When using a normal service account, use the Microsoft Management Console (mmc.exe) and load the Certificate Manager snap-in for the service account and verify.
+Group managed service accounts use user profiles to store user information, which included enrolled certificates. On the AD FS server, use a command prompt and navigate to `%systemdrive%\users\<adfsGMSA_name>\appdata\roaming\Microsoft\systemcertificates\my\certificates`.
-### Group Managed Service Account
+Each file in this folder represents a certificate in the service account's Personal store (You may need to use `dir.exe /A` to view the files in the folder). Match the thumbprint of the certificate from the event log to one of the files in this folder. That file is the certificate. Use the `Certutil -q <certificateThumbprintFileName>` to view the basic information about the certificate.
-You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts.  Use the event log information to confirm the AD FS service account enrolled a certificate.  Use certutil.exe to view the details of the certificate now shown in the event log.
+For detailed information about the certificate, use `Certutil -q -v <certificateThumbprintFileName>`.
-Group managed service accounts use user profiles to store user information, which included enrolled certificates.  On the AD FS server, use a command prompt and navigate to `%systemdrive%\users\<adfsGMSA_name>\appdata\roaming\Microsoft\systemcertificates\my\certificates` .
+> [!div class="nextstepaction"]
-
+> [Next: validate and deploy multi-factor authentication (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 Each file in this folder represents a certificate in the service account’s Personal store (You may need to use DIR /A to view the files in the folder).  Match the thumbprint of the certificate from the event log to one of the files in this folder.  That file is the certificate.  Use the `Certutil -q <certificateThumbprintFileName>` to view the basic information about the certificate.
 For detailed information about the certificate, use `Certutil -q -v <certificateThumbprintFileName>` .
 ## Follow the Windows Hello for Business on premises certificate trust deployment guide
 1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
 2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
 3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (*You are here*)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-policy-settings.md
@ -1,93 +1,82 @@
 ---
-title: Configure Windows Hello for Business Policy settings - certificate trust
+title: Configure Windows Hello for Business Policy settings in an on-premises certificate trust
-description: Configure Windows Hello for Business Policy settings for Windows Hello for Business. Certificate-based deployments need three group policy settings.
+description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises certificate trust scenario
 ms.collection: 
  - highpri
-ms.date: 08/20/2018
+ms.date: 12/12/2022
 appliesto: 
- ✅ <a href=https: //learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https: //learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# Configure Windows Hello for Business Policy settings - Certificate Trust
+# Configure Windows Hello for Business group policy settings - on-premises certificate Trust
 [!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520).
+On-premises certificate-based deployments of Windows Hello for Business need three Group Policy settings:
-Install the Remote Server Administration Tools for Windows on a computer running Windows 10 or later.
+- Enable Windows Hello for Business
 - Use certificate for on-premises authentication
 - Enable automatic enrollment of certificates
-On-premises certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
+## Enable Windows Hello for Business group policy setting
 * Enable Windows Hello for Business
 * Use certificate for on-premises authentication
 * Enable automatic enrollment of certificates
-## Enable Windows Hello for Business Group Policy
+The group policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.
-The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.
+If you configure the group policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the group policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business.
-If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business .
+## Use certificate for on-premises authentication group policy setting
-## Use certificate for on-premises authentication
+The group policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model. You must configure this group policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication.
-The Use certificate for on-premises authentication Group Policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model.  You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication, which requires a sufficient number of Windows Server 2016 domain controllers to handle the Windows Hello for Business key-trust authentication requests.
+You can configure this setting for computer or users. Deploying this setting to computers results in *all* users requesting a Windows Hello for Business authentication certificate. Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence.
-You can configure this Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users requesting a Windows Hello for Business authentication certificate.  Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence.
+## Enable automatic enrollment of certificates group policy setting
-## Enable automatic enrollment of certificates
+Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The process requires no user interaction provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires.
-Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The Windows 10, version 1703 certificate auto enrollment was updated to renew these certificates before they expire, which significantly reduces user authentication failures from expired user certificates. 
+## Create the GPO
-The process requires no user interaction provided the user signs-in using Windows Hello for Business.  The certificate is renewed in the background before it expires.
+Sign in to a domain controller or management workstations with *Domain Administrator* equivalent credentials.
 ## Create the Windows Hello for Business Group Policy object
 The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed.
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
-3. Right-click **Group Policy object** and select **New**.
+1. Right-click **Group Policy object** and select **New**
-4. Type *Enable Windows Hello for Business* in the name box and click **OK**.
+1. Type *Enable Windows Hello for Business* in the name box and select **OK**
-5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
+1. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and select **Edit**
-6. In the navigation pane, expand **Policies** under **User Configuration** (this is the only option for Windows Server 2016, but for Windows Server 2019 and later this step can also be done in **Computer Configuration**).
+1. In the navigation pane, select **User Configuration > Policies > Administrative Templates > Windows Component > Windows Hello for Business**
-7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
+1. In the content pane, double-click **Use Windows Hello for Business**. Select **Enable** and **OK**
-8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**.
+1. Select **Use certificate for on-premises authentication > Enable > OK**
-9. Double-click **Use certificate for on-premises authentication**. Click **Enable** and click **OK**.  Close the **Group Policy Management Editor**.
+1. In the navigation pane, expand **Policies > User Configuration**
 1. Expand **Windows Settings > Security Settings > Public Key Policies**
 1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**
 1. Select **Enabled** from the **Configuration Model** list
 1. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box
 1. Select the **Update certificates that use certificate templates** check box
 1. Select **OK** and close the **Group Policy Management Editor**.
-## Configure Automatic Certificate Enrollment
+## Configure security in the Windows Hello for Business GPO
 1. Start the **Group Policy Management Console** (gpmc.msc).
 2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
 3. Right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
 4. In the navigation pane, expand **Policies** under **User Configuration** (this is the only option for Windows Server 2016, but for Windows Server 2019 and later this step can also be done in **Computer Configuration**).
 5. Expand **Windows Settings > Security Settings**, and click **Public Key Policies**.
 6. In the details pane, right-click **Certificate Services Client – Auto-Enrollment** and select **Properties**.
 7. Select **Enabled** from the **Configuration Model** list.
 8. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box.
 9. Select the **Update certificates that use certificate templates** check box.
 10. Click **OK**. Close the **Group Policy Management Editor**.
 ## Configure Security in the Windows Hello for Business Group Policy object
 The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases.
 Sign in to a domain controller or management workstations with *Domain Administrator* equivalent credentials.
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
-3. Double-click the **Enable Windows Hello for Business** Group Policy object.
+1. Double-click the **Enable Windows Hello for Business** Group Policy object
-4. In the **Security Filtering** section of the content pane, click **Add**.  Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
+1. In the **Security Filtering** section of the content pane, select **Add**.  Type *Windows Hello for Business Users* or the name of the security group you previously created and select **OK**
-5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**.
+1. Select the **Delegation** tab. Select **Authenticated Users** and **Advanced**
-6. In the **Group or User names** list, select **Authenticated Users**.  In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**.
+1. In the **Group or User names** list, select **Authenticated Users**.  In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK**
 ## Deploy the Windows Hello for Business Group Policy object
-The application of the Windows Hello for Business Group Policy object uses security group filtering.  This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business.
+The application of the Windows Hello for Business Group Policy object uses security group filtering. This solution enables you to link the Group Policy object at the domain level, ensuring the GPO is within scope to all users. However, the security group filtering ensures that only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business.
 1. Start the **Group Policy Management Console** (gpmc.msc)
 2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO…**
 3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
-Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object. 
+1. Start the **Group Policy Management Console** (gpmc.msc)
 1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
 1. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
 ## Other Related Group Policy settings
 ### Windows Hello for Business
 There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment.  These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. 
 ### Use a hardware security device
@ -96,53 +85,44 @@ The default configuration for Windows Hello for Business is to prefer hardware p
 You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business.
-Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Therefore, some organization may want not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, simply select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
+Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object.
 ### Use biometrics
 Windows Hello for Business provides a great user experience when combined with the use of biometrics.  Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.  
-The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers.  The policy setting disabled all biometrics. Currently, Windows does not provide granular policy setting that enable you to disable specific modalities of biometrics such as allow facial recognition, but disallow fingerprint.
+The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disables all biometrics. Currently, Windows does not provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition, but disallowing fingerprint recognition.
 ### PIN Complexity
 PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
-Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use.  If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations.  The policy settings included are:
+Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically. The policy settings included are:
 * Require digits
 * Require lowercase letters
 * Maximum PIN length
 * Minimum PIN length
 * Expiration
 * History
 * Require special characters
 * Require uppercase letters
-In the Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under Computer Configuration\Administrative Templates\System\PIN Complexity in the Group Policy editor.
+- Require digits
 - Require lowercase letters
 - Maximum PIN length
 - Minimum PIN length
 - Expiration
 - History
 - Require special characters
 - Require uppercase letters
-## Review
+The settings can be found in *Administrative Templates\System\PIN Complexity*, under both the Computer and User Configuration nodes of the Group Policy editor.
 ## Review to validate the configuration
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Windows 10 Creators Editions)
 * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
 * Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
 * Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User)
 * Confirm you configured the proper security settings for the Group Policy object   
    * Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
    * Add the Windows Hello for Business Users group to the Group Policy object and gave the group the allow permission for Apply Group Policy
 * Linked the Group Policy object to the correct locations within Active Directory
 * Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one that enables it for users
 > [!div class="checklist"]
 > - Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
 > - Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting
 > - Confirm you configured the proper security settings for the Group Policy object
 > - Confirm you removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
 > - Confirm you added the Windows Hello for Business Users group to the Group Policy object, and gave the group the allow permission to Apply Group Policy
 > - Linked the Group Policy object to the correct locations within Active Directory
 > - Deployed any additional Windows Hello for Business Group Policy settings
 ## Add users to the Windows Hello for Business Users group
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the WHFB Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group.   Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business.
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the *Windows Hello for Business Users* group. Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business.
 ## Follow the Windows Hello for Business on premises certificate trust deployment guide
 1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
 2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 5. Configure Windows Hello for Business Policy settings (*You are here*)
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-ad-prereq.md
@ -1,78 +1,30 @@
 ---
-title: Update Active Directory schema for cert-trust deployment (Windows Hello for Business)
+title: Validate Active Directory prerequisites in an on-premises certificate trust
-description: How to Validate Active Directory prerequisites for Windows Hello for Business when deploying with the certificate trust model.
+description: Validate Active Directory prerequisites when deploying Windows Hello for Business in a certificate trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# Validate Active Directory prerequisites for cert-trust deployment
+# Validate Active Directory prerequisites - on-premises certificate trust
 [!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-The key registration process for the on-premises deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory or later schema. The key-trust model receives the schema extension when the first Windows Server 2016 or later domain controller is added to the forest. The certificate trust model requires manually updating the current schema to the Windows Server 2016 or later schema.
+The key registration process for the on-premises deployment of Windows Hello for Business requires the Windows Server 2016 Active Directory or later schema.
-> [!NOTE]
+## Create the Windows Hello for Business Users security group
 > If you already have a Windows Server 2016 or later domain controller in your forest, you can skip the "Updating the Schema" and "Create the KeyCredential Admins Security Global Group" steps that follow.
-Manually updating Active Directory uses the command-line utility **adprep.exe** located at **\<drive>:\support\adprep** on the Windows Server 2016 or later DVD or ISO.  Before running adprep.exe, you must identify the domain controller hosting the schema master role.
+The *Windows Hello for Business Users* group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy permissions to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business.
-## Discovering schema role
+Sign-in to a domain controller or to a management workstation with a *Domain Administrator* equivalent credentials.
-To locate the schema master role holder, open and command prompt and type:
+1. Open **Active Directory Users and Computers**
 1. Select **View > Advanced Features**
 1. Expand the domain node from the navigation pane
 1. Right-click the **Users** container. Select **New > Group**
 1. Type *Windows Hello for Business Users* in the **Group Name**
 1. Select **OK**
-```cmd
+> [!div class="nextstepaction"]
-netdom.exe query fsmo | findstr.exe -i "schema"
+> [Next: validate and configure PKI >](hello-cert-trust-validate-pki.md)
 ```
 ![Netdom example output.](images/hello-cmd-netdom.png)
 The command should return the name of the domain controller where you need to adprep.exe.  Update the schema locally on the domain controller hosting the Schema master role.
 ## Updating the Schema
 Windows Hello for Business uses asymmetric keys as user credentials (rather than passwords).  During enrollment, the public key is registered in an attribute on the user object in Active Directory.  The schema update adds this new attribute to Active Directory.  
 Sign-in to the domain controller hosting the schema master operational role using enterprise administrator equivalent credentials.
 1. Mount the ISO file (or insert the DVD) containing the Windows Server 2016 or later installation media.
 2. Open an elevated command prompt.
 3. Type ```cd /d x:\support\adprep``` where *x* is the drive letter of the DVD or mounted ISO.
 4. To update the schema, type ```adprep /forestprep```.
 5. Read the Adprep Warning.  Type the letter **C** and press **Enter** to update the schema.
 6. Close the Command Prompt and sign-out.
 ## Create the KeyCredential Admins Security Global Group
 The Windows Server 2016 Active Directory Federation Services (AD FS) role registers the public key on the user object during provisioning.  You assign write and read permission to this group to the Active Directory attribute to ensure the AD FS service can add and remove keys are part of its normal workflow.
 Sign-in a domain controller or management workstation with domain administrator equivalent credentials.
 1. Open **Active Directory Users and Computers**.
 2. Click **View** and click **Advance Features**.
 3. Expand the domain node from the navigation pane.
 4. Right-click the **Users** container. Click **New**. Click **Group**.
 5. Type **KeyCredential Admins** in the **Group Name** text box.
 6. Click **OK**.
 ## Create the Windows Hello for Business Users Security Global Group
 The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases.  You assign Group Policy and Certificate template permissions to this group to simplify the deployment by simply adding the users to the group.  This provides them the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
 Sign into a domain controller or management workstation with domain administrator equivalent credentials.
 1. Open **Active Directory Users and Computers**.
 2. Click **View** and click **Advanced Features**.
 3. Expand the domain node from the navigation pane.
 4. Right-click the **Users** container. Click **New**. Click **Group**.
 5. Type **Windows Hello for Business Users** in the **Group Name** text box.
 6. Click **OK**.
 ## Follow the Windows Hello for Business on premises certificate trust deployment guide
 1. Validate Active Directory prerequisites (*You are here*)
 2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-deploy-mfa.md
@ -1,25 +1,28 @@
 ---
 title: Validate and Deploy MFA for Windows Hello for Business with certificate trust
-description: How to Validate and Deploy Multi-factor Authentication (MFA) Services for Windows Hello for Business with certificate trust
+description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
-ms.date: 08/19/2018
+ms.date: 12/13/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# Validate and Deploy Multi-Factor Authentication feature
+
 # Validate and deploy multi-factor authentication - on-premises certificate trust
 [!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. On-premises deployments can use certificates, third-party authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA option.
+Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
-For information on available third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
+- third-party authentication providers for AD FS
 - custom authentication provider for AD FS
-Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
+> [!IMPORTANT]
 > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
+For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
-1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
+
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
+Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
+
-4. Validate and Deploy Multi-factor Authentication Services (MFA) (*You're here*)
+> [!div class="nextstepaction"]
-5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
+> [Next: configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-cert-trust-validate-pki.md
@ -1,190 +1,348 @@
 ---
-title: Validate Public Key Infrastructure - certificate trust model (Windows Hello for Business)
+title: Configure and validate the Public Key Infrastructure in an on-premises certificate trust model
-description: How to Validate Public Key Infrastructure for Windows Hello for Business, under a certificate trust model.
+description: Configure and validate the Public Key Infrastructure the Public Key Infrastructure when deploying Windows Hello for Business in a certificate trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# Validate and Configure Public Key Infrastructure - Certificate Trust Model
+# Configure and validate the Public Key Infrastructure - on-premises certificate trust
 [!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model.  All trust models depend on the domain controllers having a certificate.  The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller.  The certificate trust model extends certificate issuance to client computers.  During Windows Hello for Business provisioning, the user receives a sign-in certificate.
+Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate.
-## Deploy an enterprise certificate authority
+## Deploy an enterprise certification authority
-This guide assumes most enterprise have an existing public key infrastructure.  Windows Hello for Business depends on a Windows enterprise public key infrastructure running Active Directory Certificate Services.
+This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.
-### Lab-based public key infrastructure
+### Lab-based PKI
-The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.
+The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**.
-Sign-in using _Enterprise Admin_ equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed.
+Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
 >[!NOTE]
->Never install a certificate authority on a domain controller in a production environment.
+>Never install a certification authority on a domain controller in a production environment.
 1. Open an elevated Windows PowerShell prompt
-2. Use the following command to install the Active Directory Certificate Services role
+1. Use the following command to install the Active Directory Certificate Services role.
    ```PowerShell
    Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
    ```
-
+3. Use the following command to configure the CA using a basic certification authority configuration
 3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration
    ```PowerShell
    Install-AdcsCertificationAuthority
    ```
-## Configure a Production Public Key Infrastructure
+## Configure a PKI
-If you do have an existing public key infrastructure, please review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) from Microsoft TechNet to properly design your infrastructure.   Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your public key infrastructure using the information from your design session.
+If you have an existing PKI, review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) to properly design your infrastructure.  Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your PKI using the information from your design session.
-### Configure Domain Controller Certificates
+Expand the following sections to configure the PKI for Windows Hello for Business.
-Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate.  Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain.  This provides clients a root of trust external to the domain—namely the enterprise certificate authority.
+<br>
 <details>
 <summary><b>Configure domain controller certificates</b></summary>
-Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory.  However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates do not include the KDC Authentication object identifier (OID), which was later added to the Kerberos RFC.  Therefore, domain controllers need to request a certificate based on the Kerberos Authentication certificate template.
+Clients must trust the domain controllers, and to it each domain controller must have a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*.
-By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template.  However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs.  To ensure domain controllers request the proper certificate with the best available cryptography, use the Kerberos Authentication certificate template as a baseline to create an updated domain controller certificate template.
+Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory. However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template.
-Sign-in to a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
+By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template.
 1. Open the **Certificate Authority** management console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Templates Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
 4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
 5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name.  Adjust the validity and renewal period to meet your enterprise’s needs.   
    **Note**If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
 6. On the **Subject Name** tab, select the **Build from this Active Directory information** button if it is not already selected.  Select **None** from the **Subject name format** list.  Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
 7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.  Click **OK**. 
 8. Close the console.
-### Superseding the existing Domain Controller certificate
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
-Many domain controllers may have an existing domain controller certificate.  The Active Directory Certificate Services provides a default certificate template from domain controllers—the domain controller certificate template.  Later releases provided a new certificate template—the domain controller authentication certificate template.  These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the KDC Authentication extension.  
+1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates > Manage**
 1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template**
 1. On the **Compatibility** tab:
   - Clear the **Show resulting changes** check box
   - Select **Windows Server 2016** from the **Certification Authority** list
   - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
 1. On the **General** tab
   - Type *Domain Controller Authentication (Kerberos)* in Template display name
   - Adjust the validity and renewal period to meet your enterprise's needs
   > [!NOTE]
   > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
 1. On the **Subject Name** tab:
   - Select the **Build from this Active Directory information** button if it isn't already selected
   - Select **None** from the **Subject name format** list
   - Select **DNS name** from the **Include this information in alternate subject** list
   - Clear all other items
 1. On the **Cryptography** tab:
   - select **Key Storage Provider** from the **Provider Category** list
   - Select **RSA** from the **Algorithm name** list
   - Type *2048* in the **Minimum key size** text box
   - Select **SHA256** from the **Request hash** list
 1. Select **OK**
 1. Close the console
-The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later).   The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates.  You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template. 
+</details>
-Sign-in to a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
+<br>
-1. Open the **Certificate Authority** management console.
+<details>
-2. Right-click **Certificate Templates** and click **Manage**.
+<summary><b>Supersede existing domain controller certificates</b></summary>
 3. In the **Certificate Templates Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**.
 4. Click the **Superseded Templates** tab. Click **Add**.
 5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**.  Click **Add**.
 6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**.  Click **Add**.
 7. From the **Add Superseded Template** dialog, select the **Kerberos Authentication** certificate template and click **OK**.  Click **Add**. 
 8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab.
 9. Click **OK** and close the **Certificate Templates** console.
-The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list.  However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities.
+The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. 
-### Configure an Internal Web Server Certificate template
+The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\
 The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template.
-Windows 10 or Windows 11 clients use the https protocol when communicating with Active Directory Federation Services.  To meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory Federation Services farm.  On-premises deployments can use a server authentication certificate issued by their enterprise PKI.  You must configure a server authentication certificate template so the host running the Active Directory Federation Service can request the certificate.
+Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
-Sign-in to a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
+1. Open the **Certification Authority** management console
-1. Open the **Certificate Authority** management console.
+1. Right-click **Certificate Templates > Manage**
-2. Right-click **Certificate Templates** and click **Manage**.
+1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties**
-3. In the **Certificate Templates Console**, right-click the **Web Server** template in the details pane and click **Duplicate Template**.
+1. Select the **Superseded Templates** tab. Select **Add**
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add**
-5. On the **General** tab, type **Internal Web Server** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise’s needs.   
+1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK**
-    **Note:** If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
+1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK**
-6. On the **Request Handling** tab, select **Allow private key to be exported**.
+1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab
-7. On the **Subject Name** tab, select the **Supply in the request** button if it is not already selected.
+1. Select **OK** and close the **Certificate Templates** console
 8. On the **Security** tab, Click **Add**. Type **Domain Computers** in the **Enter the object names to select** box.  Click **OK**. Select the **Allow** check box next to the **Enroll** permission.
 9. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.  Click **OK**. 
 10. Close the console.
-### Unpublish Superseded Certificate Templates
+The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities.
-The certificate authority only issues certificates based on published certificate templates.  For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue.  This includes the pre-published certificate template from the role installation and any superseded certificate templates.
+</details>
-The newly created domain controller authentication certificate template supersedes previous domain controller certificate templates.  Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
+<br>
 <details>
 <summary><b>Configure an internal web server certificate template</b></summary>
-Sign-in to the certificate authority or management workstation with _Enterprise Admin_ equivalent credentials.
+Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate.
 1. Open the **Certificate Authority** management console.
 2. Expand the parent node from the navigation pane.
 3. Click **Certificate Templates** in the navigation pane.
 4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**.  Click **Yes** on the **Disable certificate templates** window.
 5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates.
-### Publish Certificate Templates to the Certificate Authority
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
-The certificate authority may only issue certificates for certificate templates that are published to that certificate authority.  If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
+1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates** and select **Manage**
 1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template**
 1. On the **Compatibility** tab:
   - Clear the **Show resulting changes** check box
   - Select **Windows Server 2016** from the **Certification Authority** list
   - Select **Windows 10 / Windows Server 2016** from the **Certificate recipient** list
 1. On the **General** tab:
   - Type *Internal Web Server* in **Template display name**
   - Adjust the validity and renewal period to meet your enterprise's needs
   > [!NOTE]
   > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
 1. On the **Request Handling** tab, select **Allow private key to be exported**
 1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
 1. On the **Security** tab:
   - Select **Add**
   - Type **Domain Computers** in the **Enter the object names to select** box
   - Select **OK**
   - Select the **Allow** check box next to the **Enroll** permission
 1. On the **Cryptography** tab:
   - Select **Key Storage Provider** from the **Provider Category** list
   - Select **RSA** from the **Algorithm name** list
   - Type *2048* in the **Minimum key size** text box
   - Select **SHA256** from the **Request hash** list
   - Select **OK**
 1. Close the console
-Sign-in to the certificate authority or management workstations with an _enterprise administrator_ equivalent credentials.
+</details>
-1. Open the **Certificate Authority** management console.
+<br>
-2. Expand the parent node from the navigation pane.
+<details>
-3. Click **Certificate Templates** in the navigation pane.
+<summary><b>Configure a certificate registration authority template</b></summary>
 4. Right-click the **Certificate Templates** node.  Click **New**, and click **Certificate Template** to issue.
 5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, and **Internal Web Server** templates you created in the previous steps.  Click **OK** to publish the selected certificate templates to the certificate authority.
 6. If you published the Domain Controller Authentication (Kerberos) certificate template, then you should unpublish the certificate templates you included in the superseded templates list.
    * To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
 7. Close the console.
-### Configure Domain Controllers for Automatic Certificate Enrollment
+A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. The Windows Hello for Business on-premises certificate-based deployment uses AD FS as the CRA.
-Domain controllers automatically request a certificate from the domain controller certificate template.  However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates.  To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
+The CRA enrolls for an *enrollment agent* certificate. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request.
 Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
 1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates** and select **Manage**
 1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template**
 1. On the **Compatibility** tab:
   - Clear the **Show resulting changes** check box
   - Select **Windows Server 2016** from the **Certification Authority** list. 
   - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
 1. On the **General** tab:
   - Type *WHFB Enrollment Agent* in **Template display name**
   - Adjust the validity and renewal period to meet your enterprise's needs
 1. On the **Subject** tab, select the **Supply in the request** button if it is not already selected
   > [!NOTE]
   > Group Managed Service Accounts (GMSA) do not support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
 1. On the **Cryptography** tab:
   - Select **Key Storage Provider** from the **Provider Category** list
   - Select **RSA** from the **Algorithm name** list
   - Type *2048* in the **Minimum key size** text box
   - Select **SHA256** from the **Request hash** list
 1. On the **Security** tab, select **Add**
 1. Select **Object Types** and select the **Service Accounts** check box. Select **OK**
 1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK**
 1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:
   - In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission
   - Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared
   - Select **OK**
 1. Close the console
 </details>
 <br>
 <details>
 <summary><b>Configure a Windows Hello for Business authentication certificate template</b></summary>
 During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template.
 Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
 1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates** and select **Manage**
 1. Right-click the **Smartcard Logon** template and choose **Duplicate Template**
 1. On the **Compatibility** tab:
   - Clear the **Show resulting changes** check box
   - Select **Windows Server 2016** from the **Certification Authority** list
   - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
 1. On the **General** tab:
   - Type *WHFB Authentication* in **Template display name**
   - Adjust the validity and renewal period to meet your enterprise's needs
   > [!NOTE]
   > If you use different template names, you'll need to remember and substitute these names in different portions of the deployment.
 1. On the **Cryptography** tab
   - Select **Key Storage Provider** from the **Provider Category** list
   - Select **RSA** from the **Algorithm name** list
   - Type *2048* in the **Minimum key size** text box
   - Select **SHA256** from the **Request hash** list
 1. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**
 1. On the **Issuance Requirements** tab, 
   - Select the **This number of authorized signatures** check box. Type *1* in the text box
   - Select **Application policy** from the **Policy type required in signature**
   - Select **Certificate Request Agent** from in the **Application policy** list
   - Select the **Valid existing certificate** option
 1. On the **Subject** tab, 
   - Select the **Build from this Active Directory information** button
   - Select **Fully distinguished name** from the **Subject name format** list
   - Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
 1. On the **Request Handling** tab, select the **Renew with same key** check box
 1. On the **Security** tab, select **Add**. Type *Window Hello for Business Users* in the **Enter the object names to select** text box and select **OK**
 1. Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section:
   - Select the **Allow** check box for the **Enroll** permission
   - Excluding the **Windows Hello for Business Users** group, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes are not already cleared
   - Select **OK**
 1. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they will be superseded by this template for the users that have Enroll permission for this template
 1. Select on the **Apply** to save changes and close the console
 #### Mark the template as the Windows Hello Sign-in template
 Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials
 Open an elevated command prompt end execute the following command
 ```cmd
 certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY
 ```
 >[!NOTE]
 >If you gave your Windows Hello for Business Authentication certificate template a different name, then replace *WHFBAuthentication* in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the **Get-CATemplate** ADCS Administration Windows PowerShell cmdlet on your certification authority.
 </details>
 <br>
 <details>
 <summary><b>Unpublish Superseded Certificate Templates</b></summary>
 The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
 The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
 Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
 1. Open the **Certification Authority** management console
 1. Expand the parent node from the navigation pane > **Certificate Templates**
 1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
 1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
 </details>
 <br>
 <details>
 <summary><b>Publish certificate templates to the CA</b></summary>
 A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
 Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials.
 1. Open the **Certification Authority** management console
 1. Expand the parent node from the navigation pane
 1. Select **Certificate Templates** in the navigation pane
 1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue
 1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, *Internal Web Server*, *WHFB Enrollment Agent* and *WHFB Authentication* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority
 1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list
   - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
 1. Close the console
 </details>
 ### Configure automatic certificate enrollment for the domain controllers
 Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU).
 1. Open the **Group Policy Management Console** (gpmc.msc)
 1. Expand the domain and select the **Group Policy Object** node in the navigation pane
 1. Right-click **Group Policy object** and select **New**
 1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK**
 1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit**
 1. In the navigation pane, expand **Policies** under **Computer Configuration**
 1. Expand **Windows Settings > Security Settings > Public Key Policies**
 1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**
 1. Select **Enabled** from the **Configuration Model** list
 1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box
 1. Select the **Update certificates that use certificate templates** check box
 1. Select **OK**
 1. Close the **Group Policy Management Editor**
 ### Deploy the domain controller auto certificate enrollment GPO
 Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…**
-3. Right-click **Group Policy object** and select **New**
+1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created
-4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**.
+1. Select **OK**
 5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**.
 6. In the navigation pane, expand **Policies** under **Computer Configuration**.
 7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**.
 8. In the details pane, right-click **Certificate Services Client – Auto-Enrollment** and select **Properties**.
 9. Select **Enabled** from the **Configuration Model** list.
 10. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box.
 11. Select the **Update certificates that use certificate templates** check box.
 12. Click **OK**. Close the **Group Policy Management Editor**.
-### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
+## Validate the configuration
 Sign-in to a domain controller or management workstations with _Domain Admin_ equivalent credentials.
 1. Start the **Group Policy Management Console** (gpmc.msc)
 2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name.  Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO…**
 3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**.
 ### Validating your work
 Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase.
 You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred.
-#### Use the Event Logs
+### Use the event logs
-Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for both users and computers.  Using the Event Viewer, navigate to the **CertificateServicesClient-Lifecycle-System** event log under **Application and Services/Microsoft/Windows**.
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
-Look for an event indicating a new certificate enrollment (autoenrollment).  The details of the event include the certificate template on which the certificate was issued.  The name of the certificate template used to issue the certificate should match the certificate template name included in the event.  The certificate thumbprint and EKUs for the certificate are also included in the event.  The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template. 
+1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log
 1. Look for an event indicating a new certificate enrollment (autoenrollment):
   - The details of the event include the certificate template on which the certificate was issued
   - The name of the certificate template used to issue the certificate should match the certificate template name included in the event
   - The certificate thumbprint and EKUs for the certificate are also included in the event
   - The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template
-Certificates superseded by your new domain controller certificate generate an archive event in the CertificateServicesClient-Lifecycle-System event.  The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
+Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
 ### Certificate Manager
-#### Certificate Manager
+You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates don't appear in Certificate Manager.
-You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs.  Use **certlm.msc** to view certificate in the local computers certificate stores.  Expand the **Personal** store and view the certificates enrolled for the computer.  Archived certificates do not appear in Certificate Manager.
+### Certutil.exe
-#### Certutil.exe
+You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates.
-You can use **certutil.exe** to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer.  From an elevated command prompt, run `certutil -q -store my` to view locally enrolled certificates.
+To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
-To view detailed information about each certificate in the store, use `certutil -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates. 
+### Troubleshooting
-#### Troubleshooting
+Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate.exe /force`.
-Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates.  You can refresh Group Policy from an elevated command prompt using `gpupdate /force`.
+Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt.
-Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq -autoenroll -q` from an elevated command prompt.
+Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions.
-Use the event logs to monitor certificate enrollment and archive.  Review the configuration, such as publishing certificate templates to issuing certificate authority and the allow auto enrollment permissions.
+> [!div class="nextstepaction"]
-
+> [Next: prepare and deploy AD FS >](hello-cert-trust-adfs.md)
 ## Follow the Windows Hello for Business on premises certificate trust deployment guide
 1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
 2. Validate and Configure Public Key Infrastructure (*You are here*)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-cert-trust.md
@ -1,22 +1,20 @@
 ---
-title: Windows Hello for Business Deployment Guide - On Premises Certificate Trust Deployment
+title: Windows Hello for Business deployment guide for the on-premises certificate trust model
-description: A guide to on premises, certificate trust Windows Hello for Business deployment.
+description: Learn how to deploy Windows Hello for Business in an on-premises, certificate trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
-ms.topic: article
+ms.topic: tutorial
 ---
-# On Premises Certificate Trust Deployment
+# Deployment guide overview - on-premises certificate trust
 [!INCLUDE [hello-on-premises-cert-trust](../../includes/hello-on-premises-cert-trust.md)]
-Windows Hello for Business replaces username and password sign-in to Windows with authentication using an asymmetric key pair. This deployment guide provides the information you'll need to successfully deploy Windows Hello for Business in an existing environment.  
+Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment:
 Below, you can find all the information needed to deploy Windows Hello for Business in a Certificate Trust Model in your on-premises environment:
 1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
+2. [Validate and configure a PKI](hello-cert-trust-validate-pki.md)
-3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
+3. [Prepare and deploy AD FS](hello-cert-trust-adfs.md)
-4. [Validate and Deploy Multi-factor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
+4. [Validate and deploy multi-factor authentication (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-cert-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-key-trust.md
@ -1,21 +1,20 @@
 ---
-title: Windows Hello for Business Deployment Guide - On Premises Key Deployment
+title: Windows Hello for Business deployment guide for the on-premises key trust model
-description: A guide to on premises, key trust Windows Hello for Business deployment.
+description: Learn how to deploy Windows Hello for Business in an on-premises, key trust model.
-ms.date: 08/20/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: tutorial
 ---
-# On Premises Key Trust Deployment
+# Deployment guide overview - on-premises key trust
 [!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-Windows Hello for Business replaces username and password sign-in to Windows with strong user authentication based on asymmetric key pair.  The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in an existing environment.  
+Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment::
 Below, you can find all the information you need to deploy Windows Hello for Business in a key trust model in your on-premises environment:
 1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
-2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
+1. [Validate and configure a PKI](hello-key-trust-validate-pki.md)
-3. [Prepare and Deploy Active Directory Federation Services](hello-key-trust-adfs.md)
+1. [Prepare and deploy AD FS](hello-key-trust-adfs.md)
-4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
+1. [Validate and deploy multi-factor authentication (MFA)](hello-key-trust-validate-deploy-mfa.md)
-5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
+1. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
@ -4,22 +4,17 @@ description: Learn how to deploy certificates to cloud Kerberos trust and key tr
 ms.collection: 
  - ContentEngagementFY23
 ms.topic: article
 localizationpriority: medium
 ms.date: 11/15/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.technology: itpro-security
 ---
 # Deploy certificates for remote desktop (RDP) sign-in
 This document describes Windows Hello for Business functionalities or scenarios that apply to:\
-✅ **Deployment type:** [hybrid](hello-how-it-works-technology.md#hybrid-deployment)\
+- **Deployment type:** [!INCLUDE [hybrid](../../includes/hello-deployment-hybrid.md)]
-✅ **Trust type:** [cloud Kerberos trust](hello-hybrid-cloud-kerberos-trust.md), [ key trust](hello-how-it-works-technology.md#key-trust)\
+- **Trust type:** [!INCLUDE [cloud-kerberos](../../includes/hello-trust-cloud-kerberos.md)],[!INCLUDE [key](../../includes/hello-trust-key.md)]
-✅ **Device registration type:** [Azure AD join](hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](hello-how-it-works-technology.md#hybrid-azure-ad-join)
+- **Join type:** [!INCLUDE [hello-join-aadj](../../includes/hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](../../includes/hello-join-hybrid.md)]
 <br>
 ---
 Windows Hello for Business supports using a certificate as the supplied credential, when establishing a remote desktop connection to another Windows device. This document discusses three approaches for *cloud Kerberos trust* and *key trust* deployments, where authentication certificates can be deployed to an existing Windows Hello for Business user:
--- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
+++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md
@ -5,7 +5,7 @@ ms.collection:
  - highpri
 ms.date: 07/29/2022
 appliesto: 
- ✅ <a href=https: //learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.topic: article
 ---
--- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
+++ b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md
@ -70,6 +70,7 @@ The certificate trust model uses a securely issued certificate based on the user
 - [Deployment type](#deployment-type)
 - [Hybrid Azure AD join](#hybrid-azure-ad-join)
 - [Hybrid deployment](#hybrid-deployment)
 - [Cloud Kerberos trust](#cloud-kerberos-trust)
 - [Key trust](#key-trust)
 - [On-premises deployment](#on-premises-deployment)
 - [Trust type](#trust-type)
@ -102,6 +103,26 @@ In Windows 10 and Windows 11, cloud experience host is an application used while
 [Windows Hello for Business and device registration](./hello-how-it-works-device-registration.md)
 ## Cloud Kerberos trust
 The cloud Kerberos trust model offers a simplified deployment experience, when compared to the other trust types.\
 With cloud Kerberos trust, there's no need to deploy certificates to the users or to the domain controllers, which is ideal for environments without an existing PKI.
 Giving the simplicity offered by this model, cloud Kerberos trust is the recommended model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
 ### Related to cloud Kerberos trust
 - [Deployment type](#deployment-type)
 - [Hybrid Azure AD join](#hybrid-azure-ad-join)
 - [Hybrid deployment](#hybrid-deployment)
 - [Key trust](#key-trust)
 - [On-premises deployment](#on-premises-deployment)
 - [Trust type](#trust-type)
 ### More information about cloud Kerberos trust
 [Cloud Kerberos trust deployment](hello-hybrid-cloud-kerberos-trust.md)
 ## Deployment type
 Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
@ -223,6 +244,7 @@ The key trust model uses the user's Windows Hello for Business identity to authe
 ### Related to key trust
 - [Cloud Kerberos trust](#cloud-kerberos-trust)
 - [Certificate trust](#certificate-trust)
 - [Deployment type](#deployment-type)
 - [Hybrid Azure AD join](#hybrid-azure-ad-join)
@ -314,6 +336,7 @@ The trust type determines how a user authenticates to the Active Directory to ac
 ### Related to trust type
 - [Cloud Kerberos trust](#cloud-kerberos-trust)
 - [Certificate trust](#certificate-trust)
 - [Hybrid deployment](#hybrid-deployment)
 - [Key trust](#key-trust)
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@ -297,7 +297,7 @@ Sign in a certificate authority or management workstations with _Domain Admin eq
 3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
 5. On the **General** tab, type **AADJ WHFB Authentication** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise's needs.
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki.md
@ -37,7 +37,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
 3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certificate Recipient** list.
 5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name.  Adjust the validity and renewal period to meet your enterprise's needs.
@ -103,7 +103,7 @@ Sign-in to a certificate authority or management workstation with _Domain Admin_
 3. In the **Certificate Template Console**, right click on the **Exchange Enrollment Agent (Offline request)** template details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
 5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise's needs.
@ -134,7 +134,7 @@ Sign-in to a certificate authority or management workstation with *Domain Admin*
 3. In the **Certificate Template** console, right-click the **Exchange Enrollment Agent (Offline request)** template in the details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
 5. On the **General** tab, type **WHFB Enrollment Agent** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise's needs.
@ -160,7 +160,7 @@ Sign-in to a certificate authority or management workstation with _Domain Admin
 3. Right-click the **Smartcard Logon** template and choose **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certificate Recipient** list.
 5. On the **General** tab, type **WHFB Authentication** or your choice of template name in **Template display name**. Note the short template name for later use with CertUtil. Adjust the validity and renewal period to meet your enterprise's needs.
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md
@ -1,16 +1,16 @@
 ---
-title: Hybrid cloud Kerberos trust deployment (Windows Hello for Business)
+title: Windows Hello for Business Cloud Kerberos trust deployment
-description: Learn the information you need to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
+description: Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario.
 ms.date: 11/1/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10, version 21H2 and later</a>
 ms.topic: article
 ---
-# Hybrid cloud Kerberos trust deployment
+# Cloud Kerberos trust deployment
 [!INCLUDE [hello-hybrid-key-trust](../../includes/hello-hybrid-cloudkerb-trust.md)]
-Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a hybrid cloud Kerberos trust scenario.
+Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to successfully deploy Windows Hello for Business in a cloud Kerberos trust scenario.
 ## Introduction to cloud Kerberos trust
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
@ -33,7 +33,7 @@ Sign-in a certificate authority or management workstations with _Domain Admin_ e
 1. Open the **Certificate Authority** management console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
-4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
+4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certificate Recipient** list.
 5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name.  Adjust the validity and renewal period to meet your enterprise's needs.
   > [!NOTE]
   > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
--- a/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
+++ b/windows/security/identity-protection/hello-for-business/hello-identity-verification.md
@ -2,10 +2,11 @@
 title: Windows Hello for Business Deployment Prerequisite Overview
 description: Overview of all the different infrastructure requirements for Windows Hello for Business deployment models
 ms.collection: 
-  - highpri
+- highpri
-ms.date: 2/15/2022
+ms.date: 12/13/2022
 appliesto:
- ✅ <a href=https: //learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: article
 ---
@ -15,11 +16,10 @@ This article lists the infrastructure requirements for the different deployment
 ## Azure AD Cloud Only Deployment
-* Microsoft Azure Account
+- Azure Active Directory
-* Azure Active Directory
+- Azure AD Multifactor Authentication
-* Azure AD Multifactor Authentication
+- Device management solution (Intune or supported third-party MDM), *optional*
-* Modern Management (Intune or supported third-party MDM), *optional*
+- Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
 * Azure AD Premium subscription - *optional*, needed for automatic MDM enrollment when the device joins Azure Active Directory
 ## Hybrid Deployments
@ -27,44 +27,26 @@ The table shows the minimum requirements for each deployment. For key trust in a
 | Requirement | cloud Kerberos trust<br/>Group Policy or Modern managed | Key trust<br/>Group Policy or Modern managed | Certificate Trust<br/>Mixed managed | Certificate Trust<br/>Modern managed | 
 | --- | --- | --- | --- | --- |
-| **Windows Version** | Windows 10, version 21H2 with KB5010415; Windows 11 with KB5010414; or later | Windows 10, version 1511 or later| **Hybrid Azure AD Joined:**<br>  *Minimum:* Windows 10, version 1703<br>  *Best experience:* Windows 10, version 1709 or later (supports synchronous certificate enrollment).<br/>**Azure AD Joined:**<br>  Windows 10, version 1511 or later| Windows 10, version 1511 or later |
+| **Windows Version** | Any supported Windows client versions| Any supported Windows client versions | Any supported Windows client versions |
-| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema | Windows Server 2016 or later Schema |
+| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later schema | Windows Server 2016 or later schema | Windows Server 2016 or later schema |
 | **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  |
+| **Domain Controller Version** | Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions  |
-| **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 |
+| **Certificate Authority**| N/A |Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
-| **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 |
+| **AD FS Version** | N/A | N/A | Any supported Windows Server versions | Any supported Windows Server versions |
-| **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 |
+| **MFA Requirement** | Azure MFA, 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 |
 > [!Important]
 > - Hybrid deployments support non-destructive PIN reset that works with Certificate Trust, Key Trust and cloud Kerberos trust models.
 >
 >   **Requirements:**
 >   - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903
 >   - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
 >
 > - On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
 >
 >   **Requirements:**
 >   - Reset from settings - Windows 10, version 1703, Professional
 >   - Reset above lock screen - Windows 10, version 1709, Professional
 >   - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
 ## On-premises Deployments
 The table shows the minimum requirements for each deployment.
 | Key trust <br/> Group Policy managed | Certificate trust <br/> Group Policy managed|
 | --- | --- |
-| Windows 10, version 1703 or later | Windows 10, version 1703 or later |
+|Any supported Windows client versions|Any supported Windows client versions|
 | Windows Server 2016 Schema | Windows Server 2016 Schema|
 | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |
-| Windows Server 2016 or later Domain Controllers | Windows Server 2008 R2 or later Domain Controllers |
+| Any supported Windows Server versions  | Any supported Windows Server versions |
-| Windows Server 2012 or later Certificate Authority | Windows Server 2012 or later Certificate Authority |
+| Any supported Windows Server versions  | Any supported Windows Server versions  |
-| Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) | Windows Server 2016 AD FS with [KB4088889 update](https://support.microsoft.com/help/4088889) |
+| Any supported Windows Server versions  | Any supported Windows Server versions  |
 | AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |
 | Azure Account, optional for Azure MFA billing | Azure Account, optional for Azure MFA billing |
 > [!IMPORTANT]
 > For Windows Hello for Business key trust deployments, if you have several domains, at least one Windows Server Domain Controller 2016 or newer is required for each domain. For more information, see the [planning guide](./hello-adequate-domain-controllers.md).
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-adfs.md
@ -1,296 +1,228 @@
 ---
-title: Prepare & Deploy Windows Active Directory Federation Services with key trust (Windows Hello for Business)
+title: Prepare and deploy Active Directory Federation Services in an on-premises key trust
-description: How to Prepare and Deploy Windows Server 2016 Active Directory Federation Services for Windows Hello for Business using key trust.
+description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business key trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: tutorial
 ---
-# Prepare and Deploy Windows Server 2016 Active Directory Federation Services with Key Trust
+# Prepare and deploy Active Directory Federation Services - on-premises key trust
 [!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-Windows Hello for Business works exclusively with the Active Directory Federation Service role included with Windows Server 2016 and requires an additional server update. The on-premises key trust deployment uses Active Directory Federation Services roles for key registration and device registration.
+Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises key trust deployment model uses AD FS for *key registration* and *device registration*.
-The following guidance describes deploying a new instance of Active Directory Federation Services 2016 using the Windows Information Database as the configuration database, which is ideal for environments with no more than 30 federation servers and no more than 100 relying party trusts.
+The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
 WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
 To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
-If your environment exceeds either of these factors or needs to provide SAML artifact resolution, token replay detection, or needs Active Directory Federation Services to operate in a federated provider role, then your deployment needs to use a SQL for your configuration database. To deploy the Active Directory Federation Services using SQL as its configuration database, please review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
+A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
-If your environment has an existing instance of Active Directory Federation Services, then you’ll need to upgrade all nodes in the farm to Windows Server 2016 along with the Windows Server 2016 update. If your environment uses Windows Internal Database (WID) for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 using a WID database](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016) to upgrade your environment. If your environment uses SQL for the configuration database, please read [Upgrading to AD FS in Windows Server 2016 with SQL Server](/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016-sql) to upgrade your environment.
+Prepare the AD FS deployment by installing and **updating** two Windows Servers.
-Ensure you apply the Windows Server 2016 Update to all nodes in the farm after you have successfully completed the upgrade. 
+## Enroll for a TLS server authentication certificate
-A new Active Directory Federation Services farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
+Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
-Prepare the Active Directory Federation Services deployment by installing and updating two Windows Server 2016 Servers. Ensure the update listed below is applied to each server before continuing. 
+The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
 - **Subject Name**: the internal FQDN of the federation server
 - **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
-## Update Windows Server 2016
+The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
-Sign-in the federation server with _local admin_ equivalent credentials.
+You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
 1. Ensure Windows Server 2016 is current by running **Windows Update** from **Settings**. Continue this process until no further updates are needed. If you’re not using Windows Update for updates, please review the [Windows Server 2016 update history page](https://support.microsoft.com/help/4000825/windows-10-windows-server-2016-update-history) to make sure you have the latest updates available installed.
 2. Ensure the latest server updates to the federation server includes [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889).
->[!IMPORTANT]
+When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
 >The above referenced updates are mandatory for Windows Hello for Business all on-premises deployment and hybrid certificate trust deployments for domain joined computers.
-## Enroll for a TLS Server Authentication Certificate
+Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
-Key trust Windows Hello for Business on-premises deployments need a federation server for device registration and key registration. Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity. 
+### AD FS authentication certificate enrollment
-The AD FS role needs a server authentication certificate for the federation services, but you can use a certificate issued by your enterprise (internal) certificate authority. The server authentication certificate should have the following names included in the certificate if you are requesting an individual certificate for each node in the federation farm:
+Sign-in the federation server with *domain administrator* equivalent credentials.
 * Subject Name: The internal FQDN of the federation server (the name of the computer running AD FS)
 * Subject Alternate Name: Your federation service name, such as *fs.corp.contoso.com* (or an appropriate wildcard entry such as *.corp.contoso.com)
-You configure your federation service name when you configure the AD FS role. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server **adfs** and the federation service **fs**. The FQDN of the host is adfs.corp.contoso.com and the FQDN of the federation service is fs.corp.contoso.com.
+1. Start the Local Computer **Certificate Manager** (certlm.msc)
 1. Expand the **Personal** node in the navigation pane
 1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
 1. Select **Next** on the **Before You Begin** page
 1. Select **Next** on the **Select Certificate Enrollment Policy** page
 1. On the **Request Certificates** page, select the **Internal Web Server** check box
 1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
    :::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
 1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
 1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
 1. Select **Enroll**
-You can, however, issue one certificate for all hosts in the farm. If you chose this option, then leave the subject name blank, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name. 
+A server authentication certificate should appear in the computer's personal certificate store.
-When creating a wildcard certificate, it is recommended that you mark the private key as exportable so that the same certificate can be deployed across each federation server and web application proxy within your AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm. 
+## Deploy the AD FS role
-Be sure to enroll or import the certificate into the AD FS server’s computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
+AD FS provides *device registration* and *key registration* services to support the Windows Hello for Business on-premises deployments.
 ### Internal Server Authentication Certificate Enrollment
 Sign-in the federation server with domain administrator equivalent credentials.
 1. Start the Local Computer **Certificate Manager** (certlm.msc).
 2. Expand the **Personal** node in the navigation pane.
 3. Right-click **Personal**. Select **All Tasks** and **Request New Certificate**.
 4. Click **Next** on the **Before You Begin** page.
 5. Click **Next** on the **Select Certificate Enrollment Policy** page.
 6. On the **Request Certificates** page, Select the **Internal Web Server** check box.
 7. Click the **More information is required to enroll for this certificate. Click here to configure settings** link   
    ![Example of Certificate Properties Subject Tab - This is what shows when you click the above link.](images/hello-internal-web-server-cert.png)
 8. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the Active Directory Federation Services role and then click **Add**. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name you will use for your federation services (fs.corp.contoso.com). The name you use here MUST match the name you use when configuring the Active Directory Federation Services server role. Click **Add**. Click **OK** when finished.
 9. Click **Enroll**.
 A server authentication certificate should appear in the computer’s Personal certificate store.
 ## Deploy the Active Directory Federation Service Role
 The Active Directory Federation Service (AD FS) role provides the following services to support Windows Hello for Business on-premises deployments.
 * Device registration
 * Key registration 
 >[!IMPORTANT]
 > Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
-Windows Hello for Business depends on proper device registration. For on-premises key trust deployments, Windows Server 2016 AD FS handles device and key registration.
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
-1. Start **Server Manager**. Click **Local Server** in the navigation pane.
+1. Select **Manage > Add Roles and Features**
-2. Click **Manage** and then click **Add Roles and Features**.
+1. Select **Next** on the **Before you begin** page
-3. Click **Next** on the **Before you begin** page.
+1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
-5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
+1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
-6. On the **Select server roles** page, select **Active Directory Federation Services**. Click **Next**.
+1. Select **Next** on the **Select features** page
-7. Click **Next** on the **Select features** page.
+1. Select **Next** on the **Active Directory Federation Service** page
-8. Click **Next** on the **Active Directory Federation Service** page.
+1. Select **Install** to start the role installation
 9. Click **Install** to start the role installation.
-## Review to validate
+## Review to validate the AD FS deployment
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm the AD FS farm uses the correct database configuration.
 * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
 * Confirm **all** AD FS servers in the farm have the latest updates.
 * Confirm all AD FS servers have a valid server authentication certificate    
    * The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
    * The alternate name of the certificate contains a wildcard or the FQDN of the federation service
-## Device Registration Service Account Prerequisite
+> [!div class="checklist"]
 > * Confirm the AD FS farm uses the correct database configuration
 > * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
 > * Confirm **all** AD FS servers in the farm have the latest updates installed
 > * Confirm all AD FS servers have a valid server authentication certificate
-The service account used for the device registration server depends on the domain controllers in the environment.
+## Device registration service account prerequisites
->[!NOTE]
+The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
 >Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
-### Windows Server 2012 or later Domain Controllers
+GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
-Windows Server 2012 or later domain controllers support Group Managed Service Accounts—the preferred way to deploy service accounts for services that support them. Group Managed Service Accounts, or GMSA, have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. The best part of GMSA is all this happens automatically. AD FS supports GMSA and should be configured using them for additional defense in depth security.
+### Create KDS Root Key
-GSMA uses the Microsoft Key Distribution Service that is located on Windows Server 2012 or later domain controllers. Windows uses the Microsoft Key Distribution Service to protect secrets stored and used by the GSMA. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
+Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
-#### Create KDS Root Key
+Start an elevated PowerShell console and execute the following command:
-
+```PowerShell
-Sign-in a domain controller with _Enterprise Admin_ equivalent credentials.
+Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
-1. Start an elevated Windows PowerShell console.
+```
 2. Type `Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)`
 ### Windows Server 2008 or 2008 R2 Domain Controllers
 Windows Server 2008 and 2008 R2 domain controllers do not host the Microsoft Key Distribution Service, nor do they support Group Managed Service Accounts. Therefore, you must use or create a normal user account as a service account where you are responsible for changing the password on a regular basis.
 #### Create an AD FS Service Account
 Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
 1. Open **Active Directory Users and Computers**.
 2. Right-click the **Users** container, Click **New**. Click **User**.
 3. In the **New Object – User** window, type **adfssvc** in the **Full name** text box. Type **adfssvc** in the **User logon name** text box. Click **Next**.
 4. Enter and confirm a password for the **adfssvc** user. Clear the **User must change password at next logon** check box.
 5. Click **Next** and then click **Finish**.
 ## Configure the Active Directory Federation Service Role
->[!IMPORTANT]
+Use the following procedures to configure AD FS.
 >Follow the procedures below based on the domain controllers deployed in your environment. If the domain controller is not listed below, then it is not supported for Windows Hello for Business.
-### Windows Server 2016, 2012 R2 or later Domain Controllers
+Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2012 or later Domain Controllers**. If you are not using Windows Server 2012 or later Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2008 or 2008R2 Domain Controllers)](#windows-server-2008-or-2008-r2-domain-controllers) section.
+1. Start **Server Manager**
 1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
 1. On the **Welcome** page, select **Create the first federation server farm > Next**
 1. On the **Connect to Active Directory Domain Services** page, select **Next**
 1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
 1. Select the federation service name from the **Federation Service Name** list
 1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
 1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
 1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
 1. On the **Review Options** page, select **Next**
 1. On the **Pre-requisite Checks** page, select **Configure**
 1. When the process completes, select **Close**
-Sign-in the federation server with _Domain Admin_ equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
+### Add the AD FS service account to the *Key Admins* group
 1. Start **Server Manager**.
 2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**. 
   ![Example of pop-up notification as described above.](images/hello-adfs-configure-2012r2.png)
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
+During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
 4. Click **Next** on the **Connect to Active Directory Domain Services** page.
 5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *fs.corp.contoso.com* or *fs.contoso.com*.
 6. Select the federation service name from the **Federation Service Name** list.
 7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
 8. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type **adfssvc**.
 9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
 10. On the **Review Options** page, click **Next**.
 11. On the **Pre-requisite Checks** page, click **Configure**.
 12. When the process completes, click **Close**.
-### Windows Server 2008 or 2008 R2 Domain Controllers
+Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
-Use the following procedures to configure AD FS when your environment uses **Windows Server 2008 or 2008 R2 Domain Controllers**. If you are not using Windows Server 2008 or 2008 R2 Domain Controllers, follow the procedures under the [Configure the Active Directory Federation Service Role (Windows Server 2012 or later Domain Controllers)](#windows-server-2012-or-later-domain-controllers) section.
+1. Open **Active Directory Users and Computers**
 1. Select the **Users** container in the navigation pane
 1. Right-click **Key Admins** in the details pane and select **Properties**
 1. Select the **Members > Add…**
 1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
 1. Select **OK** to return to **Active Directory Users and Computers**
 1. Change to server hosting the AD FS role and restart it
-Sign-in the federation server with _Domain Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
+## Configure the device registration service
 1. Start **Server Manager**.
 2. Click the notification flag in the upper right corner. Click **Configure federation services on this server**.
    ![Example of pop-up notification as described above.](images/hello-adfs-configure-2012r2.png)
-3. On the **Welcome** page, click **Create the first federation server farm** and click **Next**.
+Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
 4. Click **Next** on the **Connect to Active Directory Domain Services** page.
 5. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as fs.corp.mstepdemo.net or fs.mstepdemo.net.
 6. Select the federation service name from the **Federation Service Name** list.
 7. Type the Federation Service Display Name in the text box. This is the name users see when signing in. Click **Next**.
 8. On the **Specify Service Account** page, Select **Use an existing domain user account or group Managed Service Account** and click **Select**. 
    * In the **Select User or Service Account** dialog box, type the name of the previously created AD FS service account (example adfssvc) and click **OK**. Type the password for the AD FS service account and click **Next**.
 9. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and click **Next**.
 10. On the **Review Options** page, click **Next**.
 11. On the **Pre-requisite Checks** page, click **Configure**.
 12. When the process completes, click **Close**.
 13. Do not restart the AD FS server. You will do this later.
 1. Open the **AD FS management** console
 1. In the navigation pane, expand **Service**. Select **Device Registration**
 1. In the details pane, select **Configure device registration**
 1. In the **Configure Device Registration** dialog, Select **OK**
-### Add the AD FS Service account to the KeyAdmins group
+:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png"  alt-text="AD FS device registration: configuration of the service connection point.":::
-The KeyAdmins global group provides the AD FS service with the permissions needed to perform key registration.
+Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="AD FS device registration: service connection point object created by AD FS.":::
 1. Open **Active Directory Users and Computers**.
 2. Click the **Users** container in the navigation pane.
 3. Right-click **KeyAdmins** in the details pane and click **Properties**.
 4. Click the **Members** tab and click **Add…**
 5. In the **Enter the object names to select** text box, type **adfssvc**. Click **OK**.
 6. Click **OK** to return to **Active Directory Users and Computers**.
 7. Change to server hosting the AD FS role and restart it.
-
+## Review to validate the AD FS and Active Directory configuration
 ## Configure the Device Registration Service
 Sign-in the federation server with _Enterprise Admin_ equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
 1. Open the **AD FS management** console.
 2. In the navigation pane, expand **Service**. Click **Device Registration**.
 3. In the details pane, click **Configure Device Registration**.
 4. In the **Configure Device Registration** dialog, click **OK**.
 ## Review and validate
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm you followed the correct procedures based on the domain controllers used in your deployment   
    * Windows Server 2016, 2012 R2 or Windows Server 2012 R2
    * Windows Server 2008 or Windows Server 2008 R2
 * Confirm you have the correct service account based on your domain controller version.
 * Confirm you properly installed the AD FS role on your Windows Server 2016 based on the proper sizing of your federation, the number of relying parties, and database needs.
 * Confirm you used a certificate with the correct names as the server authentication certificate
    * Record the expiration date of the certificate and set a renewal reminder at least six weeks before it expires that includes the:
        * Certificate serial number
        * Certificate thumbprint
        * Common name of the certificate
        * Subject alternate name of the certificate
        * Name of the physical host server
        * The issued date
        * The expiration date
        * Issuing CA Vendor (if a third-party certificate) 
 * Confirm you added the AD FS service account to the KeyAdmins group.
 * Confirm you enabled the Device Registration service.
 > [!div class="checklist"]
 > * Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
 > * Confirm you added the AD FS service account to the KeyAdmins group
 > * Confirm you enabled the Device Registration service
-## Additional Federation Servers
+## Additional federation servers
 Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
-### Server Authentication Certificate
+### Server authentication certificate
 Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
-### Install Additional Servers
+### Install additional servers
 Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
-## Load Balance AD FS Federation Servers
+## Load balance AD FS
 Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
 ### Install Network Load Balancing Feature on AD FS Servers
-Sign-in the federation server with _Enterprise Admin_ equivalent credentials.
+Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
-1. Start **Server Manager**. Click **Local Server** in the navigation pane.
+
-2. Click **Manage** and then click **Add Roles and Features**.
+1. Start **Server Manager**. Select **Local Server** in the navigation pane
-3. Click **Next** On the **Before you begin** page.
+1. Select **Manage** and then select **Add Roles and Features**
-4. On the **Select installation type** page, select **Role-based or feature-based installation** and click **Next**.
+1. Select **Next** On the **Before you begin** page
-5. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Click **Next**.
+1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
-6. On the **Select server roles** page, click **Next**.
+1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
-7. Select **Network Load Balancing** on the **Select features** page.
+1. On the **Select server roles** page, select **Next**
-8. Click **Install** to start the feature installation   
+1. Select **Network Load Balancing** on the **Select features** page
-    ![Feature selection screen with NLB selected.](images/hello-nlb-feature-install.png)
+1. Select **Install** to start the feature installation
 ### Configure Network Load Balancing for AD FS
 Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
-Sign-in a node of the federation farm with _Admin_ equivalent credentials.
+Sign-in a node of the federation farm with *Administrator* equivalent credentials.
-1. Open **Network Load Balancing Manager** from **Administrative Tools**. 
+
-    ![NLB Manager user interface.](images/hello-nlb-manager.png)
+1. Open **Network Load Balancing Manager** from **Administrative Tools**
-2. Right-click **Network Load Balancing Clusters**, and then click **New Cluster**.
+1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
-3. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then click **Connect**. 
+1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
-    ![NLB Manager - Connect to new Cluster screen.](images/hello-nlb-connect.png)
+1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
-4. Select the interface that you want to use with the cluster, and then click **Next**. (The interface hosts the virtual IP address and receives the client traffic to load balance.)
+1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
-5. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Click **Next**.
+1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
-6. In **Cluster IP Addresses**, click **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Click **Next**. 
+1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
-    ![NLB Manager - Add IP to New Cluster screen.](images/hello-nlb-add-ip.png)
+1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
-7. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster. 
+1. In Port Rules, select Edit to modify the default port rules to use port 443
    ![NLB Manager - Cluster IP Configuration screen.](images/hello-nlb-cluster-ip-config.png)
 8. In **Cluster operation mode**, click **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Click **Next**.
 9. In Port Rules, click Edit to modify the default port rules to use port 443. 
    ![NLB Manager - Add\Edit Port Rule screen.](images/hello-nlb-cluster-port-rule.png)
 ### Additional AD FS Servers
-1. To add more hosts to the cluster, right-click the new cluster, and then click **Add Host to Cluster**.
+1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
-2. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same. 
+1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
    ![NLB Manager - Cluster with nodes.](images/hello-nlb-cluster.png)
 ## Configure DNS for Device Registration
-Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials. You’ll need the Federation service name to complete this task. You can view the federation service name by clicking **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
+Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
-1. Open the **DNS Management** console.
+You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
-2. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**.
+
-3. In the navigation pane, select the node that has the name of your internal Active Directory domain name.
+1. Open the **DNS Management** console
-4. In the navigation pane, right-click the domain name node and click **New Host (A or AAAA)**.
+1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
-5. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Click **Add Host**. 
+1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
-6. Right-click the `domain_name` node and select **New Alias (CNAME)**.
+1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
-7. In the **New Resource Record** dialog box, type "enterpriseregistration" in the **Alias** name box.
+1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
-8. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.domain_name.com`, and click OK.
+1. Right-click the `<domain_name>` node and select **New Alias (CNAME)**
-9. Close the DNS Management console.
+1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
 1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.<domain_name_fqdn`, and select OK
 1. Close the DNS Management console
 > [!NOTE]
-> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.upnsuffix.com` is present for each suffix.
+> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.<upnsuffix_fqdn>` is present for each suffix.
 ## Configure the Intranet Zone to include the federation service
@ -300,38 +232,30 @@ The Windows Hello provisioning presents web pages from the federation service. C
 Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
-3. Right-click **Group Policy object** and select **New**
+1. Right-click **Group Policy object** and select **New**
-4. Type **Intranet Zone Settings** in the name box and click **OK**.
+1. Type **Intranet Zone Settings** in the name box and select **OK**
-5. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and click **Edit**.
+1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
-6. In the navigation pane, expand **Policies** under **Computer Configuration**.
+1. In the navigation pane, expand **Policies** under **Computer Configuration**
-7. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel**, and select **Security Page**.
+1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
-8. In the content pane, double-click **Site to Zone Assignment List**. Click **Enable**.
+1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
 9. Click **Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Click OK twice, then close the Group Policy Management Editor.
 ### Deploy the Intranet Zone Group Policy object
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO…**
+1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
-3. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
+1. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
-## Review
+## Review to validate the configuration
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm all AD FS servers have a valid server authentication certificate    
    * The subject of the certificate is the common name (FQDN) of the host or a wildcard name.
    * The alternate name of the certificate contains a wildcard or the FQDN of the federation service
 * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load.
 * Confirm **all** AD FS servers in the farm have the latest updates.
 * Confirm you restarted the AD FS service.
 * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
 * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
 > [!div class="checklist"]
 > * Confirm all AD FS servers have a valid server authentication certificate. The subject of the certificate is the common name (FQDN) of the host or a wildcard name. The alternate name of the certificate contains a wildcard or the FQDN of the federation service
 > * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
 > * Confirm you restarted the AD FS service
 > * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
 > * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
+> [!div class="nextstepaction"]
-
+> [Next: validate and deploy multi-factor authentication (MFA)](hello-key-trust-validate-deploy-mfa.md)
 1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
 2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
 3. Prepare and Deploy Windows Server 2016 Active Directory Federation Services (*You are here*)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-policy-settings.md
@ -1,64 +1,63 @@
 ---
-title: Configure Windows Hello for Business Policy settings - key trust
+title: Configure Windows Hello for Business Policy settings in an on-premises key trust
-description: Configure Windows Hello for Business Policy settings for Windows Hello for Business
+description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises key trust scenario
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: tutorial
 ---
-# Configure Windows Hello for Business Policy settings - Key Trust
+# Configure Windows Hello for Business group policy settings - on-premises key trust
 [!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-To run the Group Policy Management Console from a Windows client, you need to install the Remote Server Administration Tools for Windows. You can download these tools from [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520).
+On-premises key trust deployments of Windows Hello for Business need one Group Policy setting: *Enable Windows Hello for Business*.
 The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.
-Alternatively, you can create a copy of the .ADMX and .ADML files from a Windows client installation setup template folder to their respective language folder on a Windows Server, or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for more information.
+If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business.
-On-premises certificate-based deployments of Windows Hello for Business needs one Group Policy setting:  Enable Windows Hello for Business
+## Enable Windows Hello for Business group policy setting
 ## Enable Windows Hello for Business Group Policy
 The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users.
-If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business. For these settings to be configured using GPO, you need to download and install the latest Administrative Templates (.admx) for Windows.
+If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business .
 ## Create the GPO
-## Create the Windows Hello for Business Group Policy object
+Sign in to a domain controller or management workstations with *Domain Administrator* equivalent credentials.
 The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed.
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
-3. Right-click **Group Policy object** and select **New**.
+1. Right-click **Group Policy object** and select **New**
-4. Type *Enable Windows Hello for Business* in the name box and click **OK**.
+1. Type *Enable Windows Hello for Business* in the name box and select **OK**
-5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
+1. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and select **Edit**
-6. In the navigation pane, expand **Policies** under **User Configuration**.
+1. In the navigation pane, select **User Configuration > Policies > **Administrative Templates > Windows Component > Windows Hello for Business**
-7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
+1. In the content pane, double-click **Use Windows Hello for Business**. Select **Enable** and **OK**
-8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**.
+1. Close the **Group Policy Management Editor**
 9. Close the **Group Policy Management Editor**.
-## Configure Security in the Windows Hello for Business Group Policy object
+## Configure security in the Windows Hello for Business GPO
 The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases.
 Sign in to a domain controller or management workstations with *Domain Administrator* equivalent credentials.
 1. Start the **Group Policy Management Console** (gpmc.msc)
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+1. Expand the domain and select the **Group Policy Object** node in the navigation pane
-3. Double-click the **Enable Windows Hello for Business** Group Policy object.
+1. Double-click the **Enable Windows Hello for Business** Group Policy object
-4. In the **Security Filtering** section of the content pane, click **Add**.  Type *Windows Hello for Business Users* or the name of the security group you previously created and click **OK**.
+1. In the **Security Filtering** section of the content pane, select **Add**.  Type *Windows Hello for Business Users* or the name of the security group you previously created and select **OK**
-5. Click the **Delegation** tab. Select **Authenticated Users** and click **Advanced**.
+1. Select the **Delegation** tab. Select **Authenticated Users** and **Advanced**
-6. In the **Group or User names** list, select **Authenticated Users**.  In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Click **OK**.
+1. In the **Group or User names** list, select **Authenticated Users**.  In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK**
 ## Deploy the Windows Hello for Business Group Policy object
-The application of the Windows Hello for Business Group Policy object uses security group filtering.  This enables you to link the Group Policy object at the domain, ensuring the Group Policy object is within scope to all users. However, the security group filtering ensures only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business.
+The application of the Windows Hello for Business Group Policy object uses security group filtering. This solution enables you to link the Group Policy object at the domain level, ensuring the GPO is within scope to all users. However, the security group filtering ensures that only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business.
 1. Start the **Group Policy Management Console** (gpmc.msc)
 2. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and click **Link an existing GPO…**
 3. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and click **OK**.
-Just to reassure, linking the **Windows Hello for Business** Group Policy object to the domain ensures the Group Policy object is in scope for all domain users. However, not all users will have the policy settings applied to them. Only users who are members of the Windows Hello for Business group receive the policy settings. All others users ignore the Group Policy object. 
+1. Start the **Group Policy Management Console** (gpmc.msc)
 1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
 1. In the **Select GPO** dialog box, select **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
 ## Other Related Group Policy settings
 ### Windows Hello for Business
 There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment.  These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. 
 ### Use a hardware security device
@ -73,47 +72,37 @@ Another policy setting becomes available when you enable the **Use a hardware se
 Windows Hello for Business provides a great user experience when combined with the use of biometrics.  Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security.  
-The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers.  The policy setting disabled all biometrics.  Currently, Windows does not provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition, but disallowing fingerprint recognition.
+The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disables all biometrics. Currently, Windows does not provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition, but disallowing fingerprint recognition.
 ### PIN Complexity
 PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed.
-Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use.  If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically; however, you can deploy Group Policy to provide to accomplish a variety of configurations.  The policy settings included are:
+Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically. The policy settings included are:
 * Require digits
 * Require lowercase letters
 * Maximum PIN length
 * Minimum PIN length
 * Expiration
 * History
 * Require special characters
 * Require uppercase letters
-In the Windows 10, version 1703, the PIN complexity Group Policy settings have moved to remove misunderstanding that PIN complexity policy settings were exclusive to Windows Hello for Business. The new location of these Group Policy settings is under Administrative Templates\System\PIN Complexity under both the Computer and User Configuration nodes of the Group Policy editor.
+- Require digits
 - Require lowercase letters
 - Maximum PIN length
 - Minimum PIN length
 - Expiration
 - History
 - Require special characters
 - Require uppercase letters
-## Review
+The settings can be found in *Administrative Templates\System\PIN Complexity*, under both the Computer and User Configuration nodes of the Group Policy editor.
 ## Review to validate the configuration
 Before you continue with the deployment, validate your deployment progress by reviewing the following items:
 * Confirm you authored Group Policy settings using the latest ADMX/ADML files (from the Windows 10 Creators Editions)
 * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
 * Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting.
 * Confirm you configure automatic certificate enrollment to the scope that matches your deployment (Computer vs. User)
 * Confirm you configured the proper security settings for the Group Policy object   
    * Removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
    * Add the Windows Hello for Business Users group to the Group Policy object and gave the group the allow permission for Apply Group Policy
 * Linked the Group Policy object to the correct locations within Active Directory
 * Deploy any additional Windows Hello for Business Group Policy setting is a policy separate from the one that enables it for users
 > [!div class="checklist"]
 > * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
 > * Confirm you configured the proper security settings for the Group Policy object   
 > * Confirm you removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions)
 > * Confirm you added the Windows Hello for Business Users group to the Group Policy object, and gave the group the allow permission to Apply Group Policy
 > * Linked the Group Policy object to the correct locations within Active Directory
 > * Deployed any additional Windows Hello for Business Group Policy settings
 ## Add users to the Windows Hello for Business Users group
-Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the Windows Hello for Business Users group.   Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business.
+Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the *Windows Hello for Business Users* group. Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business.
 ## Follow the Windows Hello for Business on premises certificate trust deployment guide
 1. [Validate Active Directory prerequisites](hello-cert-trust-validate-ad-prereq.md)
 2. [Validate and Configure Public Key Infrastructure](hello-cert-trust-validate-pki.md)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-cert-trust-adfs.md)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-cert-trust-validate-deploy-mfa.md)
 5. Configure Windows Hello for Business Policy settings (*You are here*)
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-ad-prereq.md
@ -1,39 +1,32 @@
 ---
-title: Key registration for on-premises deployment of Windows Hello for Business
+title: Validate Active Directory prerequisites in an on-premises key trust
-description: How to Validate Active Directory prerequisites for Windows Hello for Business when deploying with the key trust model.
+description: Validate Active Directory prerequisites when deploying Windows Hello for Business in a key trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: tutorial
 ---
-# Validate Active Directory prerequisites - Key Trust
+# Validate Active Directory prerequisites - on-premises key trust
 [!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-Key trust deployments need an adequate number of 2016 or later domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md), the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
+Key trust deployments need an adequate number of domain controllers to ensure successful user authentication with Windows Hello for Business. To learn more about domain controller planning for key trust deployments, read the [Windows Hello for Business planning guide](hello-planning-guide.md) and the [Planning an adequate number of Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) section.
-> [!NOTE]
+The key registration process for the on-premises deployment of Windows Hello for Business requires the Windows Server 2016 Active Directory or later schema.
 >There was an issue with key trust authentication on Windows Server 2019. If you are planning to use Windows Server 2019 domain controllers refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044) to fix this issue.
-The key registration process for the On-premises deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory or later schema.  The key-trust model receives the schema extension when the first Windows Server 2016 domain controller is added to the forest.  The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
+## Create the Windows Hello for Business Users security group
-## Create the Windows Hello for Business Users Security Global Group
+The *Windows Hello for Business Users* group is used to make it easy to deploy Windows Hello for Business in phases. You assign Group Policy permissions to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business.
-The Windows Hello for Business Users group is used to make it easy to deploy Windows Hello for Business in phases.  You assign Group Policy permissions to this group to simplify the deployment by simply adding the users to the group.  This provides users with the proper permissions to provision Windows Hello for Business.
+Sign-in to a domain controller or to a management workstation with a *Domain Administrator* equivalent credentials.
-Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+1. Open **Active Directory Users and Computers**
 1. Select **View > Advanced Features**
 1. Expand the domain node from the navigation pane
 1. Right-click the **Users** container. Select **New > Group**
 1. Type *Windows Hello for Business Users* in the **Group Name**
 1. Select **OK**
-1. Open **Active Directory Users and Computers**.
+> [!div class="nextstepaction"]
-2. Click **View** and click **Advanced Features**.
+> [Next: validate and configure PKI >](hello-key-trust-validate-pki.md)
 3. Expand the domain node from the navigation pane.
 4. Right-click the **Users** container. Click **New**. Click **Group**.
 5. Type **Windows Hello for Business Users** in the **Group Name** text box.
 6. Click **OK**.
 ## Follow the Windows Hello for Business on premises certificate trust deployment guide
 1. Validate Active Directory prerequisites (*You are here*)
 2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa.md
@ -1,28 +1,29 @@
 ---
 title: Validate and Deploy MFA for Windows Hello for Business with key trust
-description: How to Validate and Deploy Multifactor Authentication (MFA) Services for Windows Hello for Business with key trust
+description: Validate and deploy multi-factor authentication (MFA) for Windows Hello for Business in an on-premises key trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: tutorial
 ---
-# Validate and Deploy Multifactor Authentication (MFA)
+
 # Validate and deploy multi-factor authentication - on-premises key trust
 [!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-> [!IMPORTANT]
+Windows Hello for Business requires users perform multi-factor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
 > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
-Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential.  On-premises deployments can use certificates, third-party authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA option.
+- certificates
 - third-party authentication providers for AD FS
 - custom authentication provider for AD FS
 > [!IMPORTANT]
 > As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
 For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
 Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multi-factor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
-## Follow the Windows Hello for Business on premises certificate trust deployment guide
+> [!div class="nextstepaction"]
-
+> [Next: configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
 1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
 2. [Validate and Configure Public Key Infrastructure](hello-key-trust-validate-pki.md)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
 4. Validate and Deploy Multifactor Authentication Services (MFA) (*You are here*)
 5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
+++ b/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md
@ -1,245 +1,248 @@
 ---
-title: Validate Public Key Infrastructure - key trust model (Windows Hello for Business)
+title: Configure and validate the Public Key Infrastructure in an on-premises key trust model
-description: How to Validate Public Key Infrastructure for Windows Hello for Business, under a key trust model.
+description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a key trust model.
-ms.date: 08/19/2018
+ms.date: 12/12/2022
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
-ms.topic: article
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ms.topic: tutorial
 ---
-# Validate and Configure Public Key Infrastructure - Key Trust
+# Configure and validate the Public Key Infrastructure - on-premises key trust
 [!INCLUDE [hello-on-premises-key-trust](../../includes/hello-on-premises-key-trust.md)]
-Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model.  All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller.  
+Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers.
-## Deploy an enterprise certificate authority
+## Deploy an enterprise certification authority
-This guide assumes most enterprises have an existing public key infrastructure.  Windows Hello for Business depends on a Windows enterprise public key infrastructure running the Active Directory Certificate Services role from Windows Server 2012 or later.
+This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.
-### Lab-based public key infrastructure
+### Lab-based PKI
-The following instructions may be used to deploy simple public key infrastructure that is suitable for a lab environment.
+The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**.
-Sign in using **Enterprise Admin** equivalent credentials on Windows Server 2012 or later server where you want the certificate authority installed.
+Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed.
 >[!NOTE]
->Never install a certificate authority on a domain controller in a production environment.
+>Never install a certification authority on a domain controller in a production environment.
-1. Open an elevated Windows PowerShell prompt.
+1. Open an elevated Windows PowerShell prompt
-2. Use the following command to install the Active Directory Certificate Services role.   
+1. Use the following command to install the Active Directory Certificate Services role.
    ```PowerShell
    Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
    ```
-
+3. Use the following command to configure the CA using a basic certification authority configuration
 3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.   
    ```PowerShell
    Install-AdcsCertificationAuthority
    ```
-## Configure a Production Public Key Infrastructure
+## Configure a PKI
-If you do have an existing public key infrastructure, please review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) from Microsoft TechNet to properly design your infrastructure.   Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your public key infrastructure using the information from your design session.
+If you have an existing PKI, review [Certification Authority Guidance](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)) to properly design your infrastructure.  Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11)) for instructions on how to configure your PKI using the information from your design session.
-### Configure Domain Controller Certificates
+Expand the following sections to configure the PKI for Windows Hello for Business.
-Clients need to trust domain controllers and the best way to do this is to ensure each domain controller has a Kerberos Authentication certificate.  Installing a certificate on the domain controller enables the Key Distribution Center (KDC) to prove its identity to other members of the domain.  This provides clients a root of trust external to the domain—namely the enterprise certificate authority.
+<br>
 <details>
 <summary><b>Configure domain controller certificates</b></summary>
-Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise certificate authority is added to Active Directory.  However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates do not include the KDC Authentication object identifier (OID), which was later added to the Kerberos RFC.  Therefore, domain controllers need to request a certificate based on the Kerberos Authentication certificate template.
+Clients must trust the domain controllers, and to it each domain controller must have a *Kerberos Authentication* certificate. Installing a certificate on the domain controllers enables the Key Distribution Center (KDC) to prove its identity to other members of the domain. The certificates provide clients a root of trust external to the domain, namely the *enterprise certification authority*.
-By default, the Active Directory Certificate Authority provides and publishes the Kerberos Authentication certificate template.  However, the cryptography configuration included in the provided template is based on older and less performant cryptography APIs.  To ensure domain controllers request the proper certificate with the best available cryptography, use the Kerberos Authentication certificate template as a baseline to create an updated domain controller certificate template.
+Domain controllers automatically request a domain controller certificate (if published) when they discover an enterprise CA is added to Active Directory. However, certificates based on the Domain Controller and Domain Controller Authentication certificate templates don't include the *KDC Authentication* object identifier (OID), which was later added to the Kerberos RFC. Therefore, domain controllers need to request a certificate based on the *Kerberos Authentication* certificate template.
-Sign in to a certificate authority or management workstations with **Domain Admin** equivalent credentials.
+By default, the Active Directory CA provides and publishes the *Kerberos Authentication* certificate template. The cryptography configuration included in the template is based on older and less performant cryptography APIs. To ensure domain controllers request the proper certificate with the best available cryptography, use the *Kerberos Authentication* certificate template as a *baseline* to create an updated domain controller certificate template.
-1. Open the **Certificate Authority** management console.
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and click **Duplicate Template**.
 4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2008 R2** from the **Certification Authority** list. Select **Windows 7.Server 2008 R2** from the **Certification Recipient** list.
 5. On the **General** tab, type **Domain Controller Authentication (Kerberos)** in Template display name.  Adjust the validity and renewal period to meet your enterprise’s needs.   
 1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates > Manage**
 1. In the **Certificate Template Console**, right-click the **Kerberos Authentication** template in the details pane and select **Duplicate Template**
 1. On the **Compatibility** tab:
   - Clear the **Show resulting changes** check box
   - Select **Windows Server 2016** from the **Certification Authority** list
   - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
 1. On the **General** tab
   - Type *Domain Controller Authentication (Kerberos)* in Template display name
   - Adjust the validity and renewal period to meet your enterprise's needs
   > [!NOTE]
-    > If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
+   > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
 1. On the **Subject Name** tab:
   - Select the **Build from this Active Directory information** button if it isn't already selected
   - Select **None** from the **Subject name format** list
   - Select **DNS name** from the **Include this information in alternate subject** list
   - Clear all other items
 1. On the **Cryptography** tab:
   - select **Key Storage Provider** from the **Provider Category** list
   - Select **RSA** from the **Algorithm name** list
   - Type *2048* in the **Minimum key size** text box
   - Select **SHA256** from the **Request hash** list
 1. Select **OK**
 1. Close the console
-6. On the **Subject Name** tab, select the **Build from this Active Directory information** button if it is not already selected.  Select **None** from the **Subject name format** list.  Select **DNS name** from the **Include this information in alternate subject** list. Clear all other items.
+</details>
 7. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.  Click **OK**. 
-8. Close the console.
+<br>
 <details>
 <summary><b>Supersede existing domain controller certificates</b></summary>
-### Superseding the existing Domain Controller certificate
+The domain controllers may have an existing domain controller certificate. The Active Directory Certificate Services provides a default certificate template for domain controllers called *domain controller certificate*. Later releases of Windows Server provided a new certificate template called *domain controller authentication certificate*. These certificate templates were provided prior to the update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the *KDC Authentication* extension. 
-Many domain controllers may have an existing domain controller certificate.  The Active Directory Certificate Services provides a default certificate template from domain controllers—the domain controller certificate template.  Later releases provided a new certificate template—the domain controller authentication certificate template.  These certificate templates were provided prior to update of the Kerberos specification that stated Key Distribution Centers (KDCs) performing certificate authentication needed to include the KDC Authentication extension.  
+The *Kerberos Authentication* certificate template is the most current certificate template designated for domain controllers, and should be the one you deploy to all your domain controllers.\
 The *autoenrollment* feature allows you to replace the domain controller certificates. Use the following configuration to replace older domain controller certificates with new ones, using the *Kerberos Authentication* certificate template.
-The Kerberos Authentication certificate template is the most current certificate template designated for domain controllers and should be the one you deploy to all your domain controllers (2008 or later).   The autoenrollment feature in Windows enables you to effortlessly replace these domain controller certificates.  You can use the following configuration to replace older domain controller certificates with a new certificate using the Kerberos Authentication certificate template. 
+Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials.
-Sign in to a certificate authority or management workstations with _Enterprise Admin_ equivalent credentials.
+1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates > Manage**
 1. In the **Certificate Template Console**, right-click the *Domain Controller Authentication (Kerberos)* (or the name of the certificate template you created in the previous section) template in the details pane and select **Properties**
 1. Select the **Superseded Templates** tab. Select **Add**
 1. From the **Add Superseded Template** dialog, select the *Domain Controller* certificate template and select **OK > Add**
 1. From the **Add Superseded Template** dialog, select the *Domain Controller Authentication* certificate template and select **OK**
 1. From the **Add Superseded Template** dialog, select the *Kerberos Authentication* certificate template and select **OK**
 1. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab
 1. Select **OK** and close the **Certificate Templates** console
-1. Open the **Certificate Authority** management console.
+The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list. However, the certificate template and the superseding of certificate templates isn't active until the certificate template is published to one or more certificate authorities.
-2. Right-click **Certificate Templates** and click **Manage**.
+</details>
-3. In the **Certificate Template Console**, right-click the **Domain Controller Authentication (Kerberos)** (or the name of the certificate template you created in the previous section) template in the details pane and click **Properties**.
+<br>
 <details>
 <summary><b>Configure an internal web server certificate template</b></summary>
-4. Click the **Superseded Templates** tab. Click **Add**.
+Windows clients use the https protocol when communicating with Active Directory Federation Services (AD FS). To meet this need, you must issue a server authentication certificate to all the nodes in the AD FS farm. On-premises deployments can use a server authentication certificate issued by their enterprise PKI. You must configure a server authentication certificate template so the host running theAD FS can request the certificate.
-5. From the **Add Superseded Template** dialog, select the **Domain Controller** certificate template and click **OK**.  Click **Add**.
+Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
 6. From the **Add Superseded Template** dialog, select the **Domain Controller Authentication** certificate template and click **OK**.
 7. From the **Add Superseded Template dialog**, select the **Kerberos Authentication** certificate template and click **OK**. 
 8. Add any other enterprise certificate templates that were previously configured for domain controllers to the **Superseded Templates** tab.
 9. Click **OK** and close the **Certificate Templates** console.
 The certificate template is configured to supersede all the certificate templates provided in the certificate templates superseded templates list.  However, the certificate template and the superseding of certificate templates is not active until you publish the certificate template to one or more certificate authorities.
 ### Configure an Internal Web Server Certificate template
 Windows clients use the https protocol when communicating with Active Directory Federation Services.  To meet this need, you must issue a server authentication certificate to all the nodes in the Active Directory Federation Services farm.  On-premises deployments can use a server authentication certificate issued by their enterprise PKI.  You must configure a server authentication certificate template so the host running the Active Directory Federation Service can request the certificate. 
 Sign in to a certificate authority or management workstations with _Domain Admin_ equivalent credentials.
 1. Open the **Certificate Authority** management console.
 2. Right-click **Certificate Templates** and click **Manage**.
 3. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and click **Duplicate Template**.
 4. On the **Compatibility** tab, clear the **Show resulting changes** check box.  Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Authority** list. Select **Windows Server 2012** or **Windows Server 2012 R2** from the **Certification Recipient** list.
 5. On the **General** tab, type **Internal Web Server** in **Template display name**.  Adjust the validity and renewal period to meet your enterprise’s needs.
 1. Open the **Certification Authority** management console
 1. Right-click **Certificate Templates** and select **Manage**
 1. In the **Certificate Template Console**, right-click the **Web Server** template in the details pane and select **Duplicate Template**
 1. On the **Compatibility** tab:
   - Clear the **Show resulting changes** check box
   - Select **Windows Server 2016** from the **Certification Authority** list
   - Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
 1. On the **General** tab:
   - Type *Internal Web Server* in **Template display name**
   - Adjust the validity and renewal period to meet your enterprise's needs
   > [!NOTE]
-    > If you use different template names, you’ll need to remember and substitute these names in different portions of the lab.
+   > If you use different template names, you'll need to remember and substitute these names in different portions of the lab.
 1. On the **Request Handling** tab, select **Allow private key to be exported**
 1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
 1. On the **Security** tab:
   - Select **Add**
   - Type **Domain Computers** in the **Enter the object names to select** box
   - Select **OK**
   - Select the **Allow** check box next to the **Enroll** permission
 1. On the **Cryptography** tab:
   - Select **Key Storage Provider** from the **Provider Category** list
   - Select **RSA** from the **Algorithm name** list
   - Type *2048* in the **Minimum key size** text box
   - Select **SHA256** from the **Request hash** list
   - Select **OK**
 1. Close the console
-6. On the **Request Handling** tab, select **Allow private key to be exported**.
+</details>
-7. On the **Subject** tab, select the **Supply in the request** button if it is not already selected.
+<br>
 <details>
 <summary><b>Unpublish Superseded Certificate Templates</b></summary>
-8. On the **Security** tab, Click **Add**. Type **Domain Computers** in the **Enter the object names to select** box.  Click **OK**. Select the **Allow** check box next to the **Enroll** permission.
+The certification authority only issues certificates based on published certificate templates. For security, it's a good practice to unpublish certificate templates that the CA isn't configured to issue. This includes the pre-published certificate template from the role installation and any superseded certificate templates.
-9. On the **Cryptography** tab, select **Key Storage Provider** from the **Provider Category** list.  Select **RSA** from the **Algorithm name** list.  Type **2048** in the **Minimum key size** text box.  Select **SHA256** from the **Request hash** list.  Click **OK**.
+The newly created *domain controller authentication* certificate template supersedes previous domain controller certificate templates. Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
-10. Close the console.
+Sign in to the CA or management workstation with *Enterprise Administrator* equivalent credentials.
-### Unpublish Superseded Certificate Templates
+1. Open the **Certification Authority** management console
 1. Expand the parent node from the navigation pane > **Certificate Templates**
 1. Right-click the *Domain Controller* certificate template and select **Delete**. Select **Yes** on the **Disable certificate templates** window
 1. Repeat step 3 for the *Domain Controller Authentication* and *Kerberos Authentication* certificate templates
-The certificate authority only issues certificates based on published certificate templates.  For defense in depth security, it is a good practice to unpublish certificate templates that the certificate authority is not configured to issue.  This includes the pre-published certificate template from the role installation and any superseded certificate templates.
+</details>
-The newly created domain controller authentication certificate template supersedes previous domain controller certificate templates.  Therefore, you need to unpublish these certificate templates from all issuing certificate authorities.
+<br>
 <details>
 <summary><b>Publish certificate templates to the CA</b></summary>
-Sign in to the certificate authority or management workstation with _Enterprise Admin_ equivalent credentials.
+A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them.
-1. Open the **Certificate Authority** management console.
+Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials.
-2. Expand the parent node from the navigation pane.
+1. Open the **Certification Authority** management console
 1. Expand the parent node from the navigation pane
 1. Select **Certificate Templates** in the navigation pane
 1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue
 1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, and *Internal Web Server* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority
 1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list
   - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation
 1. Close the console
-3. Click **Certificate Templates** in the navigation pane.
+</details>
-4. Right-click the **Domain Controller** certificate template in the content pane and select **Delete**.  Click **Yes** on the **Disable certificate templates** window.
+### Configure automatic certificate enrollment for the domain controllers
-5. Repeat step 4 for the **Domain Controller Authentication** and **Kerberos Authentication** certificate templates.
+Domain controllers automatically request a certificate from the *Domain controller certificate* template. However, domain controllers are unaware of newer certificate templates or superseded configurations on certificate templates. To continue automatic enrollment and renewal of domain controller certificates, create and configure a Group Policy Object (GPO) for automatic certificate enrollment, linking the Group Policy object to the *Domain Controllers* Organizational Unit (OU).
-### Publish Certificate Templates to the Certificate Authority
+1. Open the **Group Policy Management Console** (gpmc.msc)
 1. Expand the domain and select the **Group Policy Object** node in the navigation pane
 1. Right-click **Group Policy object** and select **New**
 1. Type *Domain Controller Auto Certificate Enrollment* in the name box and select **OK**
 1. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and select **Edit**
 1. In the navigation pane, expand **Policies** under **Computer Configuration**
 1. Expand **Windows Settings > Security Settings > Public Key Policies**
 1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties**
 1. Select **Enabled** from the **Configuration Model** list
 1. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box
 1. Select the **Update certificates that use certificate templates** check box
 1. Select **OK**
 1. Close the **Group Policy Management Editor**
-The certificate authority may only issue certificates for certificate templates that are published to that certificate authority.  If you have more than one certificate authority and you want that certificate authority to issue certificates based on a specific certificate template, then you must publish the certificate template to all certificate authorities that are expected to issue the certificate.
+### Deploy the domain controller auto certificate enrollment GPO
-Sign in to the certificate authority or management workstations with **Enterprise Admin** equivalent credentials.
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
 1. Open the **Certificate Authority** management console.
 2. Expand the parent node from the navigation pane.
 3. Click **Certificate Templates** in the navigation pane.
 4. Right-click the **Certificate Templates** node.  Click **New**, and click **Certificate Template** to issue.
 5. In the **Enable Certificates Templates** window, select the **Domain Controller Authentication (Kerberos)**, and **Internal Web Server** templates you created in the previous steps.  Click **OK** to publish the selected certificate templates to the certificate authority.
 6. If you published the Domain Controller Authentication (Kerberos) certificate template, then you should unpublish the certificate templates you included in the superseded templates list.
    \* To unpublish a certificate template, right-click the certificate template you want to unpublish in the details pane of the Certificate Authority console and select **Delete**. Click **Yes** to confirm the operation.
 7. Close the console.
 ### Configure Domain Controllers for Automatic Certificate Enrollment
 Domain controllers automatically request a certificate from the domain controller certificate template.  However, the domain controller is unaware of newer certificate templates or superseded configurations on certificate templates.  To continue automatic enrollment and renewal of domain controller certificates that understand newer certificate template and superseded certificate template configurations, create and configure a Group Policy object for automatic certificate enrollment and link the Group Policy object to the Domain Controllers OU.
 1. Start the **Group Policy Management Console** (gpmc.msc)
 1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…**
 1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created
 1. Select **OK**
-2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
+## Validate the configuration
 3. Right-click **Group Policy object** and select **New**
 4. Type *Domain Controller Auto Certificate Enrollment* in the name box and click **OK**.
 5. Right-click the **Domain Controller Auto Certificate Enrollment** Group Policy object and click **Edit**.
 6. In the navigation pane, expand **Policies** under **Computer Configuration**.
 7. Expand **Windows Settings**, **Security Settings**, and click **Public Key Policies**.
 8. In the details pane, right-click **Certificate Services Client – Auto-Enrollment** and select **Properties**.
 9. Select **Enabled** from the **Configuration Model** list.
 10. Select the **Renew expired certificates, update pending certificates, and remove revoked certificates** check box.
 11. Select the **Update certificates that use certificate templates** check box.
 12. Click **OK**. Close the **Group Policy Management Editor**.
 ### Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object
 Sign in to domain controller or management workstations with _Domain Admin_ equivalent credentials.
 1. Start the **Group Policy Management Console** (gpmc.msc).
 2. In the navigation pane, expand the domain and expand the node that has your Active Directory domain name.  Right-click the **Domain Controllers** organizational unit and click **Link an existing GPO…**.
 3. In the **Select GPO** dialog box, select **Domain Controller Auto Certificate Enrollment** or the name of the domain controller certificate enrollment Group Policy object you previously created and click **OK**.
 ### Validating your work
 Windows Hello for Business is a distributed system, which on the surface appears complex and difficult. The key to a successful Windows Hello for Business deployment is to validate phases of work prior to moving to the next phase.
 You want to confirm your domain controllers enroll the correct certificates and not any unnecessary (superseded) certificate templates. You need to check each domain controller that autoenrollment for the computer occurred.
-#### Use the Event Logs
+### Use the event logs
-Windows Server 2012 and later include Certificate Lifecycle events to determine the lifecycles of certificates for both users and computers.  Using the Event Viewer, navigate to the CertificateServices-Lifecycles-System event log under Application and Services/Microsoft/Windows.
+Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
-Look for an event indicating a new certificate enrollment (autoenrollment).  The details of the event include the certificate template on which the certificate was issued.  The name of the certificate template used to issue the certificate should match the certificate template name included in the event.  The certificate thumbprint and EKUs for the certificate are also included in the event.  The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template. 
+1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log
 1. Look for an event indicating a new certificate enrollment (autoenrollment):
   - The details of the event include the certificate template on which the certificate was issued
   - The name of the certificate template used to issue the certificate should match the certificate template name included in the event
   - The certificate thumbprint and EKUs for the certificate are also included in the event
   - The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template
-Certificates superseded by your new domain controller certificate generate an archive event in the CertificateServices-Lifecycles-System event.  The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
+Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
-#### Certificate Manager
+### Certificate Manager
-You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs.  Use **certlm.msc** to view certificate in the local computers certificate stores.  Expand the **Personal** store and view the certificates enrolled for the computer.  Archived certificates do not appear in Certificate Manager.
+You can use the Certificate Manager console to validate the domain controller has the properly enrolled certificate based on the correct certificate template with the proper EKUs. Use **certlm.msc** to view certificate in the local computers certificate stores. Expand the **Personal** store and view the certificates enrolled for the computer. Archived certificates don't appear in Certificate Manager.
-#### Certutil.exe
+### Certutil.exe
-You can use **certutil.exe** to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer.  From an elevated command prompt, run `certutil -q -store my` to view locally enrolled certificates.
+You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates.
-To view detailed information about each certificate in the store, use `certutil -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
+To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
-#### Troubleshooting
+### Troubleshooting
-Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates.  You can refresh Group Policy from an elevated command prompt using `gpupdate /force`.
+Windows triggers automatic certificate enrollment for the computer during boot, and when Group Policy updates. You can refresh Group Policy from an elevated command prompt using `gpupdate.exe /force`.
-Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq -autoenroll -q` from an elevated command prompt.
+Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt.
-Use the event logs to monitor certificate enrollment and archive.  Review the configuration, such as publishing certificate templates to issuing certificate authority and the allow auto enrollment permissions.
+Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions.
-## Follow the Windows Hello for Business on premises key trust deployment guide
+> [!div class="nextstepaction"]
-
+> [Next: prepare and deploy AD FS >](hello-key-trust-adfs.md)
 1. [Validate Active Directory prerequisites](hello-key-trust-validate-ad-prereq.md)
 2. Validate and Configure Public Key Infrastructure (*You are here*)
 3. [Prepare and Deploy Windows Server 2016 Active Directory Federation Services](hello-key-trust-adfs.md)
 4. [Validate and Deploy Multifactor Authentication Services (MFA)](hello-key-trust-validate-deploy-mfa.md)
 5. [Configure Windows Hello for Business Policy settings](hello-key-trust-policy-settings.md)
--- a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
+++ b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
@ -5,7 +5,7 @@ ms.collection:
  - highpri
 ms.date: 2/15/2022
 appliesto: 
- ✅ <a href=https: //learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.topic: article
 ---
--- a/windows/security/identity-protection/hello-for-business/hello-overview.md
+++ b/windows/security/identity-protection/hello-for-business/hello-overview.md
@ -5,7 +5,7 @@ ms.collection:
  - highpri
 ms.topic: conceptual
 appliesto: 
- ✅ <a href=https: //learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+  - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.date: 12/31/2017
 ---
 # Windows Hello for Business Overview
--- a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
+++ b/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
@ -5,7 +5,7 @@ ms.collection:
  - highpri
 ms.date: 10/23/2017
 appliesto: 
- ✅ <a href=https: //learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
 ms.topic: article
 ---
 # Why a PIN is better than an online password
--- a/windows/security/identity-protection/hello-for-business/images/adfs-device-registration.png
+++ b/windows/security/identity-protection/hello-for-business/images/adfs-device-registration.png
--- a/windows/security/identity-protection/hello-for-business/images/adfs-scp.png
+++ b/windows/security/identity-protection/hello-for-business/images/adfs-scp.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-adfs-configure-2012r2.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-adfs-configure-2012r2.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-internal-web-server-cert.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-add-ip.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-add-ip.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-ip-config.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-ip-config.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-port-rule.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster-port-rule.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-cluster.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-connect.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-connect.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-feature-install.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-feature-install.png
--- a/windows/security/identity-protection/hello-for-business/images/hello-nlb-manager.png
+++ b/windows/security/identity-protection/hello-for-business/images/hello-nlb-manager.png
--- a/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
+++ b/windows/security/identity-protection/hello-for-business/retired/hello-how-it-works.md
@ -3,8 +3,7 @@ title: How Windows Hello for Business works (Windows)
 description: Learn about registration, authentication, key material, and infrastructure for Windows Hello for Business.
 ms.date: 10/16/2017
 appliesto: 
-  - ✅ <b>Windows 10</b>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
  - ✅ <b>Windows 11</b>
 ms.topic: article
 ---
 # How Windows Hello for Business works in Windows devices
--- a/windows/security/identity-protection/hello-for-business/toc.yml
+++ b/windows/security/identity-protection/hello-for-business/toc.yml
@ -99,7 +99,7 @@
        href: hello-deployment-key-trust.md
      - name: Validate Active Directory prerequisites
        href: hello-key-trust-validate-ad-prereq.md
-      - name: Validate and configure Public Key Infrastructure (PKI)
+      - name: Configure and validate Public Key Infrastructure (PKI)
        href: hello-key-trust-validate-pki.md
      - name: Prepare and deploy Active Directory Federation Services (AD FS)
        href: hello-key-trust-adfs.md
@ -113,7 +113,7 @@
        href: hello-deployment-cert-trust.md
      - name: Validate Active Directory prerequisites
        href: hello-cert-trust-validate-ad-prereq.md
-      - name: Validate and configure Public Key Infrastructure (PKI)
+      - name: Configure and validate Public Key Infrastructure (PKI)
        href: hello-cert-trust-validate-pki.md
      - name: Prepare and Deploy Active Directory Federation Services (AD FS)
        href: hello-cert-trust-adfs.md
--- a/windows/security/identity-protection/user-account-control/how-user-account-control-works.md
+++ b/windows/security/identity-protection/user-account-control/how-user-account-control-works.md
@ -8,7 +8,7 @@ ms.localizationpriority: medium
 ms.date: 09/23/2021
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # How User Account Control works
--- a/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings.md
+++ b/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings.md
@ -7,7 +7,7 @@ ms.topic: article
 ms.date: 04/19/2017
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # User Account Control Group Policy and registry key settings
--- a/windows/security/identity-protection/user-account-control/user-account-control-overview.md
+++ b/windows/security/identity-protection/user-account-control/user-account-control-overview.md
@ -7,7 +7,7 @@ ms.topic: article
 ms.date: 09/24/2011
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # User Account Control
--- a/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings.md
+++ b/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings.md
@ -5,7 +5,7 @@ ms.topic: article
 ms.date: 09/24/2021
 appliesto: 
 - ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
+- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
 ---
 # User Account Control security policy settings
--- a/windows/security/images/icons/information.svg
+++ b/windows/security/images/icons/information.svg
@ -0,0 +1,3 @@
 <svg width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M8 7C8.27614 7 8.5 7.22386 8.5 7.5V10.5C8.5 10.7761 8.27614 11 8 11C7.72386 11 7.5 10.7761 7.5 10.5V7.5C7.5 7.22386 7.72386 7 8 7ZM8.00001 6.24907C8.41369 6.24907 8.74905 5.91371 8.74905 5.50003C8.74905 5.08635 8.41369 4.751 8.00001 4.751C7.58633 4.751 7.25098 5.08635 7.25098 5.50003C7.25098 5.91371 7.58633 6.24907 8.00001 6.24907ZM2 8C2 4.68629 4.68629 2 8 2C11.3137 2 14 4.68629 14 8C14 11.3137 11.3137 14 8 14C4.68629 14 2 11.3137 2 8ZM8 3C5.23858 3 3 5.23858 3 8C3 10.7614 5.23858 13 8 13C10.7614 13 13 10.7614 13 8C13 5.23858 10.7614 3 8 3Z" fill="#0078D4" />
 </svg>
--- a/windows/security/includes/hello-cloud.md
+++ b/windows/security/includes/hello-cloud.md
@ -1,7 +1,11 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [cloud](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-deployment)\
+author: paolomatarazzo
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join)
+ms.author: paoloma
-
+ms.date: 12/08/2022
-<br>
+ms.topic: include
-
+---
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-cloud](hello-deployment-cloud.md)]
 - **Join type:** [!INCLUDE [hello-join-aad](hello-join-aad.md)]
 ---
--- a/windows/security/includes/hello-deployment-cloud.md
+++ b/windows/security/includes/hello-deployment-cloud.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [cloud :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-deployment "For organizations using Azure AD-only identities. Device management is usually done via Intune/MDM")
--- a/windows/security/includes/hello-deployment-hybrid.md
+++ b/windows/security/includes/hello-deployment-hybrid.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [hybrid :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Azure AD. Device management is usually done via Group Policy or Intune/MDM")
--- a/windows/security/includes/hello-deployment-onpremises.md
+++ b/windows/security/includes/hello-deployment-onpremises.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [on-premises :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Azure AD. Device management is usually done via Group Policy")
--- a/windows/security/includes/hello-hybrid-cert-trust-aad.md
+++ b/windows/security/includes/hello-hybrid-cert-trust-aad.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
+ms.author: paoloma
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join)
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
 - **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)]
 ---
--- a/windows/security/includes/hello-hybrid-cert-trust-ad.md
+++ b/windows/security/includes/hello-hybrid-cert-trust-ad.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
+ms.author: paoloma
-✅ **Device registration type:** [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-cloud-kerberos](hello-trust-cloud-kerberos.md)]
 - **Join type:** [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
 ---
--- a/windows/security/includes/hello-hybrid-cert-trust.md
+++ b/windows/security/includes/hello-hybrid-cert-trust.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
+ms.author: paoloma
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
 - **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
 ---
--- a/windows/security/includes/hello-hybrid-cloudkerb-trust.md
+++ b/windows/security/includes/hello-hybrid-cloudkerb-trust.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [cloud Kerberos trust](../identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust.md)\
+ms.author: paoloma
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-cloud-kerberos](hello-trust-cloud-kerberos.md)]
 - **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
 ---
--- a/windows/security/includes/hello-hybrid-key-trust-ad.md
+++ b/windows/security/includes/hello-hybrid-key-trust-ad.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust)\
+ms.author: paoloma
-✅ **Device registration type:** [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)]
 - **Join type:** [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
 ---
--- a/windows/security/includes/hello-hybrid-key-trust.md
+++ b/windows/security/includes/hello-hybrid-key-trust.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust)\
+ms.author: paoloma
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join), [Hybrid Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join)
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)]
 - **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)], [!INCLUDE [hello-join-hybrid](hello-join-hybrid.md)]
 ---
--- a/windows/security/includes/hello-hybrid-keycert-trust-aad.md
+++ b/windows/security/includes/hello-hybrid-keycert-trust-aad.md
@ -1,7 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [hybrid](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust), [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
+ms.author: paoloma
-✅ **Device registration type:** [Azure AD join](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join)
+ms.date: 12/08/2022
-<br>
+ms.topic: include
-
+---
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-hybrid](hello-deployment-hybrid.md)]
 - **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)], [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
 - **Join type:** [!INCLUDE [hello-join-aadj](hello-join-aad.md)]
 ---
--- a/windows/security/includes/hello-intro.md
+++ b/windows/security/includes/hello-intro.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 This document describes Windows Hello for Business functionalities or scenarios that apply to:
--- a/windows/security/includes/hello-join-aad.md
+++ b/windows/security/includes/hello-join-aad.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Azure AD joined do not have any dependencies on Active Directory. Only local users accounts and Azure AD users can sign in to these devices")
--- a/windows/security/includes/hello-join-domain.md
+++ b/windows/security/includes/hello-join-domain.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [domain join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md "Devices that are domain joined do not have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices")
--- a/windows/security/includes/hello-join-hybrid.md
+++ b/windows/security/includes/hello-join-hybrid.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [hybrid Azure AD join :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are hybrid Azure AD joined don't have any dependencies on Azure AD. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Azure AD will have single-sign on to both Active Directory and Azure AD-protected resources")
--- a/windows/security/includes/hello-on-premises-cert-trust.md
+++ b/windows/security/includes/hello-on-premises-cert-trust.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [on-premises](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [certificate trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust)\
+ms.author: paoloma
-✅ **Device registration type:** Active Directory domain join
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-onpremises](hello-deployment-onpremises.md)]
 - **Trust type:** [!INCLUDE [hello-trust-certificate](hello-trust-certificate.md)]
 - **Join type:** [!INCLUDE [hello-join-domain](hello-join-domain.md)]
 ---
--- a/windows/security/includes/hello-on-premises-key-trust.md
+++ b/windows/security/includes/hello-on-premises-key-trust.md
@ -1,8 +1,12 @@
-This document describes Windows Hello for Business functionalities or scenarios that apply to:\
+---
-✅ **Deployment type:** [on-premises](../identity-protection/hello-for-business/hello-how-it-works-technology.md#on-premises-deployment)\
+author: paolomatarazzo
-✅ **Trust type:** [key trust](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust)\
+ms.author: paoloma
-✅ **Device registration type:** Active Directory domain join
+ms.date: 12/08/2022
-
+ms.topic: include
-<br>
+---
-
+
 [!INCLUDE [hello-intro](hello-intro.md)]
 - **Deployment type:** [!INCLUDE [hello-deployment-onpremises](hello-deployment-onpremises.md)]
 - **Trust type:** [!INCLUDE [hello-trust-key](hello-trust-key.md)]
 - **Join type:** [!INCLUDE [hello-join-domain](hello-join-domain.md)]
 ---
--- a/windows/security/includes/hello-trust-certificate.md
+++ b/windows/security/includes/hello-trust-certificate.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [certificate trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
--- a/windows/security/includes/hello-trust-cloud-kerberos.md
+++ b/windows/security/includes/hello-trust-cloud-kerberos.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [cloud Kerberos trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that do not need certificate authentication")
--- a/windows/security/includes/hello-trust-key.md
+++ b/windows/security/includes/hello-trust-key.md
@ -0,0 +1,8 @@
 ---
 author: paolomatarazzo
 ms.author: paoloma
 ms.date: 12/08/2022
 ms.topic: include
 ---
 [key trust :::image type="icon" source="../images/icons/information.svg" border="false":::](../identity-protection/hello-for-business/hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
--- a/windows/security/includes/improve-request-performance.md
+++ b/windows/security/includes/improve-request-performance.md
@ -1,14 +1,8 @@
 ---
 title: Improve request performance
 description: Improve request performance
 search.product: eADQiWindows 10XVcnh
 ms.prod: m365-security
 ms.localizationpriority: medium
 ms.collection: M365-security-compliance 
 ms.topic: article
 author: paolomatarazzo
 ms.author: paoloma
-manager: aaroncz
+ms.date: 12/08/2022
 ms.topic: include
 ---
 >[!TIP]
--- a/windows/security/includes/machineactionsnote.md
+++ b/windows/security/includes/machineactionsnote.md
@ -1,12 +1,8 @@
 ---
 title: Perform a Machine Action via the Microsoft Defender for Endpoint API
 description: This page focuses on performing a machine action via the Microsoft Defender for Endpoint API.
 ms.date: 08/28/2017
 ms.reviewer: 
 author: paolomatarazzo
 ms.author: paoloma
-manager: aaroncz
+ms.date: 12/08/2022
-ms.prod: m365-security
+ms.topic: include
 ---
 >[!Note]
--- a/windows/security/includes/microsoft-defender-api-usgov.md
+++ b/windows/security/includes/microsoft-defender-api-usgov.md
@ -1,14 +1,8 @@
 ---
 title: Microsoft Defender for Endpoint API URIs for US Government
 description: Microsoft Defender for Endpoint API URIs for US Government
 search.product: eADQiWindows 10XVcnh
 ms.prod: m365-security
 author: paolomatarazzo
 ms.author: paoloma
-manager: aaroncz
+ms.date: 12/08/2022
-ms.localizationpriority: medium
+ms.topic: include
 ms.collection: M365-security-compliance 
 ms.topic: article
 ---
 >[!NOTE]
--- a/windows/security/includes/microsoft-defender.md
+++ b/windows/security/includes/microsoft-defender.md
@ -1,13 +1,7 @@
 ---
 title: Microsoft 365 Defender important guidance
 description: A note in regard to important Microsoft 365 Defender guidance.
 ms.date: 
 ms.reviewer: 
 manager: aaroncz
 author: paolomatarazzo
 ms.author: paoloma
-manager: aaroncz
+ms.date: 12/08/2022
 ms.prod: m365-security
 ms.topic: include
 ---
--- a/windows/security/includes/prerelease.md
+++ b/windows/security/includes/prerelease.md
@ -1,12 +1,8 @@
 ---
 title: Microsoft Defender for Endpoint Pre-release Disclaimer
 description: Disclaimer for pre-release version of Microsoft Defender for Endpoint.
 ms.date: 08/28/2017
 ms.reviewer: 
 author: paolomatarazzo
 ms.author: paoloma
-manager: aaroncz
+ms.date: 12/08/2022
-ms.prod: m365-security
+ms.topic: include
 ---
 > [!IMPORTANT]