diff --git a/windows/access-protection/hello-for-business/hello-adequate-domain-controllers.md b/windows/access-protection/hello-for-business/hello-adequate-domain-controllers.md
new file mode 100644
index 0000000000..040fb7e850
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-adequate-domain-controllers.md
@@ -0,0 +1,100 @@
+---
+title: Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments
+description: Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 10/09/2017
+---
+# Planning an adequate number of Windows Server 2016 Domain Controllers for Windows Hello for Business deployments
+
+**Applies to**
+-   Windows 10
+
+
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+## One size does not fit all
+
+How can you find out how many domain controllers are needed? You can use performance monitoring on your domain controllers to determine existing authentication traffic.  Windows Server 2016 includes the KDC AS Requests performance counter.  You can use these counters to determine how much of a domain controllers load is due to initial Kerberos authentication.  It’s important to remember that authentication for a Windows Hello for Business key trust deployment does not affect Kerberos authentication—it remains unchanged.
+
+Windows 10 accomplishes Windows Hello for Business key trust authentication by mapping an Active Directory user account to one or more public keys.  This mapping occurs on the domain controller, which is why the deployment needs Windows Server 2016 domain controllers. Public key mapping is only supported by Windows Server 2016 domain controllers.  Therefore, user in a key trust deployment user must authenticate to a Windows Server 2016 domain controller.
+  
+Determining an adequate number of Windows Server 2016 domain controllers is important to ensure you have enough domain controllers to satisfy all authentication requests, including users mapped with  public key trust.  What many administrators do not realize is that adding the most current version of a domain controller (in this case Windows Server 2016) to a deployment of existing domain controllers (Windows Server 2008R2 or Windows Server 2012R2) instantly makes that single domain controller susceptible to carrying the most load, or what is commonly referred to as “piling on”.   To illustrate the “piling on” concept, consider the following scenario.
+ 
+Consider a controlled environment where there are 1000 client computers and the authentication load of these 1000 client computers is evenly distributed across 10 domain controllers in the environment.  The Kerberos AS requests load would look something like the following.
+
+![dc-chart1](images/dc-chart1.png)
+
+The environment changes.  The first change includes DC1 upgraded to Windows Server 2016 to support Windows Hello for Business key-trust authentication. Next, 100 clients enroll for Windows Hello for Business using the public key trust deployment.   Given all other factors stay constant, the authentication would now look like the following.
+
+![dc-chart2](images/dc-chart2.png)
+
+The Windows Server 2016 domain controller is handling 100 percent of all public key trust authentication.  However, it is also handling 10 percent of the password authentication. Why?  This behavior occurs because domain controllers 2- 10 only support password and certificate trust authentication; only a Windows Server 2016 domain controller supports authentication public key trust authentication.  The Windows Server 2016 domain controller understands how to authenticate password and certificate trust authentication and will continue to share the load of authenticating those clients.  Because DC1 can handle all forms of authentication, it will be bear more of the authentication load, and easily become overloaded.  What if another Windows Server 2016 domain controller is added, but without deploying Windows Hello for Business to anymore clients.
+
+![dc-chart3](images/dc-chart3.png)
+
+Upgrading another Windows Server 2016 domain controller distributes the public key trust authentication across two domain controllers—each supporting 50 percent of the load.  But it doesn’t change the distribution of password and certificate trust authentication.  Both Windows Server 2016 domain controllers still share 10 percent of this load. Now look at the scenario when half of the domain controllers are upgraded to Windows Server 2016, but the number of WHFB clients remains the same.
+
+![dc-chart4](images/dc-chart4.png)
+
+Domain controllers 1 through 5 now share the public key trust authentication load where each domain controller handles 20 percent of the public key trust load but they each still handle 10 percent of the password and certificate trust authentication.  These domain controllers still have a heavier load than domain controllers 6 through 10; however, the load is adequately distributed.  Now look the scenario when half of the client computers are upgraded to Windows Hello for Business using a key-trust deployment.
+
+![dc-chart5](images/dc-chart5.png)
+
+You’ll notice the distribution did not change.  Each Windows Server 2016 domain controller handles 20 percent of the public key trust authentication.  However, increasing the volume of authentication (by increasing the number of clients) increases the amount of work that is represented by the same 20 percent.  In the previous example, 20 percent of public key trust authentication equated to a volume of 20 authentications per domain controller capable of public key trust authentication.  However, with upgraded clients, that same 20 percent represents a volume 100 public key trust authentications per public key trust capable domain controller.  Also, the distribution of non-public key trust authentication remained at 10 percent, but the volume of password and certificate trust authentication decreased across the older domain controllers.
+
+There are several conclusions here: 
+* Upgrading domain controllers changes the distribution of new authentication, but doesn’t change the distribution of older authentication.
+* Upgrading domain controllers does not affect the distribution of password and certificate trust authentication because newer domain controllers can support password and certificate trust authentication.
+* Upgraded domain controllers typically carry a heavier authentication load than down-level domain controllers because they support more forms of authentication.  
+* Upgrading clients to Windows Hello for Business, increases the volume of public key trust authentication distributed across domain controllers which support it and, reduces the volume of password and certificate trust authentication across all domain controllers
+* Upgrading clients to Windows Hello for Business but does not affect the distribution of authentication; only the volume of authentication. 
+
+The preceding was an example to show why it’s unrealistic to have a “one-size-fits-all” number to describe what “an adequate amount” means.  In the real world, authentication is not evenly distributed across domain controllers.
+
+## Determining total AS Request load
+
+Each organization needs to have an baseline of the AS request load that occurs in their environment. Windows Server provides the KDC AS Requests performance counter that helps you determine this.
+  
+Pick a site where you plan to upgrade the clients to Windows Hello for Business public key trust.  Pick a time when authentication traffic is most significant—Monday morning is great time as everyone is returning to the office.  Enable the performance counter on *all* the domain controllers in that site.  Collect KDC AS Requests performance counters for two hours:
+* A half-hour before you expect initial authentication (sign-ins and unlocks) to be significant
+* The hour you believe initial authentication to be significant
+* And a half-hour after you expect initial authentication to be significant
+
+For example, if employees are scheduled to come into the office at 9:00am.  Your performance capture should begin at 8:30am and end at 10:30am. Ensure your performance logs do not wrap the data.  You want to see authentication trend upward, peak, and trend downward.
+
+> [!NOTE]
+> To capture all the authentication traffic.  Ensure that all computers are powered down to get the most accurate authentication information (computers and services authenticate at first power up—you need to consider this authentication in your evaluation).
+
+Aggregate the performance data of all domain controllers. Look for the maximum KDC AS Requests for each domain controller.  Find the median time when the maximum number of requests occurred for the site, this should represent when the site is experience the highest amount of authentication.
+ 
+Add the number of authentications for each domain controller for the median time.  You now have the total authentication for the site during a peak time.  Using this metric, you can determine the distribution of authentication across the domain controllers in the site by dividing the domain controller’s authentication number for the median time by the total authentication.  Multiple the quotient by 10 to convert the distribution to a percentage.  To validate your math, all the distributions should equal 100 percent.
+
+Review the distribution of authentication.  Hopefully, none of these are above 70 percent.  It’s always good to reserve some capacity for the unexpected.  Also, the primary purposes of a domain controller is to provide authentication and handle Active Directory operations. Identify domain controllers with lower distributions of authentication as potential candidates for the initial domain controller upgrades in conjunction with a reasonable distribution of clients provisioned for Windows Hello for Business.
+  
+## Monitoring Authentication
+Using the same methods previously described above, monitor the Kerberos authentication after upgrading a domain controller and your first phase of Windows Hello for Business deployments.  Make note of the delta of authentication before and after upgrading the domain controller to Windows Server 2016.  This delta is representative of authentication resulting from the first phase of your Windows Hello for Busines clients.  This gives you a baseline for your environment to where you can form a statement such as 
+
+```“Every n Windows Hello for Business clients results in x percentage of key-trust authentication.”```
+
+Where _n_ equals the number of clients you switched to Windows Hello for Business and _x_ equals the increased percentage of authentication from the upgraded domain controller.  Armed with information, you can apply the observations of upgrading domain controllers and increasing Windows Hello for Business client count to appropriately phase your deployment.
+  
+Remember, increasing the number of clients changes the volume of authentication distributed across the Windows Server 2016 domain controllers. If there is only one Windows Server 2016 domain controller, there’s no distribution and you are simply increasing the volume of authentication for which THAT domain controller is responsible.
+
+Increasing the number of number of domain controllers distributes the volume of authentication, but doesn’t change it.  Therefore, as you add more domain controllers, the burden of authentication for which each domain controller is responsible decrease. Upgrading two domain controller changes the distribution to 50 percent. Upgrading three domain controllers changes the distribution to 33 percent, and so on.
+
+## Strategy
+The simplest strategy you can employ is to upgrade one domain controller and monitor the single domain controller as you continue to phase in new Windows Hello for Business key-trust clients until it reaches a 70 or 80 percent threshold.
+  
+Then, upgrade a second domain controller.  Monitor the authentication on both domain controllers to determine how the authentication distributes between the two domain controllers. Introduce more Windows Hello for Business clients while monitoring the authentication on the two upgraded domain controllers.  Once those reach your environments designated capacity, then upgrade another domain controller.
+  
+Repeat until your deployment for that site is complete.  Now, monitor authentication across all your domain controllers like you did the very first time.  Determine the distribution of authentication for each domain controller.  Identify the percentage of distribution for which it is responsible.  If a single domain controller is responsible for 70 percent of more of the authentication, you may want to consider adding a domain controller to reduce the distribution of authentication volume.
+  
+However, before considering this, ensure the high load of authentication is not a result of applications and services where their configuration has a statically configured domain controller. Adding domain controllers will not resolve the additional authentication load problem in this scenario.  Instead, manually distribute the authentication to different domain controllers among all the services or applications.  Alternatively, try simply using the domain name rather than a specific domain controller.  Each domain controller has an A record registered in DNS for the domain name, which DNS will round robin with each DNS query. It’s not the best load balancer, however, it’s a better alternative to static domain controller configurations, provided the configuration is compatible with your service or application.
+
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-new-install.md b/windows/access-protection/hello-for-business/hello-hybrid-key-new-install.md
new file mode 100644
index 0000000000..304f4fe766
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-new-install.md
@@ -0,0 +1,144 @@
+---
+title: Windows Hello for Business Key Trust New Installation (Windows Hello for Business)
+description: Windows Hello for Business Hybrid baseline deployment
+keywords: identity, PIN, biometric, Hello, passport, WHFB
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 10/09/2017
+---
+# Windows Hello for Business Key Trust New Installation
+
+**Applies to**
+-   Windows 10
+
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+Windows Hello for Business involves configuring distributed technologies that may or may not exist in your current infrastructure.  Hybrid key trust deployments of Windows Hello for Business rely on these technolgies
+
+* [Active Directory](#active-directory)
+* [Public Key Infrastructure](#public-key-infrastructure)
+* [Azure Active Directory](#azure-active-directory)
+* [Directory Synchronization](#directory-synchronization)
+* [Active Directory Federation Services](#active-directory-federation-services)
+
+
+New installations are considerably more involved than existing implementations because you are building the entire infrastructure.  Microsoft recommends you review the new installation baseline to validate your exsting envrionment has all the needed configurations to support your hybrid certificate trust Windows Hello for Business deployment.  If your environment meets these needs, you can read the [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md) section to prepare your Windows Hello for Business deployment by configuring Azure device registration.
+
+The new installation baseline begins with a basic Active Directory deployment and enterprise PKI.  This document expects you have Active Directory deployed with an adeqate number of Windows Server 2016 domain controllers for each site.
+
+## Active Directory ##   
+Production environments should follow Active Directory best practices regarding the number and placement of domain controllers to ensure adequate authentication throughout the organization.
+  
+Lab environments and isolated proof of concepts may want to limit the number of domain controllers.  The purpose of these environments is to experiment and learn.  Reducing the number of domain controllers can prevent troubleshooting issue, such as Active Directory replication, which is unrelated to activity's goal.
+
+### Section Review
+
+> [!div class="checklist"]
+> * An adequate number of Windows Server 2016 R2 domain controllers
+> * Minimum Windows Server 2008 R2 domain and forest functional level
+> * Functional networking, name resolution, and Active Directory replication
+ 
+## Public Key Infrastructure
+
+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.
+
+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.
+
+### Lab-based public key infrastructure
+
+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.
+
+>[!NOTE]
+>Never install a certificate 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.   
+    ```PowerShell
+    Add-WindowsFeature Adcs-Cert-Authority -IncludeManageTools
+    ```
+
+3. Use the following command to configure the Certificate Authority using a basic certificate authority configuration.   
+    ```PowerShell
+    Install-AdcsCertificateAuthority
+    ```   
+    
+## Configure a Production Public Key Infrastructure
+
+If you do have an existing public key infrastructure, please review [Certification Authority Guidance](https://technet.microsoft.com/library/hh831574.aspx) from Microsoft TechNet to properly design your infrastructure.   Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](https://technet.microsoft.com/library/hh831348.aspx) for instructions on how to configure your public key infrastructure using the information from your design session.
+
+### Section Review ###
+
+> [!div class="checklist"]
+> *  Miniumum Windows Server 2012 Certificate Authority.
+> *  Enterprise Certificate Authority.
+> *  Functioning public key infrastructure.
+  
+## Azure Active Directory ##
+You’ve prepared your Active Directory.  Hybrid Windows Hello for Business deployment needs Azure Active Directory to host your cloud-based identities. 
+
+The next step of the deployment is to follow the [Creating an Azure AD tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-howto-tenant) process to provision an Azure tenant for your organization.
+
+### Section Review
+
+> [!div class="checklist"]
+> * Review the different ways to establish an Azure Active Directory tenant.
+> * Create an Azure Active Directory Tenant.
+> * Purchase the appropriate Azure Active Directory subscription or licenses, if necessary.
+   
+## Multifactor Authentication Services ##
+Windows Hello for Business uses multifactor authentication during provisioning and during user initiated PIN reset scenarios, such as when a user forgets their PIN.  There are two preferred multifactor authentication configurations with hybrid deployments—Azure MFA and AD FS using Azure MFA
+
+Review the [What is Azure Multi-Factor Authentication](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication) topic to familiarize yourself its purpose and how it works.
+
+### Azure Multi-Factor Authentication (MFA) Cloud ###
+> [!IMPORTANT]
+As long as your users have licenses that include Azure Multi-Factor Authentication, there's nothing that you need to do to turn on Azure MFA. You can start requiring two-step verification on an individual user basis. The licenses that enable Azure MFA are:
+> * Azure Multi-Factor Authentication
+> * Azure Active Directory Premium
+> * Enterprise Mobility + Security
+>
+> If you have one of these subscriptions or licenses, skip the Azure MFA Adapter section. 
+
+#### Azure MFA Provider #### 
+If your organization uses Azure MFA on a per-consumption model (no licenses), then review the [Create a Multifactor Authentication Provider](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-auth-provider) section to create an Azure MFA Authentication provider and associate it with your Azure tenant. 
+
+#### Configure Azure MFA Settings ####
+Once you have created your Azure MFA authentication provider and associated it with an Azure tenant, you need to configure the multi-factor authentication settings.  Review the [Configure Azure Multi-Factor Authentication settings](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-whats-next) section to configure your settings.
+
+#### Azure MFA User States ####
+After you have completed configuring your Azure MFA settings, you want to review configure [User States](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-user-states) to understand user states.  User states determine how you enable Azure MFA for your users.
+
+### Azure MFA via ADFS ###
+Alternatively, you can configure Windows Server 2016 Active Directory Federation Services (AD FS) to provide additional multi-factor authentication. To configure, read the [Configure AD FS 2016 and Azure MFA](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa) section.
+
+### Section Review
+
+> [!div class="checklist"]
+> * Review the overview and uses of Azure Multifactor Authentication.
+> * Review your Azure Active Directory subscription for Azure Multifactor Authentication.
+> * Create an Azure Multifactor Authentication Provider, if necessary.
+> * Configure Azure Multufactor Authentiation features and settings.
+> * Understand the different User States and their effect on Azure Multifactor Authentication.
+> * Consider using Azure Multifactor Authentication or a third-party multifactor authentication provider with Windows Server Active Directory Federation Services, if necessary.
+
+> [!div class="nextstepaction"]
+> [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid key trust deployment guide
+1. [Overview](hello-hybrid-key-trust.md)
+2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
+3. New Installation Baseline (*You are here*)
+4. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
+5. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
+6. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-trust-devreg.md b/windows/access-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
new file mode 100644
index 0000000000..51dc7b8538
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-trust-devreg.md
@@ -0,0 +1,482 @@
+---
+title: Configure Device Registration for Hybrid Windows Hello for Business
+description: Azure Device Registration for Hybrid Certificate Key Deployment (Windows Hello for Business)
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust, device, registration
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 10/09/2017
+---
+# Configure Device Registration for Hybrid Windows Hello for Business
+
+**Applies to**
+-  Windows 10
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+ 
+You're environment is federated and you are ready to configure device registration for your hybrid environment. Hybrid Windows Hello for Business deployment needs device registration to enable proper device authentication.  
+  
+> [!IMPORTANT]
+> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment. 
+
+Use this three phased approach for configuring device registration.
+1. [Configure devices to register in Azure](#configure-azure-for-device-registration)
+2. [Synchronize devices to on-premises Active Directory](#configure-active-directory-to-support-azure-device-syncrhonization)
+3. [Configure AD FS to use cloud devices](#configure-ad-fs-to-use-azure-registered-devices)
+
+> [!NOTE]
+> Before proceeding, you should familiarize yourself with device regisration concepts such as:
+> * Azure AD registered devices
+> * Azure AD joined devices
+> * Hybrid Azure AD joined devices
+>
+> You can learn about this and more by reading [Introduction to Device Management in Azure Active Directory.](https://docs.microsoft.com/en-us/azure/active-directory/device-management-introduction)
+
+## Configure Azure for Device Registration
+Begin configuring device registration to support Hybrid Windows Hello for Business by configuring device registration capabilities in Azure AD. 
+
+To do this, follow the **Configure device settings** steps under [Setting up Azure AD Join in your organization](https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-setup/)  
+
+## Configure Active Directory to support Azure device syncrhonization
+
+Azure Active Directory is now configured for device registration. Next, you need to configure the on-premises Active Directory to support synchronizing hybrid Azure AD joined devices. Begin with upgrading the Active Directory Schema 
+
+### Setup Active Directory Federation Services
+If you are new to AD FS and federation services, you should review [Understanding Key AD FS Concepts](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) to prior to designing and deploying your federation service.
+Review the [AD FS Design guide](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2) to plan your federation service.
+
+Once you have your AD FS design ready, review [Deploying a Federation Server farm](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) to configure AD FS in your environment.
+> [!IMPORTANT]
+> During your AD FS deployment, skip the **Configure a federation server with Device Registration Service** and the **Configure Corporate DNS for the Federation Service and DRS** procedures.      
+
+
+#### ADFS Web Proxy ###
+Federation server proxies are computers that run AD FS software that have been configured manually to act in the proxy role. You can use federation server proxies in your organization to provide intermediary services between an Internet client and a federation server that is behind a firewall on your corporate network.
+Use the [Setting of a Federation Proxy](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/checklist--setting-up-a-federation-server-proxy) checklist to configure AD FS proxy servers in your environment.
+
+### Deploy Azure AD Connect
+Next, you need to synchronizes the on-premises Active Directory with Azure Active Directory.  To do this, first review the [Integrating on-prem directories with Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect) and [hardware and prerequisites](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites) needed and then [download the software](http://go.microsoft.com/fwlink/?LinkId=615771).
+
+When you are ready to install, follow the **Configuring federation with AD FS** section of [Custom installation of Azure AD Connect](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-started-custom).  Select the **Federation with AD FS** option on the **User sign-in** page.  At the **AD FS Farm** page, select the use an existing option and click **Next**.  
+
+### Create AD objects for AD FS Device Authentication  
+If your AD FS farm is not already configured for Device Authentication (you can see this in the AD FS Management console under Service -> Device Registration), use the following steps to create the correct AD DS objects and configuration.  
+
+![Device Registration](images/hybridct/device1.png)
+
+> [!NOTE]
+> The below commands require Active Directory administration tools, so if your federation server is not also a domain controller, first install the tools using step 1 below.  Otherwise you can skip step 1.  
+
+1.  Run the **Add Roles & Features** wizard and select feature **Remote Server Administration Tools** -> **Role Administration Tools** -> **AD DS and AD LDS Tools** -> Choose both the **Active Directory module for Windows PowerShell** and the **AD DS Tools**.
+
+![Device Registration](images/hybridct/device2.png)
+  
+2.  On your AD FS primary server, ensure you are logged in as AD DS user with Enterprise Admin (EA ) privileges and open an elevated Windows PowerShell prompt.  Then, run the following commands:  
+    
+    `Import-module activedirectory`  
+	`PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>" ` 
+3.  On the pop-up window click **Yes**.
+
+> [!NOTE]
+> If your AD FS service is configured to use a GMSA account, enter the account name in the format "domain\accountname$"
+
+![Device Registration](images/hybridct/device3.png)  
+
+The above PSH creates the following objects:  
+
+
+- RegisteredDevices container under the AD domain partition  
+- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration  
+- Device Registration Service DKM container and object under Configuration --> Services --> Device Registration Configuration  
+
+![Device Registration](images/hybridct/device4.png)  
+
+4.  Once this is done, you will see a successful completion message.
+
+![Device Registration](images/hybridct/device5.png) 
+
+### Create Service Connection Point (SCP) in Active Directory  
+If you plan to use Windows 10 domain join (with automatic registration to Azure AD) as described here, execute the following commands to create a service connection point in AD DS  
+1.  Open Windows PowerShell and execute the following:
+    
+	`PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1" ` 
+
+> [!NOTE]
+> If necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server.  This file is located in Program Files\Microsoft Azure Active Directory Connect\AdPrep
+
+![Device Registration](images/hybridct/device6.png)   
+
+2. Provide your Azure AD global administrator credentials  
+
+	`PS C:>$aadAdminCred = Get-Credential`
+
+![Device Registration](images/hybridct/device7.png) 
+
+3.  Run the following PowerShell command 
+
+    `PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred ` 
+
+Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory.
+  
+The above commands enable Windows 10 clients to find the correct Azure AD domain to join by creating the serviceConnectionpoint object in AD DS.  
+
+### Prepare AD for Device Write Back   
+To ensure AD DS objects and containers are in the correct state for write back of devices from Azure AD, do the following.
+
+1.  Open Windows PowerShell and execute the following:  
+
+    `PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD connector account name] ` 
+
+Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory in domain\accountname format  
+
+The above command creates the following objects for device write back to AD DS, if they do not exist already, and allows access to the specified AD connector account name  
+
+- RegisteredDevices container in the AD domain partition  
+- Device Registration Service container and object under Configuration --> Services --> Device Registration Configuration  
+
+### Enable Device Write Back in Azure AD Connect  
+If you have not done so before, enable device write back in Azure AD Connect by running the wizard a second time and selecting **"Customize Synchronization Options"**, then checking the box for device write back and selecting the forest in which you have run the above cmdlets  
+
+## Configure AD FS to use Azure registered devices
+
+### Configure issuance of claims
+
+In a federated Azure AD configuration, devices rely on Active Directory Federation Services (AD FS) or a 3rd party on-premises federation service to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).
+
+Windows current devices authenticate using Integrated Windows Authentication to an active WS-Trust endpoint (either 1.3 or 2005 versions) hosted by the on-premises federation service.
+
+> [!NOTE]
+> When using AD FS, either **adfs/services/trust/13/windowstransport** or **adfs/services/trust/2005/windowstransport** must be enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. You can see what end-points are enabled through the AD FS management console under **Service > Endpoints**.
+>
+> If you don't have AD FS as your on-premises federation service, follow the instructions of your vendor to make sure they support WS-Trust 1.3 or 2005 end-points and that these are published through the Metadata Exchange file (MEX).
+
+The following claims must exist in the token received by Azure DRS for device registration to complete. Azure DRS will create a device object in Azure AD with some of this information which is then used by Azure AD Connect to associate the newly created device object with the computer account on-premises.
+
+* `http://schemas.microsoft.com/ws/2012/01/accounttype`
+* `http://schemas.microsoft.com/identity/claims/onpremobjectguid`
+* `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`
+
+If you have more than one verified domain name, you need to provide the following claim for computers:
+
+* `http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`
+
+If you are already issuing an ImmutableID claim (e.g., alternate login ID) you need to provide one corresponding claim for computers:
+
+* `http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`
+
+In the following sections, you find information about:
+ 
+- The values each claim should have
+- How a definition would look like in AD FS
+
+The definition helps you to verify whether the values are present or if you need to create them.
+
+> [!NOTE]
+> If you don't use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims.
+
+#### Issue account type claim
+
+**`http://schemas.microsoft.com/ws/2012/01/accounttype`** - This claim must contain a value of **DJ**, which identifies the device as a domain-joined computer. In AD FS, you can add an issuance transform rule that looks like this:
+
+    @RuleName = "Issue account type for domain-joined computers"
+    c:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value = "DJ"
+    );
+
+#### Issue objectGUID of the computer account on-premises
+
+**`http://schemas.microsoft.com/identity/claims/onpremobjectguid`** - This claim must contain the **objectGUID** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
+
+    @RuleName = "Issue object GUID for domain-joined computers"
+    c1:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        store = "Active Directory", 
+        types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), 
+        query = ";objectguid;{0}", 
+        param = c2.Value
+    );
+ 
+#### Issue objectSID of the computer account on-premises
+
+**`http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid`** - This claim must contain the the **objectSid** value of the on-premises computer account. In AD FS, you can add an issuance transform rule that looks like this:
+
+    @RuleName = "Issue objectSID for domain-joined computers"
+    c1:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(claim = c2);
+
+#### Issue issuerID for computer when multiple verified domain names in Azure AD
+
+**`http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid`** - This claim must contain the Uniform Resource Identifier (URI) of any of the verified domain names that connect with the on-premises federation service (AD FS or 3rd party) issuing the token. In AD FS, you can add issuance transform rules that look like the ones below in that specific order after the ones above. Please note that one rule to explicitly issue the rule for users is necessary. In the rules below, a first rule identifying user vs. computer authentication is added.
+
+    @RuleName = "Issue account type with the value User when its not a computer"
+    NOT EXISTS(
+    [
+        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value == "DJ"
+    ]
+    )
+    => add(
+        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value = "User"
+    );
+    
+    @RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
+    c1:[
+        Type == "http://schemas.xmlsoap.org/claims/UPN"
+    ]
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value == "User"
+    ]
+    => issue(
+        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
+        Value = regexreplace(
+        c1.Value, 
+        ".+@(?<domain>.+)", 
+        "http://${domain}/adfs/services/trust/"
+        )
+    );
+    
+    @RuleName = "Issue issuerID for domain-joined computers"
+    c:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
+        Value = "http://<verified-domain-name>/adfs/services/trust/"
+    );
+
+
+In the claim above,
+
+- `$<domain>` is the AD FS service URL
+- `<verified-domain-name>` is a placeholder you need to replace with one of your verified domain names in Azure AD
+
+For more details about verified domain names, see [Add a custom domain name to Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-add-domain).  
+To get a list of your verified company domains, you can use the [Get-MsolDomain](https://docs.microsoft.com/en-us/powershell/module/msonline/get-msoldomain?view=azureadps-1.0) cmdlet. 
+
+#### Issue ImmutableID for computer when one for users exist (e.g. alternate login ID is set)
+
+**`http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID`** - This claim must contain a valid value for computers. In AD FS, you can create an issuance transform rule as follows:
+
+    @RuleName = "Issue ImmutableID for computers"
+    c1:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ] 
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        store = "Active Directory", 
+        types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), 
+        query = ";objectguid;{0}", 
+        param = c2.Value
+    );
+
+#### Helper script to create the AD FS issuance transform rules
+
+The following script helps you with the creation of the issuance transform rules described above.
+
+	$multipleVerifiedDomainNames = $false
+    $immutableIDAlreadyIssuedforUsers = $false
+    $oneOfVerifiedDomainNames = 'example.com'   # Replace example.com with one of your verified domains
+    
+    $rule1 = '@RuleName = "Issue account type for domain-joined computers"
+    c:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value = "DJ"
+    );'
+
+    $rule2 = '@RuleName = "Issue object GUID for domain-joined computers"
+    c1:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        store = "Active Directory", 
+        types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), 
+        query = ";objectguid;{0}", 
+        param = c2.Value
+    );'
+
+    $rule3 = '@RuleName = "Issue objectSID for domain-joined computers"
+    c1:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(claim = c2);'
+
+    $rule4 = ''
+    if ($multipleVerifiedDomainNames -eq $true) {
+    $rule4 = '@RuleName = "Issue account type with the value User when it is not a computer"
+    NOT EXISTS(
+    [
+        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value == "DJ"
+    ]
+    )
+    => add(
+        Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value = "User"
+    );
+    
+    @RuleName = "Capture UPN when AccountType is User and issue the IssuerID"
+    c1:[
+        Type == "http://schemas.xmlsoap.org/claims/UPN"
+    ]
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", 
+        Value == "User"
+    ]
+    => issue(
+        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
+        Value = regexreplace(
+        c1.Value, 
+        ".+@(?<domain>.+)", 
+        "http://${domain}/adfs/services/trust/"
+        )
+    );
+    
+    @RuleName = "Issue issuerID for domain-joined computers"
+    c:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", 
+        Value = "http://' + $oneOfVerifiedDomainNames + '/adfs/services/trust/"
+    );'
+    }
+
+    $rule5 = ''
+    if ($immutableIDAlreadyIssuedforUsers -eq $true) {
+    $rule5 = '@RuleName = "Issue ImmutableID for computers"
+    c1:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
+        Value =~ "-515$", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ] 
+    && 
+    c2:[
+        Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", 
+        Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"
+    ]
+    => issue(
+        store = "Active Directory", 
+        types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), 
+        query = ";objectguid;{0}", 
+        param = c2.Value
+    );'
+    }
+
+	$existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules 
+
+	$updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5
+
+	$crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules 
+
+	Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString 
+
+#### Remarks 
+
+- This script appends the rules to the existing rules. Do not run the script twice because the set of rules would be added twice. Make sure that no corresponding rules exist for these claims (under the corresponding conditions) before running the script again.
+
+- If you have multiple verified domain names (as shown in the Azure AD portal or via the Get-MsolDomains cmdlet), set the value of **$multipleVerifiedDomainNames** in the script to **$true**. Also make sure that you remove any existing issuerid claim that might have been created by Azure AD Connect or via other means. Here is an example for this rule:
+
+
+        c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
+        => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)",  "http://${domain}/adfs/services/trust/")); 
+
+- If you have already issued an **ImmutableID** claim  for user accounts, set the value of **$immutableIDAlreadyIssuedforUsers** in the script to **$true**.
+
+#### Configure Device Authentication in AD FS  
+Using an elevated PowerShell command window, configure AD FS policy by executing the following command  
+
+`PS C:>Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod All` 
+
+#### Check your configuration  
+For your reference, below is a comprehensive list of the AD DS devices, containers and permissions required for device write-back and authentication to work
+
+- object of type ms-DS-DeviceContainer at CN=RegisteredDevices,DC=&lt;domain&gt;  		
+	- read access to the AD FS service account   
+	- read/write access to the Azure AD Connect sync AD connector account
+- Container CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
+- Container Device Registration Service DKM under the above container
+
+![Device Registration](images/hybridct/device8.png) 
+ 
+- object of type serviceConnectionpoint at CN=&lt;guid&gt;, CN=Device Registration
+- Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;  
+  - read/write access to the specified AD connector account name on the new object 
+- object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&lt;domain&gt;
+- object of type msDS-DeviceRegistrationService in the above container
+
+>[!div class="nextstepaction"]
+[Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. Configure Azure Device Registration (*You are here*)
+5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md b/windows/access-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
new file mode 100644
index 0000000000..c4c4dd6085
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-trust-prereqs.md
@@ -0,0 +1,138 @@
+---
+title: Hybrid Windows Hello for Business Prerequistes (Windows Hello for Business)
+description: Prerequisites for Hybrid Windows Hello for Business Deployments
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 10/09/2017
+---
+# Hybrid Windows Hello for Business Prerequisites
+
+**Applies to**
+-   Windows 10
+
+
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+Hybrid environments are distributed systems that enable organizations to use on-premises and Azure-based identities and resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication that provides a single sign-in like experience to modern resources.
+
+The distributed systems on which these technologies were built involved several pieces of on-premises and cloud infrastructure.  High-level pieces of the infrastructure include:
+* [Directories](#directories)
+* [Public Key Infrastucture](#public-key-infastructure)
+* [Directory Synchronization](#directory-synchronization)
+* [Federation](#federation)
+* [MultiFactor Authetication](#multifactor-authentication)
+* [Device Registration](#device-registration)
+  
+## Directories ##
+Hybrid Windows Hello for Business needs two directories: on-premises Active Directory and a cloud Azure Active Directory.  The minimum required domain functional and forest functional levels for Windows Hello for Business deployment is Windows Server 2008 R2.
+
+A hybrid Windows Hello for Busines deployment needs an Azure Active Directory subscription.  The hybrid key trust deployment, may not require Azure Active Directory premium subscription.
+
+Windows Hello for Business can be deployed in any environment with Windows Server 2008 R2 or later domain controllers.  Azure device registration and Windows Hello for Business require the Windows Server 2016 Active Directory schema.  In addition to the Windows Server 2016 Active Directory schema, key trust deployments need an adequate number of Windows Server 2016 domain controllers at each site where users authenticate using Windows Hello for Business.
+ 
+Review these requirements and those from the Windows Hello for Business planning guide and worksheet.  Based on your deployment decisions you may need to upgrade your on-premises Active Directory or your Azure Active Directory subscription to meet your needs.
+
+### Section Review ###
+
+> [!div class="checklist"]
+> * Active Directory Domain Functional Level
+> * Active Directory Forest Functional Level
+> * Domain Controller version
+> * Windows Server 2016 Schema 
+> * Azure Active Directory subscription
+> * Correct subscription for desired features and outcomes  
+
+<br>
+
+## Public Key Infrastructure ##
+The Windows Hello for Business deployment depends on an enterprise public key infrastructure as trust anchor for authentication. Domain controllers for hybrid deployments need a certificate in order for Windows 10 devices to trust the domain controller.
+
+Key trust deployments do not need client issued certificates for on-premises authentication.  Active Directory user accounts are automatically configured for public key mapping by Azure AD Connect synchronizing the public key of the registered Windows Hello for Business credential to an attribute on the user's Active Diretory object.
+
+The minimum required enterprise certificate authority that can be used with Windows Hello for Business is Windows Server 2012.
+
+### Section Review
+> [!div class="checklist"]  
+> * Windows Server 2012 Issuing Certificate Authority
+> * Windows Server 2016 Active Directory Federation Services
+
+<br>
+
+## Directory Synchronization ##
+The two directories used in hybrid deployments must be synchronized.  You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
+  
+Organizations using older directory synchronization technology, such as DirSync or Azure AD sync need to upgrade to Azure AD Connect
+ 
+### Section Review 
+> [!div class="checklist"]
+> * Azure Active Directory Connect directory synchronization
+> * [Upgrade from DirSync](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-dirsync-upgrade-get-started)
+> * [Upgrade from Azure AD Sync](https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-upgrade-previous-version)
+
+<br>
+
+## Federation ##
+Federating your on-premises Active Directory with Azure Active Directory ensures all identities have access to all resources regardless if they reside in cloud or on-premises.  Windows Hello for Business hybrid certificate trust needs Windows Server 2016 Active Directory Federation Services.  All nodes in the AD FS farm must run the same version of AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices.
+
+The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4034658 (14393.1593)](https://support.microsoft.com/en-us/help/4034658), which is automatically downloaded and installed through Windows Update.  If your AD FS farm is not running the AD FS role with updates from Windows Server 2016, then read [Upgrading to AD FS in Windows Server 2016](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016)
+
+### Section Review ###
+> [!div class="checklist"]
+> * Windows Server 2016 Active Directory Federation Services
+> * Minimum update of [KB4034658 (14393.1593)](https://support.microsoft.com/en-us/help/4034658)
+
+<br>
+
+## Multifactor Authentication ##
+Windows Hello for Business is a strong, two-factor credential the helps organizations reduce their dependency on passwords.  The provisioning process lets a user enroll in Windows Hello for Business using their username and password as one factor. but needs a second factor of authentication.
+
+Hybrid Windows Hello for Business deployments can use Azure’s Multifactor Authentication service or they can use multifactor authentication provides by Windows Server 2016 Active Directory Federation Services, which includes an adapter model that enables third parties to integrate their multifactor authentication into AD FS.
+
+### Section Review 
+> [!div class="checklist"]
+> * Azure MFA Service
+> * Windows Server 2016 AD FS and Azure
+> * Windows Server 2016 AD FS and third party MFA Adapter
+
+<br>
+
+## Device Registration ##
+Organizations wanting to deploy hybrid key trust need thier domain joined devices to register to Azure Active Directory.  Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud.  This ensures that only approved computers are used with that Azure Active Directory.  Each computer registers its identity in Azure Active Directory. 
+ 
+
+### Section Checklist ###
+> [!div class="checklist"]
+> * Azure Active Directory Device writeback
+> * Azure Active Directory Premium subscription
+
+<br>
+
+### Next Steps ###
+Follow the Windows Hello for Business hybrid key trust deployment guide.  For proof-of-concepts, labs, and new installations, choose the **New Installation Basline**.  
+
+If your environment is already federated, but does not include Azure device registration, choose **Configure Azure Device Registration**. 
+
+If your environment is already federated and supports Azure device registration, choose **Configure Windows Hello for Business settings**.
+
+> [!div class="op_single_selector"]
+> - [New Installation Baseline](hello-hybrid-key-new-install.md)
+> - [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
+> - [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-key-trust.md)
+2. Prerequistes (*You are here*)
+3. [New Installation Baseline](hello-hybrid-key-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-key-trust-devreg.md)
+5. [Configure Windows Hello for Business settings](hello-hybrid-key-whfb-settings.md)
+6. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-trust.md b/windows/access-protection/hello-for-business/hello-hybrid-key-trust.md
new file mode 100644
index 0000000000..dbded7ce90
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-trust.md
@@ -0,0 +1,51 @@
+---
+title: Hybrid Key Trust Deployment (Windows Hello for Business)
+description: Hybrid Key Trust Deployment Overview
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, key-trust
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 10/09/2017
+---
+# Hybrid Azure AD joined Key Trust Deployment
+
+**Applies to**
+-   Windows 10
+
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+ 
+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 a hybrid key trust scenario.
+
+It is recommended that you review the Windows Hello for Business planning guide prior to using the deployment guide.  The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.  You can review the [planning guide](https://docs.microsoft.com/en-us/windows/access-protection/hello-for-business/hello-planning-guide) and download the [planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514).
+
+This deployment guide provides guidance for new deployments and customers who are already federated with Office 365.  These two scenarios provide a baseline from which you can begin your deployment.
+
+## New Deployment Baseline ##
+The new deployment baseline helps organizations who are moving to Azure and Office 365 to include Windows Hello for Business as part of their deployments.  This baseline is good for organizations who are looking to deploy proof of concepts as well as IT professionals who want to familiarize themselves Windows Hello for Business by deploying a lab environment.
+ 
+This baseline provides detailed procedures to move your environment from an on-premises only environment to a hybrid environment using Windows Hello for Business to authenticate to Azure Active Directory and to your on-premises Active Directory using a single Windows sign-in.
+ 
+## Federated Baseline ##
+The federated baseline helps organizations that have completed their federation with Azure Active Directory and Office 365 and enables them to introduce Windows Hello for Business into their hybrid environment.  This baseline exclusively focuses on the procedures needed to add Azure Device Registration and Windows Hello for Business to an existing hybrid deployment.
+
+Regardless of the baseline you choose, you’re next step is to familiarize yourself with the prerequisites needed for the deployment.  Many of the prerequisites will be new for organizations and individuals pursuing the new deployment baseline. Organizations and individuals starting from the federated baseline will likely be familiar with most of the prerequisites, but should validate they are using the proper versions that include the latest updates.
+
+> [!div class="nextstepaction"]
+> [Prerequistes](hello-hybrid-key-trust-prereqs.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid key trust deployment guide
+1. Overview (*You are here*)
+2. [Prerequistes](hello-hybrid-key-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-key-new-install.md)
+4. [Device Registration](hello-hybrid-key-trust-devreg.md)
+5. [Configure Windows Hello for Business settings](hello-hybrid-cert-whfb-settings.md)
+6. [Sign-in and Provision](hello-hybrid-key-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-provision.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
new file mode 100644
index 0000000000..744f4930a3
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-provision.md
@@ -0,0 +1,75 @@
+---
+title: Hybrid Windows Hello for Business Provisioning (Windows Hello for Business)
+description: Provisioning for Hybrid Windows Hello for Business Deployments
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, certificate-trust
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+author: mikestephens-MS
+ms.author: mstephen
+localizationpriority: high
+ms.date: 09/08/2017
+---
+# Hybrid Windows Hello for Business Provisioning
+
+**Applies to**
+-   Windows 10
+
+
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+## Provisioning
+The Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop.  Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
+
+![Event358](images/Event358.png)
+
+The first thing to validate is the computer has processed device registration. You can view this from the User device registration logs where the check **Device is AAD joined (AADJ or DJ++): Yes** appears.  Additionally, you can validate this using the **dsregcmd /status** command from a console prompt where the value for **EnterpriseJoined** reads **Yes**.
+
+![dsreg output](images/dsregcmd.png)
+
+
+Windows Hello for Business provisioning begins with a full screen page with the title **Setup a PIN** and button with the same name.  The user clicks **Setup a PIN**.
+
+![Setup a PIN Provisioning](images/setupapin.png)
+
+The provisioning flow proceeds to the Multi-Factor authentication portion of the enrollment.  Provisioning informs the user that it is actively attempting to contact the user through their configured form of MFA.  The provisioning process does not proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry.
+  
+![MFA prompt during provisioning](images/mfa.png)
+
+After a successful MFA, the provisioning flow asks the user to create and validate a PIN.  This PIN must observe any PIN complexity requirements that you deployed to the environment.
+
+<createaPin.png>
+
+The provisioning flow has all the information it needs to complete the Windows Hello for Business enrollment.
+* A successful single factor authentication (username and password at sign-in)
+* A device that has successfully completed device registration
+* A fresh, successful multi-factor authentication
+* A validated PIN that meets the PIN complexity requirements
+
+The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Azure Active Directory to register the public key.  AAD Connect syncrhonizes the user's key to the on-prem Active Directory.
+
+> [!IMPORTANT]
+> The minimum time needed to syncrhonize the user's public key from Azure Active Directory to the on-premises Active Directory is 30 minutes.  This synchronization latency delays the certificate enrollment for the user.  After the user's public key has synchronized to Active Directory, the user's certificate enrolls automatically as long as the user's session is active (actively working or locked, but still signed-in).  Also, the Action Center notifies the user thier PIN is ready for use.
+
+> [!NOTE]
+> Microsoft is actively investigating ways to reduce the syncrhonization latency and delays in certificate enrollment with the goal to make certificate enrollment occur real-time.  
+  
+After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate.  Windows send the certificate request to the AD FS server for certificate enrollment.
+  
+The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.
+
+The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority.  The registration authority returns the certificate to Windows where it then installs the certificate in the current user’s certificate store.  Once this process completes, the Windows Hello for Business provisioning workflow informs the user  they can use their PIN to sign-in through the Windows Action Center.
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. [Configure Windows Hello for Business policy settings](hello-hybrid-cert-whfb-settings-policy.md)
+6. Sign-in and Provision(*You are here*) 
+
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
new file mode 100644
index 0000000000..27eba8dd44
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-ad.md
@@ -0,0 +1,81 @@
+---
+title: Configuring Hybrid Windows Hello for Business - Active Directory (AD)
+description: Discussing the configuration of Active Directory (AD) in a Hybrid deployment of Windows Hello for Business
+keywords: identity, PIN, biometric, Hello, passport, WHFB, ad
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+localizationpriority: high
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 09/08/2017
+---
+# Configuring Windows Hello for Business: Active Directory
+
+**Applies to**
+-   Windows 10
+
+>[!div class="step-by-step"]
+[< Configure Windows Hello for Business](hello-hybrid-cert-whfb-settings.md)
+[Configure Azure AD Connect >](hello-hybrid-cert-whfb-settings-dir-sync.md)
+
+The key synchronization process for the hybrid deployment of Windows Hello for Business needs the Windows Server 2016 Active Directory schema. 
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+### Creating Security Groups
+
+Windows Hello for Business uses several security groups to simplify the deployment and managment.
+
+> [!Important]
+> If your environment has one or more Windows Server 2016 domain controllers in the domain to which you are deploying Windows Hello for Business, then skip the **Create the KeyCredentials Admins Security Group**.  Domains that include Windows Server 2016 domain controllers use the KeyAdmins group, which is created during the installation of the first Windows Server 2016 domain controller.
+
+#### Create the KeyCredential Admins Security Group
+
+Azure Active Directory Connect synchronizes the public key on the user object created during provisioning.  You assign write and read permission to this group to the Active Directory attribute to ensure the Azure AD Connect service can add and remove keys as part of its normal workflow.
+
+Sign-in a domain controller or management workstation with *Domain Admin* 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 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 users with the proper permissions to provision Windows Hello for Business and to enroll in the Windows Hello for Business authentication certificate.
+
+Sign-in a domain controller or management workstation with *Domain Admin* 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**.
+
+### Section Review
+
+> [!div class="checklist"]
+> * Create the KeyCredential Admins Security group (optional)
+> * Create the Windows Hello for Business Users group
+
+>[!div class="step-by-step"]
+[< Configure Windows Hello for Business](hello-hybrid-cert-whfb-settings.md)
+[Configure Azure AD Connect >](hello-hybrid-cert-whfb-settings-dir-sync.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. Configure Windows Hello for Business settings: Active Directory (*You are here*)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-adfs.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-adfs.md
new file mode 100644
index 0000000000..e68276a09e
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-adfs.md
@@ -0,0 +1,89 @@
+---
+title:  Configuring Hybrid Windows Hello for Business - Active Directory Federation Services (ADFS)
+description: Discussing the configuration of Active Directory Federation Services (ADFS) in a Hybrid deployment of Windows Hello for Business
+keywords: identity, PIN, biometric, Hello, passport, WHFB, adfs
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+localizationpriority: high
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 09/08/2017
+---
+# Configure Windows Hello for Business: Active Directory Federation Services
+
+**Applies to**
+-   Windows10
+
+## Federation Services
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+>[!div class="step-by-step"]
+[< Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
+[Configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md)
+
+
+The Windows Server 2016 Active Directory Fedeartion Server Certificate Registration Authority (AD FS RA) 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.
+
+### Configure the Registration Authority
+
+Sign-in the AD FS server with *Domain Admin* equivalent credentials. 
+
+1.	Open a **Windows PowerShell** prompt.
+2.	Type the following command   
+  
+    ```PowerShell
+    Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
+    ```
+
+
+The `Set-AdfsCertificateAuthority` cmdlet should show the following warning:
+>WARNING: PS0343: Issuing Windows Hello certificates requires enabling a permitted strong authentication provider, but no usable providers are currently configured.  These authentication providers are not supported for Windows Hello certificates: CertificateAuthentication,MicrosoftPassportAuthentication. Windows Hello certificates will not be issued until a permitted strong authentication provider is configured.
+
+This warning indicates that you have not configured multi-factor authentication in AD FS and until it is configured, the AD FS server will not issue Windows Hello certificates.  Windows 10, version 1703 clients check this configuration during prerequisite checks.  If detected, the prerequisite check will not succeed and the user will not provision Windows Hello for Business on sign-in.
+
+>[!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.
+
+
+### Group Memberships for the AD FS Service Account
+
+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.
+
+Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+
+1. Open **Active Directory Users and Computers**.
+2. Click the **Users** container in the navigation pane.
+3. Right-click **Windows Hello for Business Users** group
+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.	Restart the AD FS server.
+
+### Section Review
+> [!div class="checklist"]
+> * Configure the registration authority
+> * Update group memberships for the AD FS service account
+
+
+>[!div class="step-by-step"]
+[< Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
+[Configure policy settings >](hello-hybrid-cert-whfb-settings-policy.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. Configure Windows Hello for Business settings: AD FS (*You are here*)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
+
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
new file mode 100644
index 0000000000..084999e656
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-dir-sync.md
@@ -0,0 +1,86 @@
+---
+title: Configuring Hybrid Windows Hello for Business - Directory Synchronization
+description: Discussing Directory Synchronization in a Hybrid deployment of Windows Hello for Business
+keywords: identity, PIN, biometric, Hello, passport, WHFB, dirsync, connect
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+localizationpriority: high
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 09/08/2017
+---
+# Configure Hybrid Windows Hello for Business: Directory Synchronization
+
+**Applies to**
+-   Windows 10
+
+>[!div class="step-by-step"]
+[< Configure Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
+[Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
+
+## Directory Syncrhonization
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure.  Azure AD Connect synchronizes the Windows Hello for Business public key to Active Directory.  
+
+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.
+
+> [!IMPORTANT]
+> If you already have a Windows Server 2016 domain controller in your domain, you can skip **Configure Permissions for Key Synchronization**.
+
+### Configure Permissions for Key Syncrhonization
+
+Sign-in a domain controller or management workstations with *Domain Admin* equivalent credentials.
+
+1. Open **Active Directory Users and Computers**.
+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. 
+
+
+### Group Memberships for the Azure AD Connect Service Account
+
+The KeyAdmins or KeyCredential Admins global group provides the Azure AD Connect service with the permissions needed to read and write the public key to Active Directory.  
+
+Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials.
+
+1. Open **Active Directory Users and Computers**.
+2. Click the **Users** container in the navigation pane.
+>[!IMPORTANT]
+> If you already have a Windows Server 2016 domain controller in your domain, use the Keyadmins group in the next step, otherwise use the KeyCredential admins group you previously created.
+
+3. Right-click either the **KeyAdmins** or **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 the name of the Azure AD Connect service account.  Click **OK**.
+6. Click **OK** to return to **Active Directory Users and Computers**.
+
+### Section Review
+
+> [!div class="checklist"]
+> * Configure Permissions for Key Synchronization
+> * Configure group membership for Azure AD Connect
+
+>[!div class="step-by-step"]
+[< Configure Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
+[Configure PKI >](hello-hybrid-cert-whfb-settings-pki.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. Configure Windows Hello for Business settings: Directory Syncrhonization (*You are here*)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
new file mode 100644
index 0000000000..27ea8e8a47
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-pki.md
@@ -0,0 +1,199 @@
+---
+title: Configuring Hybrid Windows Hello for Business - Public Key Infrastructure (PKI)
+description: Discussing the configuration of the Public Key Infrastructure (PKI) in a Hybrid deployment of Windows Hello for Business
+keywords: identity, PIN, biometric, Hello, passport, WHFB, PKI
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+localizationpriority: high
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 09/08/2017
+---
+
+# Configure Hybrid Windows Hello for Business: Public Key Infrastructure
+
+**Applies to**
+-   Windows 10
+
+> [!div class="step-by-step"]
+[< Configure Azure AD Connect](hello-hybrid-cert-whfb-settings-dir-sync.md)
+[Configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+Windows Hello for Business deployments rely on certificates.  Hybrid deployments uses publicly issued server authentication certifcates to validate the name of the server to which they are connecting and to encyrpt the data that flows them and the client computer.
+
+All deployments use enterprise issed certificates for domain controllers as a root of trust.  Hybrid certificate trust deployments issue users sign-in certificate that enables them to authenticate using Windows Hello for Business credentials to non-Windows Server 2016 domain controllers.  Additionally, hybrid certificate trust deployments issue certificate to registration authorites to provide defenese-in-depth security for issueing user authentication certificates. 
+
+## Certifcate Templates
+
+This section has you configure certificate templates on your Windows Server 2012 or later issuing certificate authtority. 
+
+### Domain Controller certificate template
+
+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.
+
+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.
+
+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 a baseline to create an updated domain controller certificate template.
+
+#### Create a Domain Controller Authentication (Kerberos) Certificate Template
+
+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 **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 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 **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** 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.
+
+#### Configure Certificate Suspeding for the Domain Controller Authentication (Kerberos) Certificate Template
+
+Many domain controllers may have an existing domain controller certificate.  The Active Directory Certificate Services provides a default certificate template for 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 (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 a certificate authority or management workstations with _Enterprise 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 **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**.
+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.
+
+### Enrollment Agent certificate template
+
+Active Directory Federation Server used for Windows Hello for Business certificate enrollment 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.
+
+> [!IMPORTANT]
+> Follow the procedures below based on the AD FS service account used in your  environment. 
+
+#### Creating an Enrollment Agent certificate for Group Managed Service Accounts
+
+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 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.
+
+#### Creating an Enrollment Agent certificate for typical Service Acconts
+
+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.
+
+### Creating 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 Admin 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 Admin_ 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 Templates
+
+### Publish Certificate Templates to a Certificate Authority
+
+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.
+
+### Unpublish Superseded 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.
+
+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 certificate authority or management workstation 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 **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.
+
+### Section Review
+> [!div class="checklist"]
+> * Domain Controller certificate template
+> * Configure superseded domain controller certificate templates
+> * Enrollment Agent certifcate template
+> * Windows Hello for Business Authentication certificate template
+> * Mark the certifcate template as Windows Hello for Business sign-in template
+> * Publish Certificate templates to certificate authorities
+> * Unpublish superseded certificate templates
+
+
+> [!div class="step-by-step"]
+[< Configure Azure AD Connect](hello-hybrid-cert-whfb-settings-dir-sync.md)
+[Configure AD FS >](hello-hybrid-cert-whfb-settings-adfs.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. Configure Windows Hello for Business settings: PKI (*You are here*)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
+
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
new file mode 100644
index 0000000000..2c0b6759f9
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy.md
@@ -0,0 +1,204 @@
+---
+title: Configuring Hybrid Windows Hello for Business - Group Policy
+description: Discussing the configuration of Group Policy in a Hybrid deployment of Windows Hello for Business
+keywords: identity, PIN, biometric, Hello, passport, WHFB
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+localizationpriority: high
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 09/08/2017
+---
+# Configure Hybrid Windows Hello for Business: Group Policy
+
+**Applies to**
+-   Windows 10
+
+> [!div class="step-by-step"]
+[< Configure AD FS](hello-hybrid-cert-whfb-settings-adfs.md)
+
+
+## Policy Configuration
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+
+You need a Windows 10, version 1703 workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business and PIN Complexity Group Policy settings.  To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows 10. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=45520).
+Install the Remote Server Administration Tools for Windows 10 on a computer running Windows 10, version 1703.
+
+Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10 Creators Edition (1703) 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](https://support.microsoft.com/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administrative-templates-in-windows) for more information.
+
+Domain controllers of Windows Hello for Business deployments need one Group Policy setting, which enables automatic certificate enrollment for the newly create domain controller authentication certificate. This policy setting ensures domain controllers (new and existing) autoamtically request and renew the correct domain controller certifcate.  
+
+Domain joined clients of hybrid certificate-based deployments of Windows Hello for Business needs three Group Policy settings:
+* Enable Windows Hello for Business
+* Use certificate for on-premises authentication
+* Enable automatic enrollment of certificates
+
+### 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.
+
+#### Create a Domain Controller Automatic Certifiacte Enrollment Group Policy object
+
+Sign-in a domain controller or management workstations 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.
+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 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**.
+
+### Windows Hello for Business Group Policy
+
+The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory
+
+#### Enable Windows Hello for Business
+
+The Enable Windows Hello for Business Group Policy setting is the configuration needed for Windows to determine if a user should be attempt to enroll for Windows Hello for Business.  A user will only attempt enrollment if this policy setting is configured to enabled.  
+
+You can configure the Enable Windows Hello for Business Group Policy setting for computer or users. Deploying this policy setting to computers results in ALL users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment.  Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence.
+
+#### Use certificate for 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 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
+
+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. 
+
+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.
+
+#### 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.
+
+Sign-in a domain controller or management workstations 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.
+3. Right-click **Group Policy object** and select **New**.
+4. Type *Enable Windows Hello for Business* in the name box and click **OK**.
+5. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and click **Edit**.
+6. In the navigation pane, expand **Policies** under **User Configuration**.
+7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
+8. In the content pane, double-click **Use Windows Hello for Business**. Click **Enable** and click **OK**.
+9. Double-click **Use certificate for on-premises authentication**. Click **Enable** and click **OK**.  Close the **Group Policy Management Editor**.
+
+#### Configure Automatic Certificate Enrollment
+
+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**.
+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.
+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. 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**.
+5. Click the **Delegation** tab. Select **Authenticated Users** and click **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**.
+
+#### 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.
+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. 
+
+## 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
+
+The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials.  When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential.
+
+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 unforgiven 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.
+
+#### 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.
+
+### PIN Complexity
+
+PIN complexity is not specific to Windows Hello for Business. Windows 10 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 10 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:
+* Require digits
+* Require lowercase letters
+* Maximum PIN length
+* Minimum PIN length
+* Expiration
+* History
+* Require special characters
+* Require uppercase letters
+
+Starting with 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**  of the Group Policy editor.
+
+## 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 Wwindows 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 who are not members of this group will not attempt to enroll for Windows Hello for Business.
+
+### Section Review
+> [!div class="checklist"]
+> * Configure domain controllers for automatic certificate enrollment.
+> * Create Windows Hello for Business Group Policy object.
+> * Enable the Use Windows Hello for Business policy setting.
+> * Enable the Use certificate for on-premises authentication policy setting.
+> * Enable user automatic certificate enrollment.
+> * Add users or groups to the Windows Hello for Business group
+
+
+> [!div class="nextstepaction"]
+[Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. Configure Windows Hello for Business policy settings (*You are here*)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings.md b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
new file mode 100644
index 0000000000..2dbfc5fda4
--- /dev/null
+++ b/windows/access-protection/hello-for-business/hello-hybrid-key-whfb-settings.md
@@ -0,0 +1,50 @@
+---
+title: Configure Hybrid Windows Hello for Business Settings (Windows Hello for Business)
+description: Configuring Windows Hello for Business Settings in Hybrid deployment
+keywords: identity, PIN, biometric, Hello, passport, WHFB, hybrid, certificate-trust
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security, mobile
+localizationpriority: high
+author: mikestephens-MS
+ms.author: mstephen
+ms.date: 09/08/2017
+---
+# Configure Windows Hello for Business
+
+**Applies to**
+-   Windows 10
+
+> [!div class="step-by-step"]
+[Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md)
+
+>[!IMPORTANT]
+>This guide only applies to Hybrid deployments for Windows 10, version 1703 or higher.
+ 
+You're environment is federated and you are ready to configure your hybrid environment for Windows Hello for business using the certificate trust model.  
+> [!IMPORTANT]
+> If your environment is not federated, review the [New Installation baseline](hello-hybrid-cert-new-install.md) section of this deployment document to learn how to federate your environment for your Windows Hello for Business deployment.  
+
+The configuration for Windows Hello for Business is grouped in four categories.  These categories are: 
+* [Active Directory](hello-hybrid-cert-whfb-settings-ad.md)
+* [Public Key Infrastructure](hello-hybrid-cert-whfb-settings-pki.md)
+* [Active Directory Federation Services](hello-hybrid-cert-whfb-settings-adfs.md)
+* [Group Policy](hello-hybrid-cert-whfb-settings-policy.md)
+
+For the most efficent deployment, configure these technologies in order beginning with the Active Directory configuration
+
+> [!div class="step-by-step"]
+[Configure Active Directory >](hello-hybrid-cert-whfb-settings-ad.md)
+
+<br><br>
+
+<hr>
+
+## Follow the Windows Hello for Business hybrid certificate trust deployment guide
+1. [Overview](hello-hybrid-cert-trust.md)
+2. [Prerequistes](hello-hybrid-cert-trust-prereqs.md)
+3. [New Installation Baseline](hello-hybrid-cert-new-install.md)
+4. [Configure Azure Device Registration](hello-hybrid-cert-trust-devreg.md)
+5. Configure Windows Hello for Business settings (*You are here*)
+6. [Sign-in and Provision](hello-hybrid-cert-whfb-provision.md)
\ No newline at end of file
diff --git a/windows/access-protection/hello-for-business/images/dc-chart1.png b/windows/access-protection/hello-for-business/images/dc-chart1.png
new file mode 100644
index 0000000000..52e0f0500e
Binary files /dev/null and b/windows/access-protection/hello-for-business/images/dc-chart1.png differ
diff --git a/windows/access-protection/hello-for-business/images/dc-chart2.png b/windows/access-protection/hello-for-business/images/dc-chart2.png
new file mode 100644
index 0000000000..748a6a4c41
Binary files /dev/null and b/windows/access-protection/hello-for-business/images/dc-chart2.png differ
diff --git a/windows/access-protection/hello-for-business/images/dc-chart3.png b/windows/access-protection/hello-for-business/images/dc-chart3.png
new file mode 100644
index 0000000000..87d80d4c4f
Binary files /dev/null and b/windows/access-protection/hello-for-business/images/dc-chart3.png differ
diff --git a/windows/access-protection/hello-for-business/images/dc-chart4.png b/windows/access-protection/hello-for-business/images/dc-chart4.png
new file mode 100644
index 0000000000..205bf1b216
Binary files /dev/null and b/windows/access-protection/hello-for-business/images/dc-chart4.png differ
diff --git a/windows/access-protection/hello-for-business/images/dc-chart5.png b/windows/access-protection/hello-for-business/images/dc-chart5.png
new file mode 100644
index 0000000000..19d1050916
Binary files /dev/null and b/windows/access-protection/hello-for-business/images/dc-chart5.png differ