I love the Out of Box Experience (OOBE) combined with Azure AD (AAD) on Windows 10. It gives you AAD join from anywhere and automatically enrolls the device into MDM (in my case AirWatch WorkspaceONE). This is what modern management is all about - cloud, cloud, cloud. However, most organizations still have a lot of on-prem resources that they will need to access from that client such as web sites, CIFS File Shares, printers, LDAP applications, and others. Windows Hello for Business enables this by using a certificate deployed to the client via an on-prem Microsoft CA. Without this cert, your on-prem AD has no way to validate your identity on the client.

There are two ways to implement this. One is "key-trust" and the other is "cert-trust". Key trust uses a certificate deployed directly from Azure and syncs in back to your on-prem AD as a user attribute (ms-DS-KeyCredentialLink) and your domain controllers are able to use this for kerberos validation. This is a much simpler process to setup, but it requires your devices to be "hybrid" meaning on-prem AD joined + Azure AD registered. Here's a decent article on setting up key-trust. For "cloud only" AAD joined machines (like ones that have gone through OOBE), you must use cert-trust method. This is the method I'm using. In part 1, I will be detailing how to setup:

1. VMware Enterprise Connector which enables certificates to your client from an on-prem Certificate Authority
2. Create and publish new Domain Controller Kerberos certificates
3. Create and publish Windows Hello for Business smart card certificate template

Part 2 will then go into

1. Setting up web based Certificate Revocation List (CRL) 
2. How to setup the MS Certificate Authority and WHFB Template in the Workspace ONE console
3. How to setup a profile to deliver this payload
4. How to setup a profile to enable WHFB and set PIN requirements
5. Basic troubleshoot and how to validate its working

​
​I will also not be using ADFS, but instead use WorkspaceONE for identify and federation. WS1 will also be used to deploy the certificate to client. 

The full list of pre-reqs are here. We'll be using the "hybrid deployment" even though the client itself is cloud only joined. The hybrid term refers to the architecture setup, meaning you are syncing your on-prem AD data into information into Azure AD.

• Windows Server 2016 Schema
• Server 2008 R2 or newer domain/forest functional level
• Federation - MS documentation details ADFS, but I will show how to set it up without it and use WS1 for federation and cert delivery instead.
• Server 2012 or later Microsoft Certificate authority
• Azure AD Premium to enable automatic MDM enrollment
• Azure AD connect setup and configured
• WorkspaceONE side
  • Federation setup and working
  • VMware Enterprise Systems Connector (used to be called ACC)

In my setup, I'm using 2016 versions of everything to make it unified across the board.

Given the requirements above, there is a fair bit of prep-work involved that I won't be detailing in this blog.

1. Ensure your Domain Controllers are updated to 2016 schema
2. Setup your MS Certificate Authority servers. I will detail the template setup and the CRL stuff, but you'll have to setup the server first.
3. WorkpaceONE federation with AAD
4. Setup Azure AD connect to sync your users into AAD

Once you've done those things, then you can start with Step 1 below.

If you are using WorkpaceONE for anything you probably already have a VMware Enterprise Systems Connector setup and working. This connector lives inside your network and acts as a bridge to sync in AD data as well as giving WS1 a way to request and deploy certs from your on-prem MS CA. In case you don't have set it up in a test environment, here are the basic steps:
1. Login to the AirWatch WorkspaceOne console. At the Organization Group you are have setup your AD directory services connection in the WS1 console, click on All Settings --> System --> Enterprise Integration --> VMware Enterprise Systems Connector.
2. Click Override, and ensure both check boxes are checked.

3. Click on Download VMware Enterprise Systems Connector Installer. Enter a password and then click download.
NOTE this download is uniquely tied to this Organization Group and will only talk to it. It won't talk to any other OGs unless they are inheriting from this one.

4. Take this installer file and install on any server internal to your network that can talk to your AD and MS CA. 
NOTE there is no user interface for this on the server side, but you will see "AirWatch Cloud Connector and AirWatch Diagnostic Service (ACC)" services running.

Before beginning this step, you will need to setup up a service account in AD to be used to enroll the cert on behalf of users. This is required as the end users themselves may or many not have direct access to the internal network when the cert is being deployed. AirWatch will be the one doing the cert delivery. Once complete, you can then proceed with the following steps.
​NOTE: These are taken directly from MS's documentation. I've just cleaned it up a bit and added screenshots.
​
Create Domain Controller Kerberos Certificate Template
First, we need new Domain Controller Kerberos Certificate templates created for your DC's. These new templates enable the Key Distribution Center (KDC) and provide clients a root of trust external to the domain.
1. Login to your CA server and launch certsrv.msc
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.

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. Click OK and this new template should show up in the list

Configure Certificate Superceding for the Domain Controller Authentication (Kerberos) Certificate Template
Now we basically need to tell the domain controllers to use this new template for Kerberos authentication. You'll notice it has the "KDC Authentication" added to the template whereas the previous domain controller template did not. Again, following MS steps here:
1. Double-click the Domain Controller Authentication (Kerberos) template you just created and go to Superceded Templates tab.
2. Click Add and select Domain Controller template and click OK.
3. Repeat for Domain Controller Authentication and Kerberos Authentication templates. 
4. Add any others that were previously configured for domain controllers
5. Click OK when finished.

6. This is not yet active until we "Publish" this new template. To do this, right click Certificate Templates in certsrv.msc. CLick new and then Certificate Template to Issue.
7. Select the newly created Domain Controller Authentication (Kerberos) ​template.

8. As best practice, it is good to delete those old templates that have been superceded. Select Domain Controller, Domain Controller Authentication, and Kerberos Authentication from the list and click delete. Note you are only delete these as published templates, not the actual templates themselves.

9. When prompted with "Are you sure you want to disable" message, click ​Yes.

Deploy new Domain Controller Certs
In order for your DC's to get these new certs, you will either have to manually request them or setup a GPO so that they automatically request new ones. It's best to manually request them for now to test and validate and then setup the GPO once its ready to go live. I'm assuming you're doing this in a staging environment first :)
To manually request the new cert,
1. Login to the DC
2. Load certlm.msc and browse to Local Computer\Personal\Certificates
3. Right click in the blank space, and click All Tasks, Request new certificate.​

4. Select Active Diretory Enrollment Policy and click Next.

5. Select your newly created Domain Controller Authentication (Kerberos) from the list and click ​Enroll.

6. It should show Succeeded. Then click Finish.​

7. You might still have your old certs in the personal store, so go ahead and delete those out. In my case I have two old ones.

Setup Windows Hello for Business Template
Head back over to your CA and to the list of templates. Following again the steps from MS with some slight modification
1. Right click Smartcard Logon and click Duplicate Template

3. ​On the General tab, type WHFB Authentication in Template display name. Adjust the validity and renewal period to meet your enterprise's needs.

4. 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.

5.  On the Extensions tab, verify the Application Policies extension includes Smart Card Logon.

6. On the Issuance Requirements tab, leave everything blank. This is where we will differ from the MS documentation as we are not using ADFS.

7. On the Subject Name tab, select Supply in the Request and check the box. This is also different from MS as we aren't using ADFS. This setting allows WS1 to supply the CA the user information from the AW console (enrolled user).

8. On the Request Handling tab, ensure Signature and Encryption and the Renew with same key check box are selected. Also ensure the Enroll Subject without requiring any user input​ is also selected.

9. On the Security tab, add your service account here and ensure that Read, Enroll, and AutoEnroll are selected. Remove the Enroll and AutoEnroll from all other objects here.

10. Click ok to save the template.
11. Back in certsrv mmc, right click Certificate Templates, then New, then Certificate Template to Issue and select WHFB Authentication to publish this template. You should then see it in the Certifcate templates list. 

Next in Part 2, I'll go over how to setup an HTTP url and then get everything ready on the WS1 console side to be able to deploy the cert automatically to client. 

Update 4/17/18: This process does NOT require the end user to be local admin as I orginally thought. You can deploy via SCCM in the system context.
​
AirWatch 9.3 brings a number of new features to the WorkspaceONE UEM platform on Windows 10 including improved silent enrollment features. This will greatly simplify enrollment over the previous method. The new 9.3 agent brings the following updates to silent enrollment:

• On domain joined systems, it will automatically enroll as the "logged in user", regardless of whether they are an admin or not. It does this by matching the UPN of the logged in user to one in the AW console (this is assuming you've synced your AD users into AirWatch).
• If the enroll-as-logged-in user fails, it will fall back to use username and password and prompts the end user to input this information. This is also useful for non-domain systems or for when the logged-in user doesn't have a valid AirWatch username. See below: 

The primary use cases for this process are:

• Win10 client is joined to the domain (completely silent)
• Win10 client is NOT joined to the domain and you want to use the fall back to username and password popup
• If you want to silently enroll non-domain systems with no user interaction, device registration is required. For steps on that, check out my other blog.

• ​AirWatch agent and console 9.3 or higher
• Deploy Application with SCCM  in system context
• User Group Mapping should be turned on at the highest OG in order for the end user to not have to type in GroupID, otherwise you'll see this:

• Client must be joined to the domain and end-user profile must be a domain user for the "ASSIGNTOLOGGEDINUSER" switch to work. If the client is in a workgroup and/or the user is a local account the "ASSIGNTOLOGGEDINUSER" will fail (since it can't find matching username in AirWatch console) and will prompt for username and password.

This blog post will detail how to automatically enroll a Windows 10 system into AirWatch WorkspaceONE that has been newly imaged with MDT. This solution will work with though any imaging solution as well as in-place upgrades task sequences.
Requirements:

• The end user profiles must have local administrator rights (or any least temporary admin rights to complete enrollment. Admin rights can be removed after enrollment is complete)
• REST API enabled in the console
• MDT Wizard enabled to prompt for local administrator or another variable popup so that the script knows which user to pre-register the device to.

First, enable REST API in the AirWatch console and setup an API user per the steps in this post. I recommend creating an API admin role that is locked down to only a few functions so it reduces the risk of anything happening if the credentials get discovered somehow. 
​

Update March 2018

• This method is mainly used for Windows 10 systems without admin rights. For systems where the end users do have admin rights, check out my new blog which includes AirWatch 9.3 agent enhancements.

​​
AirWatch has the ability to silently enroll Windows 10 systems using command line parameters on the AirWatch Agent msi. You can use SCCM to deploy the AirWatch msi to your Windows 10 systems to automatically enroll them into AirWatch without any user interaction. 

Note: If you look at the dropdown by "Single User Devices" setting, it might make sense to change it to "Advanced", but this actually needs to stay as "Standard". I'm not 100% why on this but this is what the Product team has told me. 
4. Click save and this account is ready to go.

Deploying a PowerShell script with AirWatch is extremely simple. In this blog I'll detail how to do it with the "Product Provisioning" component of AirWatch, but this can be done via "Software Distribution" (aka Apps and Books) as well. 
First, navigate to Devices--> Staging & Provisioning --> Components --> Files/Actions.
Then click the "Add Files/Actions" button at the top.

Select "Windows", then "Windows Desktop".
Fill out the Name and Description. Verify you have the correct Organization Group (OG) in the "Managed by" field.
​In my example, I have a script to disable UAC.

Click the "Files" tab and the top and then "Add Files".
Browse for your PowerShell script.

If you use lgpo.exe to deploy a local group policy "pack" to your client machines, you've definitely run into the need to make changes later. You can certainly makes changes to your reference machine, take a new backup, and re-deploy the whole thing to your client machines but that means you are re-deploying every setting you have configured. This makes it a little more impactful to the client due to the number of changes you are re-configuring as well as the fact that older versions of Windows 10 are not compatible with lgpo backups made on newer versions. Here is a way to simply change one or two changes to your client machines without having to re-deploy the entire LGPO pack.  

1. Ensure you have downloaded lgpo.exe from MS's website here
2. Copy to a folder. I'll use C:\Temp
​3. Open cmd prompt as administrator and change directory to c:\Temp
4 Make any changes to local group policy via gpedit.msc
5. Take a backup by running this command:
​lgpo.exe /b C:\Temp /n "Backup"

6. This exports the LGPO into a folder with a GUID. I would recommend re-naming to something easier. Example, "LGPO_Backup"
7. Now you are going to want to parse this backup into a text file.
LGPO.exe /parse /m C:\Temp\LGPO_Backup\DomainSysvol\GPO\Machine\registry.pol >> C:\Temp\​lgpo.txt

Windows 10 version 1703 (Creator's Update) brings the addition of the Office CSP for easy deployment of Office 365. Here's are the steps on how to deploy it to your AirWatch managed Windows 10 system. Thanks to @josuenegron for providing the foundation for this here.

Go to the Office XML creator tool and create your deployment XML. Here's what my XML looks like:
​<Configuration>
  <Add OfficeClientEdition="64" Channel="Broad">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="Project" />
      <ExcludeApp ID="Visio" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" Channel="Broad" />
  <Display Level="Full" AcceptEULA="TRUE" />
  <Logging Level="Standard" Path="C:\VMware_IT\Logs\Office365logs" />
</Configuration>
 
Now you will need to take this XML and "serialize" it so that it can be read by the Office CSP.  You can go to this free web page to do so. Simply copy/paste your XML in the top box to get the serialized output.

Create a basic AirWatch profile and add a new "custom settings" section. Take this XML structure and add your serialized office XML in between the "Data" tags.
<Exec> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/Office/Installation/0AA79349-F334-4859-96E8-B4AB43E9FEA0/install</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> </Meta> <Data>​pasteyourxmlhere</Data> </Item> </Exec>

So with everything added, it will look like this:
​<Exec> <CmdID>2</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/Office/Installation/0AA79349-F334-4859-96E8-B4AB43E9FEA0/install</LocURI> </Target> <Meta> <Format xmlns="syncml:metinf">chr</Format> </Meta> <Data>&lt;Configuration&gt;
  &lt;Add OfficeClientEdition=&quot;64&quot; Channel=&quot;Broad&quot;&gt;
    &lt;Product ID=&quot;O365ProPlusRetail&quot;&gt;
      &lt;Language ID=&quot;en-us&quot; /&gt;
      &lt;ExcludeApp ID=&quot;Groove&quot; /&gt;
      &lt;ExcludeApp ID=&quot;Project&quot; /&gt;
      &lt;ExcludeApp ID=&quot;Visio&quot; /&gt;
    &lt;/Product&gt;
  &lt;/Add&gt;
  &lt;Updates Enabled=&quot;TRUE&quot; Channel=&quot;Broad&quot; /&gt;
  &lt;Display Level=&quot;Full&quot; AcceptEULA=&quot;TRUE&quot; /&gt;
  &lt;Logging Level=&quot;Standard&quot; Path=&quot;C:\VMware_IT\Logs\Office365logs&quot; /&gt;
&lt;/Configuration&gt;</Data> </Item> </Exec>

Take that and paste it into the custom settings area of your AirWatch profile.

Click save and publish. After a short time you should see the Office install window popup. I would highly recommend you make the display level "Full" so you can see whats happening as well as specific a log path so you can easily troubleshoot installation issue.

In this blog post, I will outline how to forcefully but elegantly upgrade remote systems to Windows 10 using SCCM task sequences. I will be using 3 task sequences working together to accomplish this. This process can also be used for clients on the LAN as well as for win10 feature upgrades. The main benefits of this process are as follows:
- All content gets pre-downloaded silently in the background
- Win10 assessment is run silently before hand and sends email based on pass/fail
- If it passes, a reg key will be created with which an SCCM compliance rule can be queried. Systems with the reg key can get automatically placed into a "Win10 Ready" collection.
- The real upgrade Task Sequence can be deployed manually or automatically to systems in the "Win10 Ready" collection
- A nice window will popup on the real upgrade TS which allows users to defer the upgrade up to 5 times before it will run automatically
 - Model specific drivers are pre-downloaded as well

Pre-Reqs
- Clients must be on a reliable VPN connection in order for this to work well. We have an "always on VPN" that connects so remote clients are always on the VPN unless the user manually disconnects.
- Because this is a lot of content going over your VPN, be mindful of the bandwidth impact. We use Adaptiva for content distribution and it takes care of all of the bandwidth management automatically for us so there is no load placed on our VPN gateways. 
- While you CAN include the MBR2GPT process to this, I would recommend against it. This is simply because if there are any issues you're gonna get a system that won't boot. Troubleshooting that remotely is a huge pain and a poor experience. Just flip them to UEFI once they visit a real office.
Downloads

In my previous post I detailed how you could use an SQL query on the SCCM database to pre-register airwatch devices into the console. While this works, it has several drawbacks:

• Running the SQL query is manual and only represents a point in time. Users will change systems, new systems will get ordered, and systems will be decommissioned, etc. You will have to regularly upload the data to ensure it's accurate.
• If you run the Airwatch agent install on a system that does NOT have a pre-registration it causes it to be in a "limbo" enrolled state. It will show enrolled in the console but it will still be enrolled as a staging user and no profiles will comes down. This can then require manual deleting of the object from the console.

With those limitations I was looking for a better and more automated way to do this. Thankfully, Chase Bradley on code.vmware.com created a method that cleverly uses Airwatch REST APIs to automate this process and dynamically pre-register devices at the time the script runs. This completely takes away the need to have a csv export/import process. Check it out here. I took those concepts and made a Powershell only version and included a few other modifications. A big thanks to Chase for laying the foundation and well as help on understanding Airwatch APIs. Disclaimer: Even though this script obfuscates the AirWatch credentials on the client, it is not 100% unbreakable. Running API on the client has some security risk associated to it. Use at your own risk. To truly secure this you would have to setup a web-service to store the actual creds and do the API calls so that they are never exposed on the client. 
My script has the following features:

1. It's entirely written in powershell leveraging the Invoke-RestMethod to make the calls directly to the airwatch console. Don't be too worried if you don't know REST API, it's pretty easy to learn. I didn't know it at all before I wrote this script and it took me an afternoon to learn and build into the script.
2. Runs a check on the system to validate enrollment and only runs if the system is not properly enrolled.
3. Deletes stale/invalid records from console, pre-registers device based on serial number and username, and then enrolls silently -- the user will not notice or see any activity. 
4. Has logging enabled both locally and to a central server.
5. Emails success/fail email to you so you can track your progress and proactively remediate clients if there are issues. 

1. API Enabled on Airwatch console
2. Script must be run as the logged in user and the user must be a local administrator
3. Windows 10 only
4. Airwatch version 9.2 or higher

Managing encryption on Windows 10 devices in the new mobile-cloud era should be simple and effortless. AirWatch 9.1 gives us a slew of features for advanced BitLocker management on your Windows 10 devices that makes it easy and flexible. I’ll highlight some of the new features introduced in 9.1 and then do a walk-through of how to set it up.
(taken from official AirWatch post)

1. Encrypt just the used space initially.
   This gives speeds up the time it takes for Bitlocker to complete encrypting the disk.
2. Set a custom URL for users to grab the recovery key themselves.
   Set this to your AirWatch self-service portal for easy recovery by your end users.
3. Suspend BitLocker during scheduled maintenance windows.
   This allows you to suspend BitLocker during certain windows of time when you apply OS or BIOS updates so that the system does not enter recovery mode. A good example of this would be with Kiosk devices; you want to update them all over night and have them ready to go in the morning without someone coming in and seeing the blue recovery screen.
4. Allow for PIN + TPM rather than just one or the other.
   This just adds an additional layer of security to your devices.
5. Use a password if no TPM is available.
   Ensures that every system is encrypted even ones that don't have a TPM chip either because they didn't ship with one, it hasn't been activated yet, or there are country specific laws preventing TPM chips.
6. Setup a “Shared” Bitlocker key among all your devices that rotates at a specified window. This makes it easier on your support teams to have one key for all devices. The individual keys still remain on the system, but this adds a 2nd “administrative” key that is synchronized.

Now, let's get to creating your profile in the AirWatch console.
First, login to your AirWatch admin console
On the left hand pane, click on Devices --> Profiles & Resources --> Profiles --> Add --> Add Profile

Then Windows--> Windows Desktop

Then select Device Profile

In the Profile screen fill out the first section -- "General"
Name - Name it something appropriate, such as "Win10 - BitLocker"
Description - Optional, but a good idea to type a bit of a description on what this profile is going to do.
Deployment - "Managed"
Assignment Type - "Auto"
Allow Removal - Recommend you set this to "Never"
Managed by - You should be able to leave this default, but be sure you are at the right org level here
Assignment Groups - Add the appropriate group here. If you haven't created a Smart Group yet you can do so here. Just click in the box and select "Create Assignment Group" at the bottom. In my case I've created a smart group for all Windows 10 Clients
Exclusions - You can add exclusions here if you want
Additional Assignment Criteria - Leave default
Removal Date - Recommend you don't enable this
You can see mine here:

Once you have configured your "General" page, click down to the "Encryption" section on the left.
Then click "configure".
Here there are numerous different options you can set. I'll walk through each one although many are self explanatory. 
Section 1
Encrypted Volume - Select "Complete Hard Disk" or "System Partition". System Partition means just the OS partition, so it won't encrypt any other disk or partitions. Recommend you set this to "Complete Hard Disk".
Only Encrypt Used Space During Initial Encryption - This will speed up the initial encryption process and not hit the disk as long. Recommend you turn this on.
Custom URL for Recovery Screen - This is where you put your unique URL that will direct users to go to on the blue BitLocker recovery screen. I recommend you set this to your organization's Airwatch self service portal.

Section 2 - BitLocker Authentication Settings
Authentication Mode - TPM or Password (aka PIN). TPM is definitely the way to go here.
Enforce Encryption Pin on Login - Check this box if you want to add a PIN in addition to TPM. This is not really necessary in my opinion, but it does give you the option if your organization requires it.
Use Password if TPM not Present - As mentioned in the beginning of the article, this really helps ensure that every system is encrypted even ones that don't have a TPM chip either because they didn't ship with one, it hasn't been properly enabled, or there are country specific laws preventing TPM chips altogether. Recommend you turn this on otherwise Bitlocker will fail if TPM isn't there and activated.
Minimum Password length - Self explanatory. Minimum 8 characters.

Section 3 - BitLocker Static Recovery Key Settings
Create Static BitLocker Recovery Key - This is also a new feature with 9.1 where it will add a secondary admin recovery key that is synchronized across your devices for easier recovery. This still keeps the unique key that is set, but it just adds a second one.
You can also set the rotation period and grace period here too.
​
Section 4 - BitLocker Suspend
Enable BitLocker Suspend - If you check this box, it will automatically suspend BitLocker during scheduled maintenance or patching periods so that the system won't automatically go into recovery mode such as updating the BIOS. Most of the time, this would probably be used on Kiosk or desktop systems where you have very predictable maintenance periods and where there is a risk of BitLocker going into recovery mode.
Recommend you leave this off unless you have a specific use case. You can always turn on for a time, and then turn off once you are done updating your systems.

Once you are complete and ready to deploy click "Save & Publish". The next screen will show you all the devices it will go to based on your Smart Group.
If it looks good, click "Publish" to send out to your devices.

Once you have deployed this out to your devices, obtaining the recovery key is very easy. Simply search for and find the device either by user or device name.
On the summary page, click on "View Recovery Key". That's it!