Archive for the ‘Quickprep’ Category
In a VMware View environment you can either use Microsoft Sysprep or VMware Quickprep for the personalization of your Linked Clone desktop pools, while you can only use Sysprep for the personalization of traditional desktop pools based on VM templates.
Every Windows operating system is generating a unique SID (Security Identifier) during the first installation of the system. This SID is used to clearly identify the operating system in a network environment. But this local SID is only used until the computer is a member is a Windows Workgroup only. As soon as you add the computer to a Active Directory domain a new SID for the computer account will be created and the local SID is no longer in use. The Microsoft Sysprep tool does change the SID for the operating system as the SID should be unique for each OS instance. The Sysprep operation needs several minutes to change the SID on a Windows OS as it needs to change all files on the hard disk drive.
The VMware Quickprep tools which comes with VMware View is used for the same reason but only with Linked Clone desktop pools. Quickprep is faster compared to Sysprep as is does not change all files on the hard disk. It does change the SID in the Active Directory which is only used as described above.
Also other software vendors use their own tools to change the SID on Windows instances, especially companies from the software deployment, like Altiris.
The Quickprep process is started by the View Composer during the creation of the Linked Clones. After the View Composer has created the replica disk and the Linked Clone own OS disk is mounted, the View Composer communicated with the Active Directory and creates a new computer account for the Linked Clone desktop and sets a random password. This process uses the standard Windows API interface and also the user account you’ve configured for the View Composer in the View Administrator GUI. If the configured user account does not have sufficient permissions the action will fail. If the action is successful, a configuration file which includes information about the desktop (hostname, domain and more) is created on the OS disk of the Linked Clone. After the file is written the desktops gets restarted. During the next boot process the View Agent hooks in. It does that in two modes. Firstly it runs in the native mode just before the Win32 subsystem is started. During that time it can still access system files which are usually locked. Secondly it starts the Service Agent which does the most tasks i.e. the communication with the View Server or writing to the Windows Registry. The native part of the agent reads the information which is written in the configuration file by the View Composer before and sets the hostname for the Windows operating system before the system comes up. After that the Service Agent writes the needed Windows domain information into the Registry.
Both applications, Sysprep and Quickprep give you the same result: A Windows desktops with a unique SID.
It’s a good decision to choose Quickprep for the Linked Clone pools because the personalization process is faster but there are also reasons for choosing Sysprep. Sometimes software products i.e. Antivirus software or network access control need a unique local SID. But anyway using vShield Endpoint is better than having a anti virus scanner in each desktop.
If you’re choosing Sysprep for your Linked Clone desktops please consider the following points.
- All vSphere servers in your cluster must run a 4.0 or 4.1 version.
- A recompose does force the system to create a new SID. (That takes a long time depending on the number of files in the VM)
- The View Agent on the VM needs the View Composer component to be installed. (Usually this is the standard)
- The Active Directory controllers must be reachable from all the desktops.
Since View 4.5 it is possible to use several settings to get more speed into the provisioning tasks of View Composer. Even if the changes speed up your VDI environment please bear in mind that manual changes in the ADAM are not supported.
The hostname naming conventions in companies are very different and mostly the come from the early days of IT. In banks for example often they are using a prefix or suffix with an increasing number. With VMware View it’s possible to use naming patterns to customize the hostname. By default the prefix can be up to 13 characters in length and some numeric suffix is appended to that in order to distinguish each desktop from others in the pool.
With VMware View 3 and the View Composer it is possible to create automated desktop pools using the linked clone technology and saving storage through that. Within the configuration you can directly set an organizational unit in the Active Directory for the desktops in the automated desktop pool.