Part 1: How to build an 'Auto Pilot scenario' with JumpCloud for Windows

Intro

You might remember my previous article (link) where I demonstrated how you can get secret credentials securely for further processing within a script. This was foundational work to evolve further and develop a proof-of-concept scenario which allows for an almost unattended deployment and enrolment of a Windows-based device using JumpCloud. Lots of pieces from the previous post are used and most enhancements are focussing on the steps needed post-deployment of the Windows Operating System itself with minimal interaction required.

Objectives

The aim here is - as mentioned above - to require only a couple of clicks and very few interactions by an admin (or designated employee) to deploy devices and make them manageable via Jumpcloud as quickly as possible.

Another goal is to keep it modular so that the script can be used in the following scenarios:

• Bare-metal installation of a device by using a custom Windows image
• OOBE with a custom Windows image delivered via Custom Factory Image (CFI)
• A single script to kick-off provisioning via JumpCloud by enrolling the device and assigning a user

Solution

The script mentioned above is the foundation and got enhanced with a couple of steps to achieve the objectives.

Initially I wanted to run this script completely within a Task Sequence while the device is still in the imaging process, but I forfeited this for 2 reasons:

• While the Task Sequence is running, there are some obstacles which making it rather cumbersome and prone to errors.
• The script would need to be more catered and would loose some flexibility for all scenarios

Therefore I decided to run the 'Auto Pilot Script' after the Task Sequence has finished the imaging process. During the imaging process, the script will be placed on the disk and a scheduled task is created which kicks off once the device has rebooted after imaging. I will cover the configuration and setup used (Microsoft Deployment Toolkit) in the next part of this series. Stay tuned for that.

Let's a have a look at the script and what it does in sequence. Some lines/sections will seem familiar as they have been inherited from the previous script (to grab secrets from Azure Key Vault etc).

During development I had to do some debugging all the time, so it was important to have a trace of what's going. So I started the script with a transcript by using:

# Starting Transcript
Start-Transcript -OutputDirectory c:\AutoPilot -Verbose -ErrorAction Continue?        

Make sure there's an Internet Connection available (yes, I'm pinging Google's DNS for that):

# Wait for successful network connection 

do {

? $ping = test-connection -comp 8.8.8.8 -count 1 -Quiet

} until ($ping)?        

While debugging, I learned that I need to ensure a minimum version of NuGet to be present on the system:

# Install Nuget (required version)

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force?        

I also had to ensure that the existing PS Management Module is imported to proceed:

# Import PowerShell Management module, which has all the cmdlets for interaction with WMI

Import-Module -Name C:\windows\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Management?I        

Next we're loading two more modules: JumpCloud PowerShell and Azure Key Vault:

# Install and import the JumpCloud Powershell Module

Install-Module -Name JumpCloud -Force



# Install and import the PS-module for Azure Key Vault

Install-Module -Name Az.KeyVault -RequiredVersion 3.6.1 -Force

# Install-Module -Name Az.KeyVault -Scope CurrentUser -Force -Verbose

Import-Module Az.KeyVault -RequiredVersion 3.6.1?        

All required modules are available now and can be used within the script. Next we will connect to the Azure Key Vault and write the secrets to variables. I'm getting the 'JumpCloud Connect Key' to deploy the JumpCloud Agent later and the 'JumpCloud API Key' to be used with the JumpCloud PowerShell Module to query the System ID, assign the device to a System Group and also assign the user to the device at the end of the process:

# Connect to Azure with the right subscription in use; adjust subscription ID to your own

Connect-AzAccount -SubscriptionId '<Subscription ID>'


# Acquire the JC Connect and API Key and set it as a variable

$key = Get-AzKeyVaultSecret -VaultName 'MDT-creds' -Name 'JumpCloud-Connect-Key' -AsPlainText

$api = Get-AzKeyVaultSecret -VaultName 'MDT-creds' -Name 'JumpCloud-API-Key' -AsPlainText?n        

Now we're able to connect to the PowerShell-Module for JumpCloud to the backend:

# Connect to your JumpCloud-Tenant by using the API-key ($api)

Connect-JCOnline $api -force?        

Ready to get the JumpCloud Agent installed and connected:

# Download and run the latest JC Agent (using $key)

cd $env:temp | Invoke-Expression; Invoke-RestMethod -Method Get -URI https://raw.githubusercontent.com/TheJumpCloud/support/master/scripts/windows/InstallWindowsAgent.ps1 -OutFile InstallWindowsAgent.ps1 | Invoke-Expression; ./InstallWindowsAgent.ps1 -JumpCloudConnectKey $key        

Once this is done, you will see the device being registered on the JumpCloud Admin Console already:

To be able to do the right assignments later, we need to get the System ID. There are a couple of ways, the hostname could be another usable variable, but the serial number seems to be most reliable and unique here:

# Acquire SerialNumber 
New-CimSession

$sn = gwmi win32_bios | select -Expand serialnumber

Write-Output "The SerialNumber: $sn has been acquired and will be used to query the JumpCloud System ID."??        

Once we got the serial number ($sn) successfully, we're able to query the System ID:

# Query System ID via JumpCloud PS Module

$sys_id = (Get-JCSystem -serialNumber $sn | select _id)._id

Write-Output "The System ID is $sys_id and will be used to assign this system to the group 'Onboarding'."        

In the next step, the device will be assigned to a group which we're using for onboarding purposes. Of course, this customisable and you could query a Device Group as well catered to your needs.

This group has already Policies and Software assigned, so once the device is added and ready, this will be carried out to this newly provisioned device.

# Add this device to the designated default System Group used for 'Onboarding'.

Add-JCSystemGroupMember -GroupName 'Onboarding' -SystemID $sys_id?        

Now that the device is basically ready to be used, we can proceed and get a user assigned to it. Simply enter the username at the prompt and hit 'Enter':

# Prompt for username to be assigned to the system

$username = Read-Host -Prompt 'Input the username'

Write-Output "The username: $username has been entered and will be assigned to this system."
        

and

# Assign the user to the device without being an Administrator

Add-JCSystemUser -Username $username -SystemID $sys_id -Administrator $False

Write-Output "All tasks have been completed successfully. The script will now clean up and announce a restart."?        

As you can see in the following screenshots, the device has been enrolled, assigned and is ready for further automated and/or manual provisioning via JumpCloud.

As you can see, Chrome and Slack got already installed via the Software Management capabilities of JumpCloud.

Additional note: the script is - of course - highly flexible: While you're connected via the JumpCloud PowerShell Module, you could trigger much more actions. For example, you could assign Commands to the system to be executed.

Finally, we will do some cleanup steps. The scripts shall be removed from the system and the Scheduled Task isn't required anymore as well:

# Delete scheduled task

Unregister-ScheduledTask -TaskName "JumpCloud Auto Pilot" -Confirm:$false


# stop the transcript if still present while debugging

Stop-Transcript


# Cleanup files on C:\

Remove-Item C:\AutoPilot\*.* -Force?        

In a last step, you can - if desired - let the device restart. Once done, you will see the assigned user at the logon screen already - which means you're good to go, you can handover the device to the actual user.

# optional

Pause

Restart-Computer         

Notes

As usual, some notes at the end:

• This script was executed via Scheduled Task on a newly imaged device. How to do that: stay tuned for the next part of this series.
• This is a basic script as a proof of concept. To be more suitable and ready for production, it will require some better error-handling and robustness. For example, in some occasions the serial number was not queried and left me with an empty and unusable string.
• Knock yourself out. This article is meant for sharing and as an inspiration. Feel free to use any code snippet here for your own purposes and customisations.