Incorp pics on provisioning page

corrected style and spacing on devreg page

windows/access-protection/hello-for-business/hello-hybrid-cert-trust-devreg.md

@@ -51,7 +51,7 @@ Azure Active Directory is now configured for device registration. Next, you need
 
 To use Windows Hello for Business with Hybrid Azure AD joined devices, you must first upgrade your Active Directory schema to Windows Server 2016. 
 
->![IMPORTANT]
+> [!IMPORTANT]
 > If you already have a Windows Server 2016 domain controller in your forest, you can skip **Upgrading Active Directory to the Windows Server 2016 Schema** (this section).
 
 #### Identify the schema role domain controller
@@ -113,11 +113,11 @@ If your AD FS farm is not already configured for Device Authentication (you can
 
 ![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 powershell prompt.  Then, execute the following PowerShell commands:  
+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 hit Yes.
+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$"
@@ -190,7 +190,7 @@ Windows current devices authenticate using Integrated Windows Authentication to
 > [!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<EFBFBD>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).
+> 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.
 
@@ -214,7 +214,7 @@ In the following sections, you find information about:
 The definition helps you to verify whether the values are present or if you need to create them.
 
 > [!NOTE]
-> If you don<EFBFBD>t use AD FS for your on-premises federation server, follow your vendor's instructions to create the appropriate configuration to issue these claims.
+> 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
 
@@ -489,26 +489,16 @@ Using an elevated PowerShell command window, configure AD FS policy by executing
 #### 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</br></br>
-
+	- 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</br></br> 
-
-
-- object of type msDS-DeviceRegistrationServiceContainer at CN=Device Registration Services,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=&ltdomain>  
-
-
+  - 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

windows/access-protection/hello-for-business/hello-hybrid-cert-whfb-provision.md

@@ -21,19 +21,20 @@ localizationpriority: high
 ## 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.png>
+![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**.
 
-<dsregcmd.png?
+![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**.
 
-<setupapin.png>
+![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.png>
+![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.