Applying an Unattend.xml Answer File in a SCCM OSD Task Sequence

There are times when you might need to customize Windows by using an unattend.xml answer file during the OS deployment. Yes, many of these customizations can be baked into the OS image itself or scripted but using an answer file is easier in many situations. For example, if you had offices in UK and USA and wanted to customize the keyboard language depending on the location, then it’s easier to maintain two answer files than two OS images.

Once you create an answer file how do you use it in a OSD task sequence? Long story short, you create a package for the answer file and then reference it in the Apply Operating System step in the task sequence.

Read on if you want the long story…

1) Create a Package for the Answer File

First thing’s first, copy the unattend.xml answer file into the SCCM software repository. Make a note of the answer file name and the UNC path where it’s stored. 

Windows 10 OSD Error: Windows Could Not Finish Configuring The System

I’ve been racking my brains over this one for the past couple of days so I thought I’d chalk up my findings here in the hope of saving the headache for somebody else.

I came across this very unexpected error message when my VM rebooted right after the Apply Operating System action while running a task sequence to install a custom Windows 10 image with an answer file:

(I was too busy troubleshooting the problem and didn’t think of taking a screenshot until it was too late. I had to Google the error message to find this image for the purposes of this post.)

Long story short, the clue to resolving this lies in the setuperr.log file in the C:\Windows\Panther\UnattendGC directory.

Capturing the Reference Windows 10 Image using MDT 2013 Update 2

This is the second of a three-part series on Windows 10 OSD using MDT and SCCM.

Recap: In the first post we populated our MDT deployment share and then created and ran a task sequence to install Windows 10 on a virtual machine along with our applications and the .NET Framework 3.5 enabled. We left the post at the point of having a Windows 10 installation which we can brand as our own and customize the default user profile.

Here, we’re going to pick up from where we left off – I’m going to assume you’ve done all the customization to your liking and thus effectively turning the Windows 10 virtual machine into a reference machine. We’ll create a task sequence to sysprep and capture an image of our virtual machine which will give us our “Reference Windows 10 Image”. We’ll also create the unattend.xml file in this post which we’ll need in the next post. Ok, let’s get started.

Step 1) Create Task Sequence to Capture the Windows 10 Reference Image

Unattend.xml and Customsettings.ini

When I first started researching on the Microsoft Deployment Toolkit I came across the Customsettings.ini and Unattend.xml files being mentioned in various forums and posts online but, being new to the subject, the purposes of both files wasn’t immediately clear to me.

I know many people have compared the two online but I still wanted to write my own post here, with the goal of making it easy to understand the purpose of the two files for people who are just getting starting with MDT.

First though, I think it’s best to take a step back and give a short overview of the Microsoft Deployment Toolkit and the deployment process in general before I start talking about these files (especially since it’s aimed at someone new to the subject).

If you are already familiar with how the Microsoft Deployment Toolkit works just skip the bullet points below. So, in my own words, here’s how MDT works:

• MDT 2010 is a free tool from Microsoft which can be used to automate the deployment of Windows operating systems with minimal to no user interaction
• MDT uses a Deployment Share which contain all the necessary files and components required in your deployment environment, such as Windows images, device drivers, Windows updates and service packs and applications
• You create Task Sequences within MDT which carries out a sequence of pre-determined steps on a client PC to accomplish a given task. For example, you can have a Task Sequence to capture a Windows 7 image and another Task Sequence for deploying it to a computer
• MDT produces a bootable image which can be used with Windows Deployment Services to PXE-boot a computer to start the deployment process. Alternatively, you can also create a bootable USB or DVD to boot computers
• Once the computer is booted using the bootable image a Deployment Wizard takes over the deployment process
• You select a Task Sequence from within the Deployment Wizard to execute the given task associated with the task sequence
• Selecting a Task Sequence to deploy a Windows 7 image, for example, will require you to provide some key information within the Deployment Wizard. For example, you will need to provide the keyboard language, computer name, administrator password, etc

Now, the deployment process isn’t automated if you have to manually enter the information in the Deployment Wizard, right? Exactly. This is where the Customsettings.ini and Unattend.xml files come in.

Unattend.xml is the unattended answer file which is applied during the deployment process to provide the information you would be otherwise required to enter manually when installing an OS. By providing the answers in a XML file beforehand and applying it to the deployment process you eliminate the need to enter them manually.

Much of the settings you include in Unattend.xml can also be set in the Customsettings.ini file, but with one exception. Customsettings.ini applies specifically to the Deployment Wizard. Not only can you provide the information required in the deployment wizard but you can also skip the wizard panes, thereby automating the process.

Also, each Task Sequence has its own Unattend.xml file associated with it, whereas Customsettings.ini applies to the Deployment Share globally. It is entirely possible to enter all the required information in Customsettings.ini without touching the Unattend.xml file associated with a Task Sequence.

Consider this scenario. You have two task sequences, one to deploy a 32-bit Windows 7 image and another one for a 64-bit image. In both cases you need the client PC’s to join the domain. You can automate the domain joining process using the Customsettings.ini file without having to go into the Unattend.xml files associated with both the task sequences to add the settings individually. In this scenario the settings within the Unattend.xml files are dynamically injected at deploy time by reading the properties from the Customsettings.ini file.

So there you have it, my own comparison of the two files in a MDT deployment environment. I hope someone does find this useful. I’d love feedback from anyone reading this, and hear any thoughts on the post you may have.

Building an Unattended Answer File for Windows 7

I want to document the process of building an answer file and preparing and sysprep’ing a reference computer as a way of noting down my findings in exploring my interests in Windows deployment.

This is the first post illustrating the process and settings required to build an answer file to completely automate Windows 7 installation.

Experiments with Sysprep

With the Technician Computer at hand I’ve recently been familiarising myself with the Windows SIM tool and actually building the unattend.xml answer file – I must say I find it very exciting and am really getting stuck in!

I kept it simple to start off with – to completely automate the installation while generating a random computer name, enabling the built-in admin account and customizing the default user profile. With the groundwork done beforehand my first answer file, I can say with some satisfaction, worked without a hitch!