Auto Provisioning Windows Devices with JumpCloud

Before We Start

The Problem I'm Trying to Solve

To provision Windows devices in a modern way:

• Without signing up with Intune, and the MSFT enterprise subscriptions.
• Provide an open-the-box experience for onboarding remote co-workers.
• Archive a liteTouch / ZeroTouch Windows provisioning experience for the IT folks - to save precious man hours.
• Enforce the security policies and push the managed software with full transparency (to the end users) on d-day.

You will need:

• A Window 10 / 11 installation media.
• OR a MDT image.
• A JumpCloud tenant - free for 10 users.
• A workflow automation tenant. Such as:
  • Make.com - Exported blueprints can be found in Make blueprints folder.
  • n8n.io - Exported workflows can be found in n8n folder.
• (Optional) An Image distribution channel, for an open-the-box experience, and the benefit of pre-installing the drivers by the manufacturer:
  • Dell - Image Assist (FKA: Dell Factory image), you can submit either a full image or just the autounattended.xml to Dell.
  • Lenovo - Custom image (Untested, an enterprise account is needed according to this)
• An autounattended.xml (Windows answer file) with desired configurations. You can get it in various ways:
  • Use my example here.
  • Use Windows Answer File Generator.
• The traditional and official path, Windows System Image Manager.

Getting Started

A. Setup the workflow engine to secure your JumpCloud device enrollment connect key and API keys.

On a high level, the 3 workflows will do:

• Securely distribute the JumpCloud device enrollment key to a validated user.
  • By validating the user's email and pre-assigned enrollmentPin.
  • Rotate the enrollmentPin once obtained.
  • The enrollmentPin can be sent to the user as part of the onboarding process, especially for remote co-workers.
• Bind the user to the device on JumpCloud.
• Add the device to the designated device group on JumpCloud, thus on day 1:
  • A set of security policies can be applied.
  • System patch policies can be enforced.
  • A set of (managed) software will be installed.

Option 1 - Using Make.com

1. Import the blueprints in my repo.

2. Setup Scenario jcGetConnKey:

   • Create a webhook, copy the link, and click on advanced setting to add a data structure:

     

   • Make sure systemKey, newHostname , groupName are added as the items in the new data structure.

     

   • Move on to validateUser web request module, and add your JC API key (ideally a Read-only one.)

     

   • Move on to connKeyData JSON module, create a data structure consists conn_key, email, and user_id, and save it.

     

   • Move on to reGenUserEnrolPinData JSON module, and create a data structure like this:

     

   • Continue to rotateUserEnrolPin module, and add your JC API key - this time with "writeable" permissions.

   • Input your JC connect key as a static value on connKeyData module, and fill in the email and user_id by the data processed from the iterator module :

     • Note You can find the connect key by going to JumpCloud admin console -> Devices -> add Device -> copy the key.

       

   • Check the rest of the modules and fix any errors.

3. Setup Scenario jcSystemBindUser:

   • Similarly to the above - create a webhook, copy the link, and click on advanced setting to add a data structure:

     

   • Move on to userSystemBindData JSON module, and create a data structure:

     

   • Move on to updateSystemData JSON module,and create a data structure:

     

   • Check the rest of the modules and fix any errors.

4. Setup Scenario jcSystemAddGroup:

   • Similarly to the above - create a webhook, copy the link, and you can reuse the data structure created in jcSystemBindUser scenario.

   • Move on to createGroupBody JSON module, and create a data structure:

     

   • Move on to addSysGroupMemberBody JSON module, and create a data structure:

     
     • Note There are two modules named the same, you can reuse the data structure in 1 or the other, and config the same.

Option 2 - Using n8n.io

1. Import the workflow in my repo.

2. Setup Workflow jcGetConnKey:

   • Go to validateJcUser node, create a R/O API Header Auth Key:

     

   • Move on to Respond to Webhook node and key in your connect key:

     

   • Move on to ran_num node, and write a JS code to generate random digits of enrollmentPin.

   • Continue to rotateUserEnrolPin node, and create a W/R API Header Auth.

3. Setup Workflow jcSystemBindUser:

   <WIP>

4. Setup Workflow jcSystemAddGroup:

   <WIP>

B. Change the Webhook URLs in kickstart.ps1

1. Change the URLs respectively created and copied from section A into:

$getConnkey_url = "your own webhook"
$jcSystemBindUser_url = "your own webhook"
$jcSystemAddGroup_url = "your own webhook"

C. Kickstart.ps1 hosting Recommended hosting the kickOff.ps1 in a publicly accessible, and compliant to your security rquirements.

It can be:

• AWS S3 or,
• Azure blob or,
• Github

[Optional] You can self-host main.psm1 too by changing the URL in kickstart.ps1:

$moduleUrl = "your hosted main.psm1 url"

D. Update the kickstart.ps1 URL in autounattended.xml Once you decided and attained the public URL for kickstart.ps1, change the URL in autounattended.xml:

<SynchronousCommand wcm:action="add">
    <Order>4</Order>
    <CommandLine>PowerShell.exe -WindowStyle Maximized -ExecutionPolicy RemoteSigned iex (irm "your kickstart.ps1 url") </CommandLine>
    <Description>wap kickoff</Description>
</SynchronousCommand>

P.S. Re-provsioning

You can place reKickOff.bat onto a USB stick or the same reachable cloud storage as kickOff.ps1 as a backup plan in case the initial provisioning failed.