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.

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!