Special Note

This document is in draft form and is lacking screenshots or more in depth steps. Please provide any feedback at the bottom to help me make this better. Thanks!

Outline

Preface
What is Operating System Deployment
History – Breakdown of the manual steps

Make a bootable lightweight OS

Format the drive
Setup the OS
Segway – The OOB Process
Customize the OS
Ready to go
Philosophy
Keep it simple, stupid
General CM Management Strategy
Software
Simple Modular Task Sequence
Keep it updated often
Deploy apps as a service post imaging
Building the first task sequence
Breakdown of the basics
Digging in and building one
Make sure your boot images are working / customize them
Customize the boot image(s)
Import Operating System Image
Create an Unattended XML File to answer OOBE questions
APPX Removal Package
Driver package for your target machine
Create a Task Sequence
Additional Customization
Deploying the Task Sequence
Distribute the Content
Side note on Prompting for Computer Name / Unknown Computers
To Prompt for a Computer Name
To set a known BitLocker key during OSD before it’s rotated by AD
Testing

Preface

I’ve been working on this e-book for a long time and it’s gone through a lot of revisions. After talking to my co-worker I decided it was time to re-write this whole chapter and maybe revisit others. We were out for a walk and he started talking about how can anyone has a chance coming out of high school or college these days in IT. He went on to explain that there is a long, deep history of everything and a background on why we’re doing what we are which isn’t implicitly obvious. He knows what we’re doing and what it does but not the WHY we’re doing it. So I’m hoping to add that element to this to give more of an understanding going forward.

What is Operating System Deployment

Operating system deployment is essentially the automation of installation and configuration of computer operating systems. Way back in the 1990s we may have done it a little different – either manually sitting down at each machine and going through a checklist, or doing this once and then literally cloning the machine to other, identical hardware. It was tedious, as we’ll get into in the next section, but there wasn’t any other way to go about this. Sure, there was SMS and Ghost (for cloning machines) but both had their issues which I wont get into here.

History – Breakdown of the manual steps

As mentioned before, we’ll get into the high-level overview of doing everything manually. I’ll get into why this is important next under Philosophy, but I always find it helps to break things down into bite size steps to fully understand what we’re doing.

Make a bootable lightweight OS

When you sit at a computer out of the box you may wonder why we’d need to make a bootable operating system (of any kind) to deploy an Operating System (OS) to it. Problem is if the OS is working, typically it wont let us kick out the storage under it and wipe the drives so that’s one reason. The other reason is maybe obvious in hind sight – what if the OS on the machine won’t boot and that’s why we want to image it?

In general sense we’re making a bootable, non-dependent environment to start installing an operating system to a target computer.

You may have done this and not even realize it — making a Windows USB drive (or DVD?) actually includes a boot loader and lightweight OS called Windows Preinstall Environment (WinPE) which is why the manual setup process of Windows looks and feels familiar.

Format the drive

Now that we have an operating system, we need to clear and prepare the drive to receive a new OS. The bootable OS we made in the previous step generally has built-in tools to manage disks including clearing all of the disk partitions and creating new ones in the layout we need, plus format them with the file system the new OS will need to function properly.

Setup the OS

Once the drive is ready, we usually would launch the operating system setup. Here you may have done this by hand – you start something like setup.exe and next through until the operating system kicks off the install.

Newer installers may have options to prepare the disk (and I mean anything in the last 20+ years as newer). Once the install starts, what the setup process is doing is actually quite simple – its copying files from the install source to the hard drive. Usually the only other thing it’ll do is flag the drive as bootable and install a bootloader – a small program that kicks off the OS load that the computers BIOS understands is bootable. Thats how when you turn your computer on, it can boot.

You may be thinking – no, a lot more has to happen, right? Not really. Windows installers just copy a bunch of files to C:\ and some bootloader files to a boot partition and then the setup is complete. The temporary, cut down OS we ran setup with (even if you boot off a USB drive or DVD – this is still there, its a lightweight Windows called Windows PE or Preinstall Environment – we’ll get into that later) is done. The installed OS boots, and then does its out of box (OOB) routine.

Segway – the OOB Process

Once Windows setup is complete – the files are copied, the boot loader is installed, Windows will go into its out of box routine.

What this phase does is also pretty simple. Windows has a catalog of drivers it comes with that it’ll use as it goes through all of the new computers hardware. (Hopefully) If it finds matching drivers in its driver store, it’ll install those drivers. This usually is proceeded by a reboot.

Once the drivers are installed, Windows will jump into the OOBE or Out Of Box Experience. OOBE is that full-screen wizard that shows up when you unbox and turn on a new computer, or what you run into before you can log into the computer the first time. It asks some general questions:

Do you want to join a wireless network
Keyboard, language, and time zone
General Windows Options
Do you want to join the computer to a domain (Pro and above) or use a cloud account

Once you answer these questions – you can log into your computer. Setup is complete.

Customize the OS

Once you log into a computer you may have some post install setup steps that you generally want to do. Maybe you don’t want the search bar on the task bar. Maybe you want to remove In-Box apps like XBOX Game Bar since a lot of people don’t like these on their business computers. You may install some software such as Office or Adobe Reader — and configure them the way you’d like. This is the customization steps we’ll consider.

Ready to go

This is the setup process if you sat down and installed a computer by hand in a nutshell. An end user in theory could sit down and start working.

Philosophy

I wanted to cover the basic management philosophy here since a lot of what I’ll be covering hinges on that. I’ll cover the high level overview of what and then get into the why of everything in detail.

Keep the task sequences as simple as possible
Only include software and drivers we absolutely need
Automate software packaging as much as possible
Deploy software that’s unique to groups of machines AFTER OSD
Deploy updates after the OSD so everything is updated
Automate user experience as much as possible

Keep it simple, stupid

This one I heard long ago and it really has stuck with me. Back in the day I mentioned the first phase of automation was to build a golden computer by hand, then to clone it to identical (and later, really similar) computers and this was the way we did things. This is a pain to do – you have to keep a spare machine for every model or group of computers and build them out to keep the imaging updated.

Later when ConfigMan took off more, in combination with Virtual Machines, this got better – we could automate it, but it seemed like it was a lot of wasted time, troubleshooting, and felt super clunky to me.

There were reasons to have a golden image in SCCM (at the time) such as large installers were nearly impossible to deploy so you’d be stuck deploying them with the OS.

Today, I reject the ideology of a golden or master image. We can do better.

Instead, we break down what we’d do manually, and make each individual step work, then put it all together. This is how I go about tackling any problem I run into and it hasn’t let me down yet.

General CM Management Strategy

I covered this somewhat before but its worth going over the general setup we’ll be running for this guide.

Software

Software is automated as much as we can. If I had more time I’d automate it more, or alternatively you can grab a product like PatchMyPC and it’ll do a lot of this for you.

We have a template folder with a customized PowerShell Application Deployment Toolkit. When packing applications, we grab a copy of this and fill in the blanks. We’ll install any dependencies here such as VC++ Runtimes, and test it out. Once its ready, we’ll run a script I wrote to automatically:

Check to make sure the application folder path is correct
Handle a quirk with CM PowerShell for Application ‘icons’ — resize the PNG file in the template to work
Build the application out (and optionally a version for OSD)
Build deployment types out to handle user logged in and out (I don’t think this is needed anymore, but there were issues a long time ago and change is hard)
Distribute the app to our Distribution Points
Create a Computer Target Collection
Deploy the software as required to the collection

We’ll cover this in more detail in the chapter for application building along with why we’re doing this, the benefits, cons, etc. But for now, this allows us to deliver a consistent experience to the end user and keeps app deployments super simple and uncomplicated. It also allows us to flag an app for OSD and it’ll build a version for that. It also works great for some of our automation tools to build new computers based on existing ones, and machine replacement.

Simple Modular Task Sequence

My task sequence design is to keep it as simple as possible. Reusable items are broken into their own task sequences so I can use them for other task sequences (more on that later, but for now assume we will have ONE task sequence for everything.)

We will use stock Microsoft Windows images with zero customization (well, unless our security department wants something patched specifically.) We’ll use OEM driver packages. We’ll only include applications everyone in the ORG needs and nothing more. We’ll also customize only the bare minimum and let the user handle the rest.

Keep it updated often

Since the design is simplified. it lets you swap parts out as you update them. Applications can just be swapped out and away you go. Same thing with drivers. Need to update the Windows image? Chances are you can download an updated Windows OS for the last month on Volume Licensing Service Center (VLSC) and drop it into CM and just swap that out in the task sequence, too.

Need a whole new build of Windows, or are going from Windows 10 to Windows 11? We just copy the existing task sequence and swap the OS out and for the last ten years, this has worked flawlessly. Given, you may have a few things you need to tweak but other than that, it should just work.

Deploy apps as a service post imaging

I wanted to reiterate that we deploy all needed applications post OSD. This is handled by the desktop technicians. They can look at what collections a similar user is, or the same user if we’re doing a replacement, and toss the new machine into those and the software will deploy. This lets us have one task sequence to rule them all. As mentioned, we have started automating that and I plan on releasing a re-written version of the tool to do this later.

Building the first task sequence

Now that we’ve gotten a background on what, how, and why we’re doing things the way we are, lets dig in and make it all work.

Breakdown of the basics

We’ll be building a task sequence that does the following; none of this should be any surprise but there may be some new steps I haven’t mentioned, which we’ll explain:

Somehow Boots the computer into Windows PE (Our Lightweight Boot OS)
Clears the disk drive and prepares it for Windows
Copies Windows files, including boot loaders (Installing the OS)
Something new – Copies drivers into the Windows Driver Store so our fancy new machine has updated, OEM specific drivers for us to use
Answers the Out Of Box Experience questions for us (The Answer File)
Optional (Not covered in this section since it deserves its own) update the system firmware
Lays down org-wide applications
Customizations to the machine
Enabling BitLocker
Installing and doing basic LAPS configuration
Flipping registry keys so the first login experience is what we want
Flipping registry keys so that the core org wide apps are configured properly before any compliance or group policy can fail us — such as auto log into OneDrive or Outlook
Remove In-Box apps that we don’t want

I will note that some of this is changing, and I’ll probably swap out how some of this is done or remove some of it as management of devices changes. An example of this is the driver management. Today, we just use CM Packages to copy files over and then DISM to inject them into the Windows Image before it can do first-boot driver install. In the future I’d love to swap this out for Cloud OSD or Windows Update to grab drivers beyond the network cards and is always up to date. Both options also now let you update system firmware which is another reason I wont cover that in detail in this chapter.

What is needed in Configuration Manager to do this:

Working Boot Images
A Task Sequence
A Package with an Answer/Unattended XML File
An Operating System Image
A Package to house our OEM Drivers for each model
A Distribution Point with PXE Boot Enabled

Digging in and building one

Lets get started (finally!)

Make sure your boot images are working / customize them

By default if you completed the LAB setup guides from before, or have a working CM environment that already is deploying Operating Systems, you should have working boot images and we may not need to do anything here.

Boot images are located under Software Library > Operating Systems > Boot Images

Here you’ll find (typically) a separate boot image for 32-bit and 64-bit systems:

32-bit: Boot Image (x86)
64-bit: Boot Image (x64)

These days you’ll likely never use the 32-bit image, and we can focus on the 64-bit. Below I’ll detail what customizations I make to the image, why, and why I usually don’t inject drivers into it.

Customize the boot image(s)

Right click on the Boot Image (x64) and choose Properties
Here, navigate to the Customization tab
In this section, typically the only thing I’ll customize is enabling Command Support. This is at the bottom of the screen and is enabled by checking the box. This allows us to get a command prompt during Windows PE and can be useful for troubleshooting. It does run some risks if you enable it on a user-facing deployment, so keep that in mind
Next I enable some optional components (Optional Components Tab) so that we can run things like PowerShell during the task sequence. This is optional for us too, as it wont be needed to deploy an OS, but gives us the ability to use some tools later on.
1. Optional Components tab
2. Click on the orange splat (star) in the middle of the screen
3. Search for ‘PowerShell’ and tick the boxes next to the three components that show up
4. Click OK when prompted and then OK out of the Select Optional Components window
5. OK out of the Boot Image Properties
6. You’ll be prompted to update the distribution points now – choose yes and wait for it to complete
Thats it, the image is customized.

Import an Operating System Image

We’ll assume you’ve logged into Volume Licensing Service Center (VLSC) and downloaded the newest version of Windows 10 (in this example Windows 10 21H2 Update 6 or May 2022, 64bit, English — but it’s specific to what you have and want to deploy.)

Download the most current Pro, Education, or Enterprise Windows image you’d like to deploy. These are now updated monthly so you should go ahead and get the most updated version.
Mount the image by double clicking it.
Create folders on your CM site
1. \\server\Sources\Operating Systems\Windows 10\Enterprise\21H2.6\x64\ISO
2. \\server\Sources\Operating Systems\Windows 10\Enterprise\21H2.6\x64\WIM
Copy the complete contents of the ISO to the ISO folder
Copy the wim file from \sources\install.wim to the WIM folder
Open the CM Console and navigate to Software Library > Operating Systems > Operating System Images
Choose Add Operating System Image under the create section on the ribbon
Data Source:
1. Browse to the newly copied WIM file under Path:
2. Check the box to extract the specific index (This keeps it organized and can shrink the image size a little)
3. Choose the Image Index (I chose the one for Enterprise)
4. Fill out the rest appropriately
5. Click Next >
General
1. Name: Windows 10 Enterprise (x64) 21H2.6
2. Version: 21H2.6
3. Click Next >
Review the summary. Click Next >
Wait for the wizard to complete then click Close

You’ve imported the OS. Congrats.

Create an Unattended XML File to answer OOBE questions

This part is a little tricky. This file is essentially giving answers to the out of box questions automatically so the technician or end user doesn’t have to answer them. You’ll want to tweak this if you’re looking to do AutoPilot since it needs OOBE and we’re going to be skipping that. I’ll admit that I haven’t found a great guide on how to make these XML files from scratch myself, so I cant pass that along — but I’ll revise this section when I do so you can understand it better. Essentially just know that this file works with Windows 10/11 at present.


<?xml version="1.0" encoding="utf-8"?>

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<settings pass="oobeSystem">

<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22%3E

<OOBE>

<HideEULAPage>true</HideEULAPage>

<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>

<HideOnlineAccountScreens>true</HideOnlineAccountScreens>

<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>

<HideLocalAccountScreen>true</HideLocalAccountScreen>

<ProtectYourPC>1</ProtectYourPC>

</OOBE>

</component>

<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22%3E

<InputLocale>en-US</InputLocale>

<SystemLocale>en-US</SystemLocale>

<UILanguage>en-US</UILanguage>

<UserLocale>en-US</UserLocale>

</component>

</settings>

</unattend>

Create a new folder
1. \\server\sources\Packages\Windows Unattended\
Create a new text file in that folder and paste the above code into it
Rename the file to be Unattended.xml
Open the CM Console and navigate to Software Library > Application Management > Packages
Click on Create Image in the ribbon
Package
1. Name: Windows Unattended
2. Check ‘This package contains source files’ and point to the new folder above
3. Click Next >
Program Type
1. Choose ‘Do not create program’ and click Next >
Review the summary and click Next >
Click Close when the wizard is complete

You now have an answer file for Windows Installs

APPX Removal Package

This allows us to run a PowerShell script that de-provisions any APPx (Windows Store) apps that aren’t on a whitelist.

You can find this file from my GitHub, here: https://github.com/hypercube33/SCCM/blob/master/RemoveAPPXv5.ps1

Create a folder on your CM Server Share; \\servername\sources\Packages\RemoveAPPX
Copy the file from my GitHub to this folder
Open the CM Console
Navigate to Software Library > Application Management > Packages
Click on Create Package in the ribbon
Package
1. Name: Remove APPx In-Box Apps
2. Check ‘This package contains source files’ and point to the new folder above
3. Click Next >
Program Type
1. Choose ‘Do not create program’ and click Next >
Review the summary and click Next >
Click Close when the wizard is complete

Driver package for your target machine

I wont cover this in this section in detail since I have a whole chapter on doing this step by step, and it also varies by model, and sometimes you just have to make your own driver packages by dumping drivers from a working machine. Essentially you’ll just download a driver CAB file or Self-Extracting ZIP file or use a tool to make this on the fly, but you’ll be left with a folder that has all of the drivers for a specific model.

You’ll also need to get a WMI query to identify the machine and model so we can run a driver copy step in the task sequence for ONLY that model while skipping the rest that don’t match.

Once the drivers are copied to a folder, we’ll use the built-in DISM command to inject them into the fresh Windows image before we go to boot it the first time during the task sequence.

Why not use SCCM’s drivers?

because it creates an absolute mess. Its also super slow, and its like a box of chocolates – you never know what you’re going to get. My advice is to avoid it at all costs.

Create a Task Sequence

Finally, the good part. Making the task sequence.

Open the CM Console
Navigate to Software Library > Operating Systems > Task Sequences
Click on Create Task Sequence on the ribbon
Choose ‘Build and capture a reference operating system image’ — yes, I know I have a whole section about not doing that — but it has the ground work in place to deploy an OS and we’ll just re-use that.
Click Next >
Task Sequence Information
1. Task sequence name: Windows 10 Enterprise (x64) 21H2.6 – Wipe and Load
2. Boot Image — Choose the x64 boot image
3. Click Next >
Install the Windows operating system
1. Image Package: Choose the 21H2.6 image from above
2. Image Index: this should be 1, but if you chose to not extract an index to its own image, you’ll have to pick the right one here
3. Product Key: you’ll want to DEFINETLY put this in from your VLSC portal
4. Randomly generate the local administrator password and disable the account (I highly suggest this since every machines admin user has the same hash — we’ll make a new one in our TS)
5. Click Next >
Configure Network
1. Choose ‘join a domain’
2. Pick your domain from the list
3. Pick your Domain OU — DO NOT use the Computers OU as its not an OU but a different kind of container. Make one if you havent in previous steps or setup will fail!
4. Select your domain join account. This should be a specifically created user that has delegated permissions to join machines (NOT a domain admin!) — make sure to test it with the dialog in this section to verify it
5. Next >
Install the configuration Manager client
1. Package — use the pre-selected default
2. Installation properties: Here customize the below to match your environment.
  /skipprereq:windowsupdateagent30-x64.exe SMSCACHESIZE=20480 /noreboot MP=LAB-SCCM.lab DNSSUFFIX=lab
  1. SkipPreReq – this skips an old prereq that was required and checks. Probably not needed anymore
  2. SMSCacheSize – this sets the CM Cache size to 20GB since we have some hefty apps and its good to have this bigger
  3. NoReboot – this tells it to not force a reboot
  4. MP – this is your management point’s Fully Qualified Domain Name (FQDN)
  5. DNSSuffix – this is the DNS suffix for your network
  Note – there are more commands and you can look them up here: https://docs.microsoft.com/en-us/mem/configmgr/core/clients/deploy/about-client-installation-properties
Include software updates
1. Do not install any software updates
2. Next >
Install applications — here you can add your common-to-every-machine apps or leave it blank and we can replace it with an app task sequence that does the same thing. Click Next >
System preparation – Click Next >
Image properties – Click Next >
Capture Image – Put in a path to any folder in your sources or make a new one called Capture and point there — we wont be using this. Set any domain account. Click Next >
Summary. Review. Click Next >
Wait for the wizard to complete. Click Close.

You now have a basic ‘Build and Capture’ task sequence. We’ll edit this to just do a wipe-and-load deployment now.

Here is an overview of what we’ll customize, and why:

Add a variable to track drive partition letters
Tell SCCM to always image to C:
Remove the Capture steps
Setup the Out of Box customization / answer file
Change the steps for driver install to use a more streamlined approach
Setup BitLocker and LAPS with a newly created Admin user

Right click on your new task sequence and choose Edit.
Highlight the folder ‘Capture the Reference Machine’ and hit Remove at the top of the tree\

You're now left with a plan as can be, but probably workable deployment

Click on the folder ‘Build the Reference Machine’ and over to the right, change its name: ‘Install Operating System’ – Now its more descriptive.\

Note: Groups/folders are just human friendly objects – they allow you to group steps. Optionally you can put run conditions on them to dynamically run or not run depending on conditions you can set.

Customize the Partition Steps
1. We’ll be telling the task sequence to store the randomly assigned drive letter for the Windows partition into a variable. This is like you writing it down so you can recall it later
  1. Select ‘Partition Disk 0 – BIOS’
  2. Here you’ll see that its cutting the drive 0 disk into 3 partitions. One of those below is listed as ‘Windows (Primary)’
  3. Select the Windows (Primary) Volume from the list. Right click and choose Properties
  4. At the very bottom there is a variable box. Here put OSDisk — it’ll save whatever drive letter Windows PE sets this to when its creating it. We don’t really care what it is, but we’ll need to know it. This is specifically useful to make sure Windows goes to the right partition, on the right disk (in the case you have machines with many disks, for example)
  5. Click OK
  6. Repeat the steps for the Partition Disk 0 – UEFI.
Note that it has an additional partition for UEFI booting
Add a new step to the task sequence — tell it to ignore whatever the drive letter is of our OSDisk partition when it boots into Windows. If you’ve done this before, you may have had a case where Windows became D: or E: and good luck changing that after imaging!
1. Click on the Add button above the task tree on the left
2. Choose General > Set Task Sequence Variable
  1. Task Sequence Variable: OSDPreserveDriveLetter
  2. Value: FALSE
  3. Move this step after the Partition Disk 0 steps\
  Note: this sets a built-in variable to tell Configuration Manager to ignore the drive letter, whatever it is, after imaging. This should help ensure Windows thinks its on C:
Pre-provision BitLocker
1. We’ll want to start BitLocker on the drive.
2. Click Add > Disks > Pre-provision BitLocker
3. Move this step below the Set Task Sequence Variable
4. Set it up to encrypt the right partition
  1. Destination: Logical drive letter stored in a variable
  2. Variable name: OSDisk
  1. Customize the Apply OS step
5. Out Of Box / Unattended Answer File
  1. Click on the step Apply Operating System
  2. Check the box ‘Use an unattended or Sysprep answer file for a custom installation
  3. Click on browse and navigate to the package we made for this ‘Windows Unattended’
  4. File Name: Unattended.xml
6. Destination
  1. On the bottom of this step there is a Destination field. We’ll be choosing a Task Sequence Variable for this that we set earlier. Fill in “OSDisk”
Customize Apply Windows Settings
1. Username — this is what Windows is registered to
2. Organization Name: this is the org Windows is registered to
3. Product Key: this is your VLSC product key that should be for the edition you’re deploying
4. Other settings — you can set things like time zone, language — etc. I leave these not specified
Device Drivers
1. Remove the built-in step for this — Select ‘Apply Device Drivers’ and remove this step
2. Add a new folder. Add > New Group
3. Call the new group Drivers
4. Make sure it is located under Apply Network Settings
5. Add at least two steps — one to copy the drivers using a standard CM Package (NOT a driver package) and then a step to run DISM to inject the drivers to the Windows Driver Catalog
  1. Add a new step under the folder/group: Add > Software > Download Package Content
  2. Title this for the specific model of machine you’re targeting
  3. Click the yellow splat (*) and choose the package that acts as a container for the models drivers
  4. Under Place into the following location: choose Custom Path: C:\Drivers
  5. At the top of the task sequence editor, there is a second tab for your Download Package Content step – Options
  6. Here we will set a custom condition that the task sequence will evaluate True or False. If TRUE, the step will run. If False, the step is skipped.
  7. Click on Add Condition and choose Query WMI. Here you can put in a WMI query (I’ll have a whole section with examples of this later) that evaluates true or false. In this example, I’ll target a Lenovo A485. Lenovo for example has these great deployment Recipe Cards that give these WMI queries for each model. You can find them here: https://support.lenovo.com/us/en/solutions/ht104042-think-deployment-center-deployment-recipe-cards
  8. Fill in SELECT * FROM Win32_ComputerSystemProduct WHERE Name LIKE '20MU%' OR Name LIKE '20MV%' — this is essentially asking Windows “Is this machine saying its a model that starts with 20MU or 20MV (% is a wildcard value) and if TRUE, we can copy the drivers for that from the package to C:\Drivers”
  9. Now that the drivers should copy when the model matches, we need to inject them into Windows.
  10. Add a new step at the very bottom of the group/folder – and keep it at the bottom below all of your steps in this Drivers group so its the last step in it; Add > General > Run Command Line
  11. Command line: DISM.exe /Image:%OSTargetSystemDrive%\ /Add-Driver /Driver:C:\Drivers /Recurse /LogPath:%_SMSTSLogPath%\dism.log
6. This is telling DISM to point to the OS drive. Add drivers from C:\Drivers. Recursive means it’ll search every sub-folder in here for drivers and add the *.inf files to the Windows Driver Store. Its also telling it to log to the SMSTSLOGPath ‘dism.log’ for troubleshooting.
Drivers note: You can replace these steps with a nested task sequence later so you can re-use these steps and keep everything clean, once you’re comfortable with nested task sequences. I’ll cover that later
Create a new folder/group to do tasks once the OS is up and running. This section will be once Windows boots, installs its drivers, reboots, and is ready to start taking on applications and settings.
1. Add > New Group. Give it the name Setup Operating System
2. Move the step ‘Setup Windows and Configuration Manager’ into it.
3. If you have it, move the Install Applications step into here as well
Setup Windows and Configuration Manager should be the top of this Group at all times since this is where the CM Client is installed, and you need this to run any further Task Sequence Steps
Create a new admin user and setup LAPS
1. Add > General > Run Command Line
  1. Change the name to ‘Add Admin User’
  2. Command Line: cmd.exe /c net user ContosoAdmin Abc.123 /add /comment:"LAPS Account" /expires:never /fullname: "Contoso LAPS Admin"
  3. This creates a new user, sets its password to Abc.123, puts a comment on it and sets the fullname
2. Add > General > Run Command Line
  1. Change the name to ‘Add LAPS Admin to Admin Group’
  2. Command Line: cmd.exe /c net localgroup "Administrators" "ContosoAdmin" /add
  3. This adds the user ContosoAdmin to the machines Local Administrators group\
  Note: You’ll have to set the reg keys or group policy to manage your LAPS system and manage this user
Finalize BitLocker
1. Add > Disks > Enable BitLocker
2. Choose TPM Only for most situations. Consult your security team if you need something different
3. There is the option now to automatically store the key in AD
4. For us we encrypt laptops only (not thin clients) so we added the following in Options for this step:
  1. WMI Query: SELECT * FROM Win32_Battery WHERE Availability != 0
  2. What this does is look for a battery and if not present wont run
Remove built-in APPx packages (Optional)

Starting with 1909, Windows 10 has been better with Education / Enterprise versions not having so much junk when the user logs in the first time. I still run this script to clean up APPx packages. I think this is a grey area with support, but the vast majority of admins are doing this so I’ll include it here. This should be tested to make sure that no apps are removed that you need since some are super hard to get back, or require the user to have access to the store to re-add.
1. In the Setup Operating System step, somewhere after Setup Windows and Configuration Manager, add a Run PowerShell step
  1. Add > General > Run PowerShell Script
  Note here that if your scripts are unsigned (and if you don’t know if they are, they probably aren’t) you need to set the PowerShell Execution Policy to Bypass
  1. Choose the package we created earlier, “Remove APPx In-Box Apps”
  2. Type the name of the script in Script name: RemoveAPPXv5.ps1
Thats it, the time has come to either add more customizations to your liking, or get started on testing this out!

Additional Customization

Mouse Pointer during OSD — how to get it back

During imaging you may have noticed that your mouse cursor isn’t available which is pretty annoying. If you run into an error, you have to ALT+TAB through the message windows to see what it is. This restores the mouse cursor though its a little bit of work.

Create the reg key to re-enable the mouse cursor
1. Create a new Group (Add > New Group) and call it ‘Correct Missing Cursor’
2. Move the group to just after the Apply Operating System step
3. Inside the group we’ll add three (3) Run Command Line steps
4. Change the first one to the following
  1. Name: Load Registry SOFTWARE Hive
  2. Command line: reg.exe load HKLM\Temp %OSDTargetSystemDrive%\Windows\system32\config\software
5. Change the second one to:
  1. Name: Disable Surpressed Mouse Cursor
  2. Command line: reg.exe add "HKLM\Temp\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableCursorSurpression /t REG_DWORD /d 0 /f
6. Change the third one to:
  1. Name: Unmount Registry SOFTWARE Hive
  2. Command line: reg.exe unload HKLM\Temp
Remove the registry setting to restore to defaults
1. Create a new Run Command Line step at the end, right before final reboot
  1. Name: Reset Mouse Suppression to Default
  2. Command line: reg.exe add "HKLM\Temp\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableCursorSuppression /t REG_DWORD /d 1 /f
TBD

Deploying the Task Sequence

Now that you have a task sequence we have to push it’s contents out to the Distribution Points

Distribute the Content

Right click on your task sequence
Choose Distribute Content
At General, Click Next >
Review the content that’ll be distributed. Click Next >
Here you will choose your distribution points
1. Click Add
2. Choose Distribution Point
3. Check the box next to the DP you’d like to run this task sequence from. See the note below if this list is blank / wasn’t before

Note that if you have done this already, the list will be blank and when you hit Add, your any DP’s that have the content already distributed wont show up — this is a quick way to verify you’ve done this already or dont have to do it again

Side note on Prompting for Computer Name / Unknown Computers

When you start a fresh CM deployment, you may note that there is a collection (Under Assets and Compliance > Device Collections) called All Unknown Computers. You may also note that under Devices (Assets and Compliance > Devices) there are two objects:

x86 Unknown Computer (x86 Unknown Computer)
x64 Unknown Computer (x64 Unknown Computer)

You do not want to delete these as they are very useful. Essentially an Unknown computer is one that isnt in the list of Devices. Devices are identified by two main things, generally – and its good to keep this in mind since it can cause things to not work as you may expect at first:

MAC Address(s) – Network MAC Addresses are the identifier you can get in trouble the most with during PXE Imaging as if the device exists and has a learned MAC address, it wont re-image since its no longer “Unknown”
GUID – Every device has (or should have…) a GUID that’s stored in the BIOS/UEFI subsystem on the motherboard.

Note that you can set a list of MAC Addresses that are ignored and always considered Unknown by adding them to a list. You can find this in Administration > Site Configuration, Clicking on Sites, then clicking Hierarchy Settings. There, go to the tab Client Approval and Conflicting Records and at the bottom you can add ‘Hardware Ids’ or MAC Addresses to the list. This is useful if you use USB Dongles to image machines – it will ignore them and assume you’re booting an Unknown computer, and wont associate them to the device.

To prompt for a computer name:

Don’t want freshly imaged computers to have some random name? Taking over an existing setup and wonder how the dialog box knows to pop up during imaging to ask for a computer name? You’re in luck – here is where that is configured. This below sets the Task Sequence variable OSDComputerName to blank forcing it to prompt during OSD.

Navigate to Assets and Compliance > Device Collections and right click on the All Unknown Computers collection. Choose Properties
Go to the Collection Variables tab
Click on the yellow splat (*) and fill in the following
1. Name: OSDCOMPUTERNAME
2. Check the box ‘Do not display this value in the Configuration Manager console’
3. Leave the value and confirm blank

To set a known BitLocker key during OSD before its rotated by AD:

Want a BitLocker recovery PIN set to something you can know before its rotated out to something random and stored in Active Directory? Set this below to configure a known OSD BitLocker Recovery Key

Navigate to Assets and Compliance > Device Collections and right click on the All Unknown Computers collection. Choose Properties
Go to the Collection Variables tab
Click on the yellow splat (*) and fill in the following
1. Name: OSDBitlockerPin
2. Fill in the Value and Confirm with what you’d like the pin to be

Testing

How do you know if something works if you haven’t tested it? We don’t want to end up with Schrodinger’s Task Sequence, so its best to test it. What better way than spinning up a Hyper-V VM, that doesn’t need any drivers to test everything (other than drivers) before you move on to physical hardware that is finicky?

Create a new Hyper-V VM.
1. Typically I suggest 80GB disk
2. Generation 2 since we want UEFI
3. Set it to network installed OS
4. When its done go to properties and give it more than 1 core (new Hyper-V seems to be better at this at least!)
Fire your VM and let it PXE Boot. If you want to know how to set this up and how it works, there is a section fully dedicated to how that works, and how to set it up properly.
Monitor it’s progress and if it fails, where.
If it happens to fail check the SMSTS.log file with CMTrace.exe to get more information on what went wrong