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.
...
| Info |
|---|
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 in 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:
...
| Info | ||
|---|---|---|
| ||
From Windows 8 / Windows Server 2012, the sysprep command supports a new option |
Answer File
When we have prepared a template with sysprep, we can use an answer file is used 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 " ( APB 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 host agent insert flexVDI Host Agent will copy it into the a floppy disk in each volatile clone named , 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 replace the host 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 prewritten deskprecreated (done when the field "Precreated desktops" in the Desktop Policy is greater than 0), where x represent 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 prewritten deskprecreated (done when the field "Precreated desktops" in the Desktop Policy is greater than 0), where x represent 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. Describes It describes the actions and values to be applied in the different phases Windows Installerconfiguration passes during startup. Its format is similar to the following:
...
The tag component specifies a component of the installer, and the properties that it will be automatically assigned automatically. The atrbuto The processorArchitecture attribute indicates to which architecture is applied this section applies, the . The remaining attributes is are fixed. You can duplicate each component tag component , each with using a different architecture (x86 or amd64) for use in any casein each one, to be used always.
The tag cpi:offlineImage refers to the location of the base image on which where the response file appliesis applied. It only makes sense during the process creation of creating the file.
Creating a response file
The recommended procedure to create 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 picture file \sources\install.wim that comes in a Windows installation ISO. When you open the image, WSIM create a catalog file first if not exist. To do this, the image must have permission to read and write, so we copy the ISO to the hard drive and will remove the read - only flag. Once you open the image and created the catalog, create the initially empty answer file. Then you just have to go dragging the components of the image to the corresponding section in the answer file, and configure them. See reference Unattended Windows to understand what each component. Examples for the most common situations occur.
...