Now that we have completed the steps in part 1, let's continue with putting together the final pieces:

1. Setup an http CRL location (as opposed to the default LDAP based location) - this is a critical piece!
2. Setup the MS Certificate Authority and WHFB Template in the Workspace ONE console
3. Setup a profile to deliver this cert as well as the Root certificate
4. Basic troubleshoot and how to validate its working

Because your AAD joined Windows 10 device is not joined to the on-prem domain, it will not have the ability to use LDAP to validate the CRL (Certificate Revocation List). The client must be able to validate the CRL for the cert to work. This is so that if you revoke the cert, it will see that and revoke it's use. LDAP is the default CRL distribution point on MS CAs. So we'll need to add (or even fully replace) that location with one that is HTTP. Also, it's best practice to put this externally facing on the web. You can also using OCSP (Online Certificate Status Protocol) for this too, but I won't get into detail on that particular method. I also want to give lots of credit to this blog and this blog for helping me setup the correct CRL distribution points. Check them out for the full background on certificate revocation list distribution points (CDPs)

I'm putting this CPD on the same server as my CA, but it's not required. I'll also show how to setup the basic IIS website for this, but any web server will do as long as the CA has write access to put the CRL files. 

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.

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
Check out my new blog which includes AirWatch 9.3 agent enhancements as that is the preferred way to do enrollment on Windows 10. If that method doesn't work or you prefer to statically assign Windows 10 devices to an OG, then continue reading.  ​​
​
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