Forgive me for beginning this thread after development work has begun but this
is something that was in the works prior to the initial code import to ASF. I
also wasn't familiar with ASF practices until this week, so better late than never.
I have been working on adding support for Windows Vista bare metal images. To
begin with, I'll summarize what's been done to date and try to provide a little
background information for those of you who are familiarizing yourselves with
the VCL code. After that, I’ll explain what I’m working on now and propose some
Any thoughts or help you can provide is greatly appreciated. I realize I’m
dumping a lot into one message, so please begin new threads as you see fit.
The basic development necessary to allow a Vista image to be captured and loaded
is done. The majority of this work is reflected in 2 places in the repository:
Vista.pm is where nearly all of the subroutines reside which interact with the
OS. These subroutines perform operations such as add a user, configure the
firewall, and so on. The following subroutines within Vista.pm make up the OS
module interface and are called by the VCL state modules (new.pm, image.pm, etc):
capture_prepare - Called by image.pm when image capture is initiated. Performs
steps to clean up and prepare the OS before a disk image is saved. Examples of
tasks: logoff user, disable and delete the pagefile, configure firewall
capture_start - Called by image.pm after everything is ready for the image to be
captured. This initiates a reboot and then xCAT takes over to run partimage.
post_load – Called by new.pm after an image has been loaded on and booted for
the first time. It configures the computer, examples being: activate Vista, run
newsid.exe which also sets the computer name, disable the customer improvement
program. The steps performed by post_load are not specific to a reservation,
meaning it doesn’t add the user account or configure networking access specific
to a user’s IP address.
add_users – Called by new.pm when a computer needs to be reserved for a specific
reservation. It creates a local account for the user who made the reservation.
If the image has been configured to have a user group associated with it,
add_users also creates accounts for the user group members.
grant_access – Called by reserved.pm. After a user clicks the Connect button on
the VCL current reservation page, the user’s IP address is captured and the
request state is changed to reserved. reserved.pm calls the grant_access
subroutine, which opens up the firewall allowing RDP traffic from the user’s IP
sanitize – Called by reclaim.pm. If a computer is reserved but the user never
connects, reclaim.pm returns the computer to the state it was in before being
configured for a specific reservation rather than completely reloading the
computer. The sanitize subroutine reverses the actions done by add_users and
grant_access. It deletes user accounts and removes the firewall exception for
The other subroutines in Vista.pm are called by the subroutines listed above.
The Scripts directory contains several batch, registry, and other files. These
are copied to the computer when an image is being created. A few of the files
currently in the Scripts directory in the repository are not used at all. The
functionality provided by these has been implemented in subroutines in Vista.pm.
For example, the contents of the various .reg files also exist as string
variables in the Vista.pm subroutines. Using SSH, Vista.pm takes the string
representing the contents of a valid .reg file, echos it to a temp file on the
remote computer, and then runs reg.exe to import it into the computer's
registry. Some of the files can be removed from the repository but they aren't
Working on now...
Our NCSU production system has a working base image. There are a few minor bugs
to fix. I have created Jira issues for the ones I know of (VCL-38, VCL-39,
VCL-40). They are pretty minor and I will try to fix them to today.
There are a few aspects where I know improvements can be made. I have created
Jira issues for the following:
Sysprep for Vista (VCL-42) - The code is currently using newsid.exe instead of
Sysprep. This was done because Vista uses an entirely new deployment mechanism
and Sysprep was taking a very long time to run. Vista’s new Sysprep/deployment
architecture has some nice features. Support should be added.
Device drivers (VCL-41) – Sysprep has the ability to add device drivers.
Newsid.exe does not. The code does not currently inject any device drivers.
The ability to add device drivers without using Sysprep should be added.
Reduce Vista image size (VCL-43) - Image size is a problem. The base image with
no applications and no pagefile is around 8-9 GB. For comparison’s sake, our
Windows XP base image is around 2 GB. The size of every Vista image will
increase over time as Microsoft updates are installed. The C:\Windows\winsxs
directory will grow with each update. Reducing Vista’s image size is an area
that needs to be researched. There’s a product called vLite which allows you to
install Vista with a smaller footprint. I tried it out and it worked pretty
well, but I was unable to run Sysprep on the image.
Suppress Security Center warnings (VCL-44) – The registry keys used in Windows
XP to suppress Security Center warnings do not seem to work the same with Vista.
VCL images have Microsoft automatic updates disabled. This is causing a
warning to be displayed in system tray.
Defrag before image capture (VCL-45) – Windows images are usually defragmented
before an image is captured. Vista’s defrag takes a very long time. There are
claims that this was improved with SP1 but it’s still very slow. I don’t know
exactly how long an average defrag takes with Vista but I have seen it take well
over an hour. Code exists in capture_prepare to run defrag but it is currently
commented out. If defrag is enabled, the message sent to users saying the image
will be ready in 25-30 minutes must be changed.
Change location of copied VCL files (VCL-46) – When an image is captured, the
Sysprep_Vista directory is currently being copied to C:\VCL. I initially used
this location to make it easy to access during development and should have
changed it before now. The directory should be moved somewhere less obvious.
It’s probably best to use one of the locations VCL uses for XP –
C:\Cygwin\home\root or the Application Data directory in root’s profile directory.
Virtual Computing Lab
Office of Information Technology
North Carolina State University