Novell Doc: PlateSpin Orchestrate 2.5 Virtual Machine Management Guide

6.2 Understanding Sysprep

In the PlateSpin Orchestrate Development Client, sysprep refers to the function of preparing unique settings for Windows VMs on VM hosts so that those VMs can be provisioned by the provisioning adapter without creating conflicts and personalizing other information.

As the administrator, you can set facts in the PlateSpin Orchestrate Development Client that can later be automatically applied to a VM clone (by selecting the Use Autoprep check box) during a Provision or a Clone action from a VM template. The sysprep facts can also be manually applied to an existing VM by using the Personalize action.

NOTE:In PlateSpin Orchestrate 2.5, Windows VMs managed by the xen provisioning adapter and the hyperv provisioning adapter can now be “sysprepped” in the Development Client. This functionality was not supported in earlier releases of the product.

Make sure you have performed these prerequisites:

Create a Windows VM by using the Xen hypervisor.
Make sure the VM is discovered by PlateSpin Orchestrate.
Configure the VM (or a template of the VM) by using the information in Section 6.2.2, Setting Sysprep Facts in the Development Client and in Section 6.2.3, Using the Sysprep deploy.cab Files.

When the prerequisites are met, you can proceed to sysprep the xen VM by using the information in Section 6.2.4, Applying Sysprep Facts.

This section includes the following information:

6.2.1 How Sysprep Works

This section includes the following information:

Sysprep onVMware VMs

Sysprep facts (see Section 6.2.2, Setting Sysprep Facts in the Development Client) are translated by the PlateSpin Orchestrate vSphere provisioning adapter into a VMware image-customization specification. The provisioning adapter passes the specification to the vSphere client API, which does the customization work. The changes made are leveraged by the Windows sysprep facility to complete final reconfiguration.

The vsphere provisioning adapter requires the VMware Tools package installed and running on the target VM before sysprep can be done, because that is a requirement of the underlying VMware Image Customization functionality leveraged by PlateSpin Orchestrate.

Sysprep On Xen VMs

The xen provisioning adapter uses the settings specified in the sysprep facts to perform an “unattended mini-setup” to reconfigure the VMs’ Windows guest operating system. The provisioning adapter directly modifies the VM image without need for any agent, so you can configure sysprep on a “cold” VM image in the same way as you can run the Install Agent action on that image.

NOTE:You can perform the Install Agent and Personalize actions at the same time on a Xen Windows VM. The two operations cooperate and complete without conflict.

6.2.2 Setting Sysprep Facts in the Development Client

You can use the Development Client to configure the facts for sysprep of a VM. This section includes information about the Development Client interface where those facts are set.

When you select a Windows VM object in the Explorer tree of the Development Client, click the Info/Groups tab to open the Info Groups page, then scroll down to the Provisioning Information panel of this page. Open the Windows Sysprep Config subpanel and the Network Sysprep Config subpanel.

Figure 6-2 The Sysprep Sections of the Info/Groups Page of a VM Template Object

Windows VMs that you clone can be personalized and prepared for provisioning by configuring the facts in this panel. Click Define on each field if the value has not been previously configured.

NOTE:You can trigger a sysprep for a Windows VM just by configuring the Admin Password field on this page. The Orchestrate provisioning adapter fills in the other required values with reasonable defaults if you don’t specify them. For example, the value for the Computer Name field uses the PlateSpin Orchestrate VM name by default.

When you finish changing the settings in this panel, right-click the VM and select Personalize for the changes to take effect. This sets up a pending customization that does not take place until the VM is powered on (provisioned) again.

IMPORTANT:On VMs managed by Xen and vSphere, running the Personalize action on a templated VM is not supported. Running this action results in failure because it is not supported in the underlying system. When you clone or provision from a templated VM, select the Use Autoprep check box.

This section also contains the following information:

Sysprep Facts

The following table lists the facts that are either required or optional for configuring sysprep.

Table 6-1 Required or Optional Facts for Sysprep Configuration

String in Development Client UI	Fact Name	Required/Optional	Description and Information
Change SID	<fact name="resource.provisioner.autoprep.options.changeSID" value="false" type="Boolean" />	Automatic default value provided by Orchestrate¹	The Windows Security ID. If this is marked as true, sysprep generates a new Security ID. If this is not selected, Orchestrate defaults the value to true, meaning a new SID is to be generated during sysprep. For newer (that is, unattended .xml-based) sysprep, unless this fact is defined and explicitly set to false, the SID is always changed. This is the desired behavior for cloning a Windows machine.
Delete Accounts	<fact name="resource.provisioner.autoprep.options.deleteAccounts" value="false" type="Boolean" />	Optional²	(Windows with vSphere VMs) When this check box is selected (it has a value of true), PlateSpin Orchestrate removes all user accounts from the destination VM; the Administrator account and other Windows “standard” accounts are left in place. If it is false, existing accounts from the source VM are retained. (Xen) This field is deprecated for Xen sysprep. Instead, ensure that the VM image has the required set of accounts from the beginning. No account deletion is done unless this fact is defined and set to true. Also, some versions of Windows sysprep do not support account deletion during sysprep, in which case this flag is ignored.
Admin Password	<fact name="resource.provisioner.autoprep.sysprep.GuiUnattended.AdminPassword.value" value="" type="String" />	Required³	The Admin password for this VM. NOTE:Only a plaintext admin password is currently supported. You should leave this field blank if Admin Password Plaintext is not selected. This fact must be specified or the personalization fails. Windows sysprep requires that this be specified.
Admin Password Plaintext	<fact name="resource.provisioner.autoprep.sysprep.GuiUnattended.AdminPassword.plainText" value="false" type="Boolean" />	Automatic default value provided by Orchestrate¹	When this check box is selected (it has a value of true) the Admin Password value is entered in plain text. If not set, this fact defaults to true, indicating that the AdminPassword fact is a plain text password. Orchestrate does not support automatic encryption of the password, so if you want to use an encrypted password, you need to know how to encrypt the password correctly for sysprep.inf, then enter it as AdminPassword.value with this flag set to false.
Timezone	<fact name="resource.provisioner.autoprep.sysprep.GuiUnattended.TimeZone" value="" type="String" />	Automatic default value provided by Orchestrate¹	The time zone of the new VM. For sysprep on Windows versions prior to Vista, (that is, versions using sysprep.inf), numeric time zone codes are used. See the Microsoft sysprep documentation for values (for example, 04 indicates PST, 10 indicates MST, 20 indicates Central, 35 indicates EST as defined in the Windows sysprep documentation). NOTE:Make sure that you use the exact text string listed under the Time Zone column heading in the table included in this Microsoft article. For sysprep on Windows Vista and later (that is, versions using unattend.xml), full string time zone names are used. Refer to the Microsoft sysprep documentation for the relevant Windows version. If you do not set this fact, the default time zone for sysprep.inf (UTC or 85) is used.
Autologon	<fact name="resource.provisioner.autoprep.sysprep.GuiUnattended.AutoLogon" value="false" type="Boolean" />	Optional²	When this check box is selected (it has a value of true) the VM automatically logs on to the Administrator account by using AdminPassword. If the value is false, logon is prompted. If no value is provided, the fact is set to false.
Autologon Count	<fact name="resource.provisioner.autoprep.sysprep.GuiUnattended.AutoLogon" value="" type="Boolean" />>	Optional²	The limit count for the VM to automatically log on with the Administrator account. AutoLogon must be true for this value to be accepted. If a value is not specified for this fact, but Autologon is set to true, the value defaults to 1.
Fullname	<fact name="resource.provisioner.autoprep.sysprep.UserData.FullName" value="" type="String" />	Automatic default value provided by Orchestrate¹	The user’s full name required by the Windows OS installer during installation.
Org Name	<fact name="resource.provisioner.autoprep.sysprep.UserData.OrgName" value="" type="String" />	Automatic default value provided by Orchestrate¹	The organization name required by the Windows OS installer during installation. This fact is required by sysprep. If the value is not specified, the provided default is Organization Name. This fact is nonessential for Windows functionality.
Computer Name	<fact name="resource.provisioner.autoprep.sysprep.UserData.ComputerName" value="" type="String" />	Automatic default value provided by Orchestrate¹	The VM’s new host name. If you specify an asterisk () in this field, Orchestrate Services generates the name based on the source VM name. This fact is required by sysprep. If the value is not set, the default value is the name of the VM in Orchestrate Services. The name cannot be longer than 15 characters because of a Windows limitation on the length of the computer name. Values longer than 15 characters are not accepted. Because facts can be edited using methods other than the Admin view of the Server Console, be aware that there are other restrictions regarding the characters you can use for the Computer Name. The following characters are not allowed: whitespace ` ! @ # $ ^ & () + = [] {} \ \| ; : ' " , <> / ? Other methods you could use to edit the computer name fact might not enforce any restrictions or constraints on the naming. If the naming is invalid, the VM might hang during sysprep.
Product ID	<fact name="resource.provisioner.autoprep.sysprep.UserData.ProductID" value="" type="String" />	Effectively required⁴	The Windows product key. The ID is obtained from the Windows MSDN CD or from Microsoft. The value is used when building a new VM. This fact is optional for PlateSpin Orchestrate, but if the value is not specified, the Windows VM might stop at a user prompt on its console waiting for the entry of the Product ID. Certain versions of Windows, such Windows Server 2008, might not require a product key at installation, but will eventually require it (or a valid license server setup for product activation).
Run Once Command	<fact name="resource.provisioner.autoprep.sysprep.GuiRunOnce.Command" value="" type="String" />	Optional²	A list of commands separated by new line characters that run the first time a user logs on after the new VM is created. Commands are scheduled by using the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce registry key. The value does not need to be specified. It is passed to the sysprep answer file only if one or more commands are specified in the list.
Workgroup	<fact name="resource.provisioner.autoprep.sysprep.Identification.JoinWorkgroup" value="" type="String" />	Automatic default value provided by Orchestrate¹	The Windows workgroup name. If the VM is joining a domain, use JoinDomain. Sysprep requires either a domain or a workgroup to be joined. This fact is ignored if the Domain fact and related facts are set, because domain joining takes priority over Workgroup joining. If no domain is being joined, and this fact is not specified, the default value becomes WORKGROUP (default with Windows).
Domain	<fact name="resource.provisioner.autoprep.sysprep.Identification.JoinDomain" value="" type="String" />	Automatic default value provided by Orchestrate¹	The Windows domain name. If the VM is joining a workgroup, use JoinWorkgroup. For joining a domain, DomainAdmin and DomainAdminPassword must be defined. No default value is provided if this value is not set. Instead, a workgroup is joined with the default name WORKGROUP if no Workgroup fact was set.See also: Domain Admin Password (required if a value is set for this fact).
Domain Admin	<fact name="resource.provisioner.autoprep.sysprep.Identification.DomainAdmin" value="" type="String" />	Required³	Provide a value for this fact when the Domain fact has a value. Configuring this fact allows sufficient privileges to the Windows sysprep program to add the new server or workstation to the domain. Normally, this is the Administrator account for the domain. If the Domain fact does not have a value, this fact is ignored.
Domain Admin Password	<fact name="resource.provisioner.autoprep.sysprep.Identification.DomainAdminPassword.value" value="" type="String" />	Required³	Provide a value for this fact when the Domain fact has a value. Configuring this fact allows sufficient privileges to the Windows sysprep program to add the new server or workstation to the domain. Normally, this is the Administrator password for the domain. If the Domain fact does not have a value, this fact is ignored.
Domain Admin Password Plaintext	<fact name="resource.provisioner.autoprep.sysprep.Identification.DomainAdminPassword.plainText" value="false" type="Boolean" />	Automatic default value provided by Orchestrate¹	When this check box is selected (it has a value of true), DomainAdminPassword is in plaintext. The value defaults to true if it is not set. The value is currently ignored for sysprep, because there are no fields to accept this flag in sysprep.inf or unattend.xml.
License File Automode	<fact name="resource.provisioner.autoprep.sysprep.LicenseFilePrintData.AutoMode" value="" type="String" />	Automatic default value provided by Orchestrate¹	The value in this field is either PerServer or PerSeat. If it is set to PerServer, the AutoUsers fact must be set. A value for this fact is required for sysprep on Windows Server products. The provided default is “PerServer.”
License File Autousers	<fact name="resource.provisioner.autoprep.sysprep.LicenseFilePrintData.AutoUsers" value="200" type="Integer" />	Automatic default value provided by Orchestrate¹	Specify value between 1 and 9999, representing the number of client licenses per seat. A value for this fact is required for sysprep on Windows Server products. The provided default is 5.

¹ Facts with automatic default values must be set in the sysprep.inf or unattend.xml answer file, but the vmprep job provides useful “generic” defaults if any of these facts are not specified. In general, a VM can be successfully personalized using only an Admin Password and Product ID. Some versions of Windows do not require the Product ID if their activation timeout for Windows Product Activation has not yet expired.

² Optional facts are never required. They are not placed in sysprep.inf or unattend.xml if a value is not specified. For the purpose of this documentation, “optional” also means that sysprep continues to function if these facts are not specified; however, optional facts might be needed as part of a Domain join or a similar function.

³ There is no way to provide default values for required facts, and sysprep fails ungracefully if they are not specified. The vmprep job fails a Personalization action if these facts are not set by the user.

⁴ For sysprep, this is the only fact that is “effectively” required. Some versions of Windows can be installed or sysprepped without this value, but most versions stop during sysprep and await user interaction at a Product Key prompt if this value is not specified in sysprep.inf or unattend.xml.

Configuring vNIC Sysprep Facts

VMs can be prepared for provisioning by configuring the facts in either the Autoprep Network Adapter subpanel (Windows VMs) of the vNIC Info/Groups panel or the Sysprep Network Adapter subpanel (Linux VMs). For more information, see Defining Autoprep/Sysprep Network Adapter Facts on the vNIC Object.

Virtual NIC sysprep facts are always optional. If they are are not specified, Windows chooses “typical system” values, including setting vNICS to use DHCP.

6.2.3 Using the Sysprep deploy.cab Files

By default, Microsoft does not include the sysprep.exe or setupcl.exe utilities needed for sysprep on Windows Server 2003, Windows XP, or any previous version. To provide sysprep functionality for VMs running these Windows versions, PlateSpin Orchestrate must have access to compatible deploy.cab files from Microsoft. These files can usually be copied directly from the Windows installation CD, or they can be downloaded from Microsoft.

For Windows Vista, Windows Server 2008, and later releases, Microsoft includes the needed sysprep tools on the OS installation and uses a different “answer file” format and utility syntax. For these newer versions of Windows, there is no need to download additional files from Microsoft, or to copy them from the installation CD.The following instructions apply only if you want to perform sysprep-based personalization on Windows 2003 VMs, Windows XP VMs, or earlier versions of Windows VMs. The instructions include the following:

.cab File Installation Locations

Assuming a normal install of the Orchestrate Server, the server’s datagrid file tree is located in the /var/opt/novell/zenworks/zos/server/datagrid/ directory. Copy the .cab files to one of the following locations (leaving off the fully qualified portion of the path before "/datagrid”) as appropriate for the Windows server operating system:

     dataGrid/files/sysprep/winserver2003_sp1/x86/deploy.cab
     dataGrid/files/sysprep/winserver2003_r2/x86/deploy.cab
     dataGrid/files/sysprep/winserver2003/x86/deploy.cab
     dataGrid/files/sysprep/windowsxp/x86/deploy.cab
     dataGrid/files/sysprep/windowsxpx64/x86_64/deploy.cab
     dataGrid/files/sysprep/winserver2003x64/x86_64/deploy.cab
     dataGrid/files/sysprep/winserver2003x64_r2/x86_64/deploy.cab

Notice that the files are named according to the resource.os.type fact, the resource.os.arch fact, and (optionally) whether the VM’s operating system is SP1, R2, or something similar. The file tree in the list above covers all of the common releases of Windows. The Orchestrate sysprep job looks for the datagrid file in the following path:

grid:///sysprep/<resource.os.type>_<servicepack>/<resource.os.arch>/deploy.cab

If Orchestrate cannot find the .cab file in this path, it looks for the datagrid file in the following path:

grid:///sysprep/<resource.os.type>/<resource.os.arch>/deploy.cab

If you want to install the precise version of deploy.cab from your Windows CD, use the above convention to copy it to the /datagrid directory.

Through testing, Novell has determined that only two unique .cab files are required to support the most common Windows versions. See the Download Instructions exceptions on the Microsoft site for details. This method works because Orchestrate uses only the sysprep.exe and setupcl.exe executables from the .cab files. The other utilities are not used because their purpose is to manually build sysprep.inf. Orchestrate automatically builds its own answer file as part of the VM personalization process.

Detailed Instructions for Downloading .cab Files From Microsoft

Use the following steps to download the .cab files from Microsoft that you need for sysprep for Xen and Hyper-V VMs.

HINT:You can deploy the .cab files uisng any user account that has admin rights.

(Conditional) Download the Windows 2003 .exe file containing deploy.cab.
1. From a Web browser, navigate to the Microsoft Download Center page entitled System Preparation tool for Windows Server 2003 Service Pack 2 Deployment, then download the Windows 2003 sysprep tool, WindowsServer2003-KB926028-v2-x86-ENU.exe.
2. Copy the .exe file to a suitable location on a Windows physical or virtual machine, then run the executable with the /x flag (which specifies file extraction only) to extract deploy.cab from the executable bundle.
3. Navigate to the extracted directory where deploy.cab is located.
4. Copy deploy.cab to the appropriate locations on the Orchestrate Server.
(Conditional) Download theWindows XP .cab file:
1. From a Web browser, navigate to the Microsoft Download Center page entitled Windows XP Service Pack 2 Deployment Tools , then download the Windows XP sysprep tool, WindowsXP-KB838080-SP2-DeployTools-ENU.cab.
2. Run the .cab file on a Windows physical or virtual machine to extract deploy.cab.
3. Navigate to the extracted directory where deploy.cab is located.
4. Copy deploy.cab to the appropriate locations on the Orchestrate Server.

VM personalization testing using the two versions of deploy.cab files listed above has determined that they are suitable for common versions of Windows. When you have placed copies of the deploy.cab file in the proper directories of the Orchestrate Server machine, you can perform sysprep personalization on pre-Vista versions of Windows.You can download other, potentially newer, deploy.cab files from Microsoft, but be sure you are familiar with how to use the Microsoft sysprep tools and that the version you download matches the version of your VMs. Make sure you use the file and directory naming conventions explained in this section, so that the personalization system uses the correct deploy.cab for the VM being personalized.

Detailed instructions for Copying deploy.cab from the Windows Installation CD or DVD

If the version of deploy.cab you download from Microsoft is not suitable for the Windows version on your Windows VMs, you can copy deploy.cab for the version of Windows server you need directly from the Microsoft installation CD or DVD. The file is normally located in the following path relative to the CD’s root directory:

     support/tools/deploy.cab

Copy deploy.cab to the correct location in the datagrid file tree of the Orchestrate Server according your Windows version (see .cab File Installation Locations). For example, if your CD is the x86_64 version of Windows 2003 Server SP2, copy it to the following location on the Orchestrate Server machine:

     dataGrid/files/sysprep/winserver2003x64_sp2/x86_64/deploy.cab

You can also copy deploy.cab to the alternate location used for fall back:

     dataGrid/files/sysprep/winserver2003x64/x86_64/deploy.cab

NOTE:If the .cab file you download from Microsoft (see Detailed Instructions for Downloading .cab Files From Microsoft) causes problems with sysprep on your VM images, using the method of coping deploy.cab described in this section might correct compatibility problems.

6.2.4 Applying Sysprep Facts

For vSphere VMs, the vmprep.job is not used. Instead, Orchestrate uses VMware Image Customization through the Orchestrate vsphere provisioning adapter’s vi-client facility. For more information, see Sysprep onVMware VMs.

For Xen VMs, the PlateSpin Orchestrate Server applies the sysprep facts by launching the vmprep job when the facts are defined. This job runs automatically and applies the appropriate facts to a VM in the following situations:

When you run a Personalize action on any non-templated VM. (See Table 2-2).

On VMs managed by Xen and vSphere, running the Personalize action on a templated VM is not supported. Running this action results in failure because it is not supported in the underlying system. When you clone or provision from a templated VM, select the Use Autoprep check box.
When you create a VM clone by initiating the Clone action on a VM template.

You must select the Use Autoprep check box in the VM Client or the Use Autoprep check box in the Development Client if autoprep facts are to be used when the Clone action is initiated.

You need need to make sure that the VM template is set up according to your needs before you clone or provision it, so that the resulting clone meets your needs.

6.2.5 Example Sysprep Scenarios

Scenario 1: You want to create 25 dynamic VM instances to test job provisioning. You will never use these instances again, so you will not personalize them.

You create a VM template by right-clicking a VM, then you select Create Template. When the VM Template is created in the Explorer Tree, you define its sysprep facts in the Info/Groups page by spcifying an asterisk in the MAC Address field, then you select the Use DHCP check box. This lets the Development Client autogenerate the MAC address and retrieve network data from the DHCP server. For information about setting sysprep facts on each vNIC, see The Virtual NIC Info Panel in the PlateSpin Orchestrate 2.5 Development Client Reference.

When the sysprep facts are defined, you provision this template. You right-click the template object and select Provision, then in the Provision VM dialog box, you specify that you want to provision (create) 25 new VM instances from this template. Provisioning automatically applies the sysprep facts from the template.

Scenario 2: You have created three VM clones in your grid and you want to provision those clones. You want to ensure that the MAC address and other key network information for each clone is unique, even though each clone is a copy of the same OS image. These clones are to be detached later and used for such things as mail servers and Web servers. When the clones were first created, sysprep facts were applied, but now you have changed those facts by adding static IP addresses, subnet masks, and gateway addresses for each. Each clone must be “personalized” because of this change to basic network identifiers.

To personalize, you select each Clone object, then define the adapter-specific settings on the Info/Groups page by entering IP addresses, subnet masks, and gateway addresses for each adapter. When you have defined the sysprep facts on each VM clone, you right-click each Clone object in turn and select Personalize to apply the new network configuration.

For more information, see Changing a Virtual Machine Template Clone to an Instance and Personalize.

6.2.6 Known Sysprep Limitations

There are some limitations that you need to be aware of when you use sysprep on VMs:

When a VM is sysprepped on vSphere, two reboots are required after the VM is first started in order for Windows to apply VMware and sysprep reconfigurations. Windows VMs managed by Xen and syspreppred also require two reboots.
Before performing a sysprep operation on a vSphere VM, you must first configure the VM to have the VMware Tools guest OS package installed. The VMware administrator must also have configured the Virtual Center server to allow sysprep. For more information, see the VMware vSphere Online Library.
When a VM is sysprepped in vSphere, it goes into a “customization pending” state that is not cleared until the VM successfully starts and the prep is complete. This means that subsequent attempts to sysprep fail until the VM reboots and the previous prep completes. There is no way to directly reverse customization in vSphere.
When you create a template of a VM with the Windows Server 2008 R2 OS, make sure that you configure the sysprep settings for all of its network interfaces using a DHCP connection, not an IP address. This is necessary because of a problem in Windows sysprep that does not remove old IP addresses from the template. The guest OS must not have an IP configured when it is sysprepped.

When the template has been prepared to use DHCP, subsequent syspreps of the clones of that template can use an IP address.
Testing has shown that personalizing VMs that have pre-Vista Windows operating systems does not properly configure some network settings. This is a sysprep limitation. The issue is manifest when vNIC-specific settings from sysprep facts on the VM's vNICs are not configured in the VM after personalization.

To work around this issue, personalize by using DHCP settings. You can do this by leaving the fields blank. DHCP is the default for network settings.
If a Hyper-V VM is running during the discover process, it fails to discover the resource.os.family fact. This prevents the Development Client from displaying the Sysprep and Autoprep options section on the Info/Groups tab for the VM.

NOTE:If the VM not running when the discovery occurs, the hyperv provisioning adapter discovers resource.os.family itself.

If you create a template from this VM, the resource.os.family fact is discovered and populated on the VM template admin view.

To display the sysprep/autoprep settings on a Hyper-V VM use the following steps:
1. Shut down the Hyper-V VM that has the problem.
2. From the Explorer Tree, right-click the VM you have shut down, then select Resync State.
3. In the Development Client, Shift+click the Refresh icon or restart the Development Client to refresh all of the objects and their facts in the Resource admin view.
Sysprep does not work on Windows VMs until you set a value for the Admin Password fact: resource.provisioner.autoprep.sysprep.GuiUnattended.AdminPassword.value.

For information about this fact, see Admin Password.
If you clone a Windows Server 2003 VM template originally created in the hypervisor environment, the administrator password for the VM template base image must be blank (no value), or the original VM administrator password is retained and you cannot log in to the cloned VM with the new password.

Attempting to change an old password value by using the the AdminPassword entry in sysprep.inf does not work, but if the original password value was blank, you can use the AdminPassword entry in sysprep.inf to provide the password value and log in with that password. The value is applied from the resource.provisioner.autoprep.sysprep.GuiUnattended.AdminPassword.value sysprep fact when you select the Use Autoprep check box while creating a clone.
Some sysprep problems have been noted with Windows Product Activation (WPA) functionality, particularly with versions of Wndows that require product activation by the end user.

On Windows Server 2003 SP1, if you have a VM that has passed the initial activation deadline, and you sysprep it, sysprep is applied correctly, but that VM immediately changes to “limited functionality” mode and requires user intervention to reactivate it. Sysprep seems to remove activation and require that the VM be reactivated.

Further, although there is a Boolean value (AutoActivate) that you can set in the “unattended” section of sysprep.inf, setting the value does not always result in auto activation of a VM.

To avoid this situation, we recommend that you consider volume licensing or similar licensing solutions available from Microsoft that don’t require manual activation by an actual user. For versions of Windows prior to Windows Vista, this would be a VLK (Volume License Key). For Windows Vista or later, Microsoft has license server-based solutions available to handle volume licensing.

In using sysprep on Windows VMs managed by Xen, no special agent or tools are needed for sysprep because of the method used by the xen provisioning adapter. See Sysprep On Xen VMs for more information.