Provisioning MS Windows clones with sysprep and unattend.xml file
The procedure described here is for Windows Vista onwards. However, different versions versions of Windows add and remove obsolete options; if in doubt, see the official documentation from Microsoft.
Automatically configuring and activating Windows desktops is specially useful when using volatile desktops: installations that are created, configured, used for a short time (from some minutes to a few days), and then deleted, to make room for creating fresh desktops. So in this this page we will refer to the Guests as volatiles, although this method can be used for long-life Guest machines.
Sysprep
Sysprep is a utility (included with the OS) that allows us to generalize a Windows system: erase all configuration information that makes that machine unique, to regenerate it on the next reboot. It is very useful for creating clones of a particular system image, as flexVDI does when creating clones with a desktop policy. The idea is to run sysprep, turn off the machine, turn it into a template and create clones that will be configured in their first boot. This configuration can be automated with an answer file.
You can find more information about sysprep on the following links:
Preparing a Windows Template with Sysprep
The right way to create a Windows Guest to serve as a template is to enter audit mode during the installation of Windows . Thus no local user will be created, other than the administrator. In audit mode, you can configure the template installing any programs you want. Once finished, you must run sysprep . This tool will shut down the guest at the end, so we must keep it in RunOnce mode.
There is no limit to the number of times sysprep can be run on a system. But after executing it, Windows will need to be activated again, which can be done up to three times on a given Windows installation, or Windows will stop letting users to log in the system after 30 days.
To avoid this problem, after configuring the template, create a copy where you will execute sysprep. Thus, if you need to make changes to the template, you can make them on the original (which has not gone through the generalization/activation cycle) and repeat the procedure on new copies as often as necessary.
When you run sysprep us the following window:
For the task at hand, we will select "Enter System Out-of-Box Experience (OOBE)", "generalize" and "Shutdown". Pressing "OK", the process of generalization is made, then the guest will turn off. From here we can turn it into a template.
New from Windows 8 / Windows Server 2012
From Windows 8 / Windows Server 2012, the sysprep command supports a new option mode, only from the command line. By passing the parameter "/mode:vm" hardware information will not be removed, so that subsequent boot are noticeably faster. However, all clones must run on machines with the same hardware profile. The complete command line would be:
> sysprep.exe /generalize /oobe /shutdown /mode:vm
Answer File
When we have prepared a template with sysprep, we can use an answer file to automate the initial configuration at the next boot. That file is searched in a series of predefined paths. In particular, one of which is " A:\unattend.xml " ( Implicit Answer File Search Order No. 4). For that reason, desktop policies have a field to set up a file /flexvdi/local as answer file. If this file exists, the flexVDI Host Agent will copy it into a floppy disk in each volatile clone, renamed to "unattend.xml", so that it can be used to automatically configure the clones. In addition, you can use the following three variables within the file, which will be replaced by flexVDI Host agent before inserting it into the floppy disk, with specific values for each volatile:
- WINDOWSDOMAIN is replaced by the domain specified in the policy Windows desktop.
- COMPUTER is replaced by the name of the volatile. This name is generated in one of two ways:
- vxxxxxxxx, where x represents the number of volatile (the guest name suffix that appears in the session table VDI).
- An arbitrary name assigned in the LDAP attribute that defines the possible policies a user's desktop in the form "computer = xxxxx" as if it were a political more.
- VDIUSER is replaced by:
- uxxxxxxx, if the volatile has been precreated (done when the field "Precreated desktops" in the Desktop Policy is greater than 0), where x is the number of volatile. Precreation makes the specialization and activation of the desktop happen before the user logs in.
- The name of the user who has been authenticated in flexVDI if the desktop has been created as a result of that request.
- uxxxxxxx, if the volatile has been precreated (done when the field "Precreated desktops" in the Desktop Policy is greater than 0), where x is the number of volatile. Precreation makes the specialization and activation of the desktop happen before the user logs in.
The format of this file is XML. It describes the actions and values to be applied in the different Windows configuration passes during startup. Its format is similar to the following:
unattend.xml
<?xml version="1.0" encoding="UTF-8"?><unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="..."> <component name="..." processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http:/ ... </component> ... </settings> ... <cpi:offlineImage cpi:source="..." xmlns:cpi="urn:schemas-microsoft-com:cpi" /></unattend> |
The tag settings includes a set of components that will be applied during a certain phase of the installer, specified with the attribute pass .
The tag component specifies a component of the installer, and the properties that it will be automatically assigned. The processorArchitecture attribute indicates to which architecture is applied this section. The remaining attributes are fixed. You can duplicate each component tag, using a different architecture (x86 or amd64) in each one, to be used always.
The tag cpi:offlineImage refers to the location of the base image where the response file is applied. It only makes sense during the creation of the file.
Creating a response file
The best practices for authoring answer files is to use Windows System Image Manager. The alternative is to write the file by hand and then optionally validate with WSIM. When you open WSIM see the following:
To create an answer file, it is necessary to start from a Windows image. We can simply take the file \sources\install.wim that comes in a Windows installation ISO. When opening the image, WSIM create a catalog file first, if it does not exist. To do this, the image must have read and write permission, so we have to copy the content of the ISO to the hard drive and remove the read-only flag. Once you open the image and create the catalog, we will create an initially empty answer file. Then you just have to drag the components of the image to the corresponding section in the answer file, and configure them. See Unattended Windows Setup Reference to understand the usage of each component.
Some examples for the most common situations:
Basic configuration
To set the language, the name of the machine and local users, add the following components:
- Microsoft-Windows-International-Core to the oobeSystem section. The "InputLocale", "SystemLocale", "UserLocale" and "UILanguage" properties must be set to "en-US"
- If you do not want to have any local user, Microsoft-Windows-Deployment to specialize section, adding a RunSynchronousCommand with the following properties:
- Path = reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OOBE /v UnattendCreatedUser /t REG_DWORD /d 1 /f
- Order = 1
- Microsoft-Windows-Shell-Setup in the specialize section with the following properties:
- ComputerName = COMPUTER
- TimeZone = (valid zones can be listed with "tzutil /l") for instance "Pacific Standard Time"
- CopyProfile = true. It will overwrite the profile in "\Users\Default User" with the current user.
- ShowWindowsLive = false. Do not show a link to Windows Live in the start menu.
- ProductKey = product key to activate Windows.
- Microsoft-Windows-Shell-Setup in the oobeSystem section with the following properties:
- OOBE, to hide configuration pages to start first, with the following properties:
- HideEULAPage = true
- NetworkLocation = Work
- ProtectYourPC = 2 (see reference for possible values)
- UserAccounts, with the following properties:
- AdministratorPassword/Value = administrator password. However, by default, the administrator account is disabled.
- LocalAccounts, one for each local user you want to add. If only domain users will be used, add no user.
- RegisteredOwner and RegisteredOrganization, optionally, with their corresponding values.
- OOBE, to hide configuration pages to start first, with the following properties:
Licensing volatile desktops
Volume licensing should be used KMS a similar method to decrease the number of licenses used to destroy a clone for volatile desks, or. MAK licenses are not supported.
It is likely that the boot process will requests a product key if it is not provided in the response file. To prevent this from happening, you can use a key in file \sources\product.ini which is in the Windows installation media. As a result, the boot process will not request the key, but Windows will not be activated.
Add computer to a domain
To add the volatile desktop to the domain specified in desktop policy, add the following components:
- Microsoft-Windows-UnattendedJoin in the specialize section with the following properties:
- Identification/JoinDomain = WINDOWSDOMAIN
- Identification/Credentials with user credentials with permission to add machines to the domain.
Delete Unattend.xml cached files
Answer files are cached in C:\Windows\Panther . This is a security problem because they contain credentials that users should not be able to see. Therefore, it is best to delete files A:\unattend.xml and C:\Windows\Panther\unattend.xml. The most common option is to create a batch command in the template called C:\Windows\Setup\Scripts\SetupComplete.cmd with the following content:
del /Q /F a:\unattend.xml
del /Q /F c:\windows\panther\unattend.xml This command will be executed at the end of the preparation of the volatile guest, removing the two answer files.
More information
You can find more information about response files in the following links: