Back to basics – Understanding Unattend.xml automation in Windows 7

Article originally posted on https://deployvista.com, my previous blog.

First
If your goal is to very quickly have a nice fully automated Windows 7 setup, including drivers, application etc. – This article is not for you. If that's your goal, you should download the free Microsoft Deployment Toolkit (MDT) and use that as your deployment solution.

Second
That being said, if you rather is a hardcore geek who wants to build everything yourself from scratch, instead of using the standard tools that Microsoft recommends, this article will help you create your own answer files to automate the core Windows 7 setup.

This is also your chance to challenge the 20+ people strong deployment solution team at Microsoft, showing them that you are better building deployment solutions than they are. Why use a standard solution that 700.000 other people on this planet are already using when you can re-invent what they have done and build it your self 🙂

So here is the text to get in touch with your inner deployment geek…

Download the sample files:

Understanding Unattend.xml automation in Windows 7

Background info…

The core setup of Windows 7 can be automated by creating an answer file, the Unattend.xml file. The Unattend.xml for Windows 7 (and Vista/2008/2008R2) are divided into sections, or configuration passes. This is because different parts of the setup are reading settings from different passes.

This means that depending on what type of Windows 7 setup you are doing, you need to populate different sections in the answer file. The premium tool for editing the unattend.xml file is Windows System Image Manager (WSIM) from the Windows Assessment and Deployment kit – The Windows ADK.

The settings that you have to define also depends on if you are using setup.exe to deploy Windows 7, or just using an image utility like ImageX (or ghost, or whatever) to apply an image. I will cover all these scenarios.

Please also notice that you need different answers files depending on what platform (x86 and x64) you are deploying. An answer file for x86 cannot be used for x64 and vice versa.

Scenario 1 – Running setup.exe to deploy Windows 7.

If you boot the default Windows 7 DVD – Setup.exe starts automatically. To have setup.exe pick up an answer file, you just need to named it AutoUnattend.xml and store it in one of the paths that setup.exe looks for answer files in. The most common location is a removable media like a USB stick.

In the sample files for this article you will find a minimal, but fully automated answer file for this scenario. The sample file is for the x86 version of Windows 7 Enterprise when using KMS for activation, joining a WORKGROUP (no Product Key specified in the answer file).

Scenario 2 – Running ImageX to deploy Windows 7.

As mentioned you don't need to run setup.exe to deploy windows 7, you can boot into a WinPE 3.0 environment and use tools like imagex to apply an image. If you don't use setup, you need to also create and format the drive before applying the image. The overall process is the following:

  1. Boot on WinPE 4.0
  2. Create and format a partition (C:)
  3. Use ImageX to apply a previously sysprepped image to C:
  4. Create a bootloader
  5. Copy your unattend.xml file (named Unattend.xml) to C:\Windows\System32\Sysprep
  6. Reboot

In the sample file for this scenario, I have taken the sample file from Scenario 1 and just removed the WinPE pass settings. I could have used the exact same file, for any settings in WinPE pass are simple skipped when using ImageX, but I prefer to have as clean answer files as possible.

Scenario 3 – Running Sysprep

You can also prebake the answer file into your image when running sysprep. If you do that, you don't have to copy it in step 4 in the previous scenario.

The sample file for this scenario are the same as for scenario 2. You can have sysprep use it by either specify /unattend: when running sysprep. Or by storing the unattend.xml file (named Unattend.xml) in the C:\Windows\System32\Sysprep folder before running sysprep. The normal switches for sysprep are /oobe /generalize /shutdown (or /reboot).If we wanted we could also add settings for the Generalize pass for this scenario if we wanted. That section is being read when executing sysprep.

Notes about the answer files.

In Windows 7 the Administrator account is disabled by default. It can be enabled by either specifying the AdministratorPassword value together with Autologon settings, or like most people did in the Windows Vista timeframe, by running a few RunSynchronous Commands in the specialize pass. I selected to use the AdministratorPassword/AutoLogon feature in my samples since I wanted to Autologon anyway.

Also, if you are deploying into a workgroup, like my samples, there is a need to specify an extra account in the unattend.xml, or the Windows 7 setup will stop and prompt youfor a user. In my sample I use a neat trick. Since I have enabled the administrator account, I simply specify that user as the extra account, and I avoid the need for creating an extra user which later may have to be deleted.

/ Johan

About the author

Johan Arwidmark

0 0 votes
Article Rating
Subscribe
Notify of
guest
12 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Sai
Sai
8 months ago

Hi Johan,

Great Article…
I have a doubt, does this apply to DISM and unattend.xml as well.

I mean if I am applying the image using DISM and then if I place the unattend.xml under C:\Windows\System32\sysprep, will that be picked up as in scenario2.

Thanks in advance.

BR,
Sai

Last edited 8 months ago by Sai
Admin
Admin
6 years ago

Most likely you have a GPO that renames the admin account.

/ Johan

AndersE
AndersE
6 years ago

Hi! I´m still working with MDT 2010. But it is still great.
Now a strange thing occured.
After deployment of Win 7, adminstrator (svenska administratör) account has changed name to Admin
So At logon screen it is administrator, but I have to write admin to logon when in Domain.
Checking accounts under comp mgmt. Yes it is called Admin.
The only thing I have done is created Another account using unattend.xml, 7 oobe, local accounts, administrators Group.
Any ideas, Johan?
Regards Anders

Admin
Admin
7 years ago

Just add FinishAction=REBOOT to the CustomSettings.ini, and MDT will disable the autologon automatically (but the admin account is still enabled)

/ Johan

Teknologist
Teknologist
7 years ago

Hey,

Great article! very informative. I just started with MDT WDS and all these wonderful tools since we are getting so many Windows 8 laptops / tablets.

Question, is there a way to enable the built-in Administrator account, but not have it autologin? I have a second local admin account created with unattend.xml, but I would like to have both (built-in and local admin) accounts display at the log in screen after the workstation completes sysprepping.

Thanks!

Admin
Admin
7 years ago

Since you're using MDT (which is awesome), simply call a script in the task sequence that creates any extra users needed.

/ Johan

meffordm
meffordm
7 years ago

Johan,

I need to inject the extra user on the fly. Our users enter a default user and password during the wizard (using custom wizard pages) and I need to get that into the unattend.xml file in place of the default user that comes in the unattend.xml file from corporate, but I'm quickly exhausting all of my ideas. I see that some of the unattend.xml values can be overwritten from customsettings.ini properties and such (i.e. TimeZone), but I can't find any that work for my situation. Is there a way to do it?

Michael.

meffordm
meffordm
7 years ago

Johan,

I need to inject the extra user on the fly. Our users enter a default user and password during the wizard (using custom wizard pages) and I need to get that into the unattend.xml file in place of the default user that comes in the unattend.xml file from corporate, but I'm quickly exhausting all of my ideas. I see that some of the unattend.xml values can be overwritten from customsettings.ini properties and such (i.e. TimeZone), but I can't find any that work for my situation. Is there a way to do it?

Michael.

meffordm
meffordm
7 years ago

Johan,

I need to inject the extra user on the fly. Our users enter a default user and password during the wizard (using custom wizard pages) and I need to get that into the unattend.xml file in place of the default user that comes in the unattend.xml file from corporate, but I'm quickly exhausting all of my ideas. I see that some of the unattend.xml values can be overwritten from customsettings.ini properties and such (i.e. TimeZone), but I can't find any that work for my situation. Is there a way to do it?

Michael.

Admin
Admin
7 years ago

I have a new post that explains how to automate Windows 8.1 for Windows To Go:

Automating the Windows To Go setup (Windows 8.1 Enterprise) https://deploymentresearch.com/Research/tabid/62/EntryId/123/Back-to-basics-Automating-the-Windows-To-Go-setup-Windows-8-1-Enterprise.aspx

/ Johan

saranrajappa
saranrajappa
7 years ago

Hi Johan,I have a issue with MDT2013 and Windows 8.1.Case:I have prepared a reference computer (VM), Windows 8.1 Ent 64Bit with all my setting, and Administrator account is enabled.I have build a task sequence in MDT 2013 and selected sysprep and capture, Updated the MDT share.From reference VM, opened MDT share and launced LiteTouch.vbs..; captured the reference VM WIM to share. Issue:I am deploying the captured WIM to a Windows To Go USB drive using Windows To Go creator available in Windows 8 system. I am finding it build-in administrator account has been disabled while booting the WTG computer. Troubleshooting… Read more »


>