Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


The Art of OEM - nLite & OEM Preinstallation

Your opinion goes here  

141 members have voted

  1. 2. Would you like for Windows Designer Studio to perform most of the operations described in this guide?

    • Yes, and I want more features too!
    • Yes
    • No, I'd rather stick with the plain old Windows Setup routine.
    • No, it's just a waste of time; nLite/vLite will always be enough for my needs.
  2. 3. Now that this guide is complete, are you happy with its contents?

    • Yes, it's a great idea!
    • Somewhat, I used some of the things described here.
    • Probably, but it is too complex for me to handle.
    • No
  3. 4. Which of these should benefit you the most and you'd like to see first in Windows Designer Studio? (more details soon)

    • Windows Setup SDK (Panther Engine) - WIM capture, Setup customization and ISO making, like in Parts 3 and 4
    • VKEY Explorer - an advanced tool to design the registry of the OS you are designing
    • Package Designer - a set of diff and compression tools to allow you to author/create/add/remove windows components and preinstalled apps
    • VM Workbench - an extension for the free VMware Player product to test the results of your work before finalizing

Recommended Posts

3.5. Imaging

Taking into account what you've seen in the /INFO for Longhorn, I must run ximage with the following arguments:

ximage.exe /flags 0 /capture Z: "I:\temp\install.wim" "Windows Home Server"

Depending on your disk speed, this can take a lot of time. You can see the progress in the console prompt. Ximage scans the folder structure so that it uses single instance storage and selectively compresses in LZX everything in there. Great moment for a snack, as this usually takes longer than Ghost. I have lots of drivers, so there will be over 24000 files in there. Running vmount2.exe at Above Normal priority might help. Note that this process generates lots of fragmentation for install.wim so using a defragmented partition as target will help.

Here's my result:

Available Image Choices:
<?xml version="1.0" encoding="UTF-16" standalone="no"?>

You can see that image index is 0 instead of 3. Images #1 and #2 will not be present, because Windows PE 1.6 has driver problems and is old. Part 4 describes how to use Bart PE instead (or some other Windows PE).

In order to correct this problem, you'll have to use a hex editor to modify the embedded XML in the WIM. I use Tiny Hexer from mirkes.de.

Tiny Hexer will load by default the first sector. You can also see in there the boot.ini file stored inside. The XML is stored at the end of the file, in unicode. Load the last sector and look for the text.

And replace that 0 with a 3.

Save and exit. You now have a valid WIM Beta 1 image of your OS. Go back to VMware and unmount the partition.

In Part 4 you will learn how to use this WIM to make a bootable ISO to install it.

Share this post

Link to post
Share on other sites

Part 4: Installing Windows from a WIM

In the last part of this tutorial, I will show you how to install an OS stored in a WIM. There are several ways of doing this, and there is a great degree of flexibility in making the install disc. Think it over and choose what's best for your purposes.

4.1. The Panther Unattended Install Engine

In order to test your newly created WIM, we start by copying the \SOURCES folder from the Longhorn CD, without the original INSTALL.WIM file. Add yours instead. My future DVD root is I:\temp and this will become I:\temp\SOURCES

These are the files in \SOURCES:


Replace PIDGEN.DLL, EULA.TXT and SETUPP.INI with those from your nLited disc in order to match the product key and license with what you are installing.

Now you can test to see how the setup routine looks like. SETUP.EXE will generate a C:\$WINDOWS.~BT while it is running and will delete it afterwards, the logs for the engine, codenamed Panther, are in C:\$WINDOWS.~BT\Sources\Panther.

You can see the log for setup.exe in C:\$WINDOWS.~BT\Sources\Panther\setupact.log. For example:

Info                Setup has started phase 1 at 2007-05-27 01:20:22
Info Install Source is C:\$WINDOWS.~BT\Sources
Info Build version is 6.0.4074.0 (idx02.040425-1535)
Info CreateSetupBlackboard:Successfully created Setup black board path is C:\$WINDOWS.~BT\Sources\Panther\SetupInfo
Info InstallWindows:Starting with Empty Queue. Setup Phase = 1
Info Initializing Module -- Name: "ScenarioDetect" Binary: "winsetup.dll" InitFunc: "Module_Init_ScenarioDetect" InitStr: ""
Info InitModule -- module 'ScenarioDetect' returned 1
Info Initializing Module -- Name: "ModuleLoader" Binary: "winsetup.dll" InitFunc: "Module_Init_ModuleLoader" InitStr: ""
Info Module_Init_ModuleLoader:Entry
Info InitModule -- module 'ModuleLoader' returned 1
Info Started Worker Thread 3636
Info Started Worker Thread 3884
Info Started Worker Thread 3800
Info Started Worker Thread 1908
Info Started Worker Thread 4040
Info DetectSetupScenario:Setup is starting from phase 1

After this step, if your WIM is bad the setup routine will fail. DOSNET.INF might give you some clues:

signature="$Windows NT$"

d1 = \I386
d2 = \cmpnents\tabletpc\I386
d3 = \cmpnents\mediactr\I386

ProductType = 0

MinimumMemory = 67108864

DestinationPlatform = i386

ServicePack = 0.0

halcbus.dll = %cbus2_mp%
halcbusm.dll = %cbusmc_mp%
halmca.dll = %mca_up%
halmpsm.dll = %mps_mca_mp%
halncr.dll = %ncr_mp%
missprocfeat = %missing_proc_feat%

You can control 2 things from here: MinimumMemory, in this case don't install if less than 64 Mb of RAM, and ProductType, the same as your flag in WIM XML schema, 0.

Edited by dexter.inside

Share this post

Link to post
Share on other sites

4.2. Setup Library Dependencies

If we want to run the setup routine from another, non-Vista, environment, we must make sure the proper dependencies are present on your final Windows PE / Bart PE disk. As most XP / 2003 systems have the necessary runtime code present, a minimal preinstallation environment does not and we have to get those files in there.

The proper tool to find out what we need is called Dependency Walker.

I loaded SETUP.EXE and the program displays files that are loaded by it.

On my system, it looks like the only missing dependency is DWMAPI.DLL, the Desktop Window Manager from Vista. Read here another example of such a case. It only indicates that this setup is Aero-aware and has features not shown on non-Aero desktop themes. Just like the difference between IE7 for XP/2003 and IE7+ for Vista.

4.3. Building a PE disk

I am using in this example Bart PE Builder v3.1.10a, the most flexible solution in this situation. I:\temp is the destination of my CD root and P:\ is a virtual drive containing the WHS nLited ISO I made in Part 1.


Picture 4 - Bart PE Builder

These are the plugins I use:

You should also add the hdc and SCSIAdapter folders from your BDD distribution to \BartPE\drivers. Now you can build the PE.

Don't bother with missing files, nLite removed them for good reasons.

Add the \SOURCES folder you made in the root (and without the WIM file in order to save space, we only want to find out what files are missing), in my case, I:\temp, and depends.exe to \I386\System32 so that you will be able to check for missing dependencies inside the preinstallation environment.

You should also uppercase file names and folders, the proper windows folder is I386 with a capital I, not i386.

Now make a virtual machine without any hard disks and test your PE:

Link the CD-ROM to the ISO file or mount it, and run the VM:

Share this post

Link to post
Share on other sites

Dependency Walker will provide you with the missing dependencies you need to add to your PE image for setup to work:

So you can now add them to your PE disk. Afterwards, build the CD again and repeat the process:

The final list of missing files that you will have to add is:


As you can see, now SETUP.EXE starts.

4.5. Setup Billboards

The billboards are in \SOURCES\win32ui.dll. Use Resource Hacker to customize them.

I will not change them in this tutorial to save time.

4.6. Testing the final ISO

- Add back INSTALL.WIM to your \SOURCES folder.

- Make a simple STARTNET.CMD to launch setup

set path=%path%;"X:\SOURCES"

- Build the ISO (use -m in OSCDIMG as it's probably larger than a CD)

Note that on VMware, the setup might take ~2 minutes to start from Bart PE. The setup routine is quite slow this way, so a better way to do it is to use Windows PE 2.0. For example, you might add the \SOURCES folder to a Norton Ghost 12 recovery CD and launch it from there.

Edited by dexter.inside

Share this post

Link to post
Share on other sites

The great part is that, due to the registry being already in place, this stage takes only ~20 seconds instead of the normal 7 to 10 minutes.


So, that more or less completes my guide. I will be updating it on the forum as I receive feedback from you, as there still is some more text to add. I hope I will be able to spare some time to make a small application and a SDK for this setup method, as there's great potential in it for both retail and OEM sectors.

I have brought before my point of viewing common OEM practices to Microsoft Research, but they were uninterested to make radical changes in the OPKs and OEM Action Pack software to improve it. There's nothing in for them, obviously. Although I am not primarily trained as a programmer, but as an engineer and analyst, I do resort to coding stuff by myself when I am left with no other option. I just hope the opensource community is more interested in this than Microsoft has.

Thank you for your attention. More coming soon.

Edited by dexter.inside

Share this post

Link to post
Share on other sites
Can there anything be done about the annoying "The bandwidth limit for this site has been exceeded." message when you click on a picture?

Edit: I've been noticed today of using up the bandwidth, I will mirror these pictures on my main web storage.

Edited by dexter.inside

Share this post

Link to post
Share on other sites

I've started my project at http://sourceforge.net/projects/wdesign

you can join and/or get the source code there, post suggestions for functionality, or whatever.

as for the main issues i'd like to cover:

- it will cover complementary aspects to nLite/vLite functionality

- for a start, it is intended to create a setup disc, by performing stuff described in this guide

- a more "embedded" point of view, e.g. the ability to define a "package" containing files, registry settings, and installer logic, to acquire the contents of that package from the windows disc or an existing installation. I don't like using several gigabytes of storage or SQL Server to handle data. It was the only way 10 years ago when they invented this method called "NT Embedded", but now we have Microsoft .NET to ease our work.

- the ability to define/add/remove these packages from a sysprepped 2000/XP/2003 or Vista

- some compatibility to the distribution share in Business Desktop Deployment

- share with others your own package layout, so each of the users can contribute to the process.

I am currently working on a unified abstraction layer to handle heterogenous data in windows, like INFs / SIFs / registry hives / XMLs. As for storage capabilities, I plan to use WIM, in a similar fashion that Microsoft did in Windows XP Fundamentals for Legacy PCs.

The main process would look like this:

1) Acquistion - windows files get copied into the application's WIM repository, from either Windows PE, windows setup disc, or an existing windows installation.

2) Packaging - depending on what packaging logic you have at that moment, an acquired OS gets transformed into a bunch of packages. You can either create more packages yourself to remove more from the leftovers or to add a application.

3) Verification - the future registry is scanned for errors, you are prompted to add files that are not present, you can preview changes

4) Export - using files stored in your registry, like OSes, apps, drivers, and the packaging schema you created, another sysprepped installation of windows is generated, on either local filesystem, SDI disks or mounted VMware VMDK disks

5) Testing - I have the SDKs for VMware Player, the free virtualization product, so my app should be able to generate a VMX configuration and boot that exported disk to test if it actually works.

6) Install Media - using a package containing setup files, a setup disc is generated, just like in Part 4 of the guide

At this point I am planning a console-like main window that runs wizards for each task: Acquisition, Export...


You can try it yourself - get the binaries here.

This build is only for testing the code on different machines. No actual functionality yet. Read the console.log that it generates after each run to see what it actually does.

So I will be creating a list with desired functionality. Feel free to submit a request for your needs.

N.B. As I currently am unemployed I will probably have a lot of time for programming. :D

Edited by dexter.inside

Share this post

Link to post
Share on other sites
How did you get the OS/Version/Build No. on the bottom right of your installations in screenshots on the first page?

there's the "show version number on desktop" tweak, present in either nLite or the TweakUI powertoy. It's useful when you have to track lots of windows installations. In evaluation builds it's enabled by default. If you've got a timebomb there's an extra string there - "for evaluation purposes only."

Share this post

Link to post
Share on other sites
You can get ximage.exe from the Longhorn 4074 install CD or from the Longhorn 4033 SDK. It was renamed to ImageX after Beta 1 was scrapped. It may surprise you to know that Codename Eiger also uses the Beta 1 format instead of later revisions, due to some unknown reason.

I use version 6.0.4059.0 (main.031208-1842), compatible with XML*.DLL schema v2.00.3510.0 (main.031208-1842) and earlier. This was the last release of Beta 1, compatible with all WIMs made before Beta 2. Notice the compile date - December 2003. Eiger uses a different compile of the same code, flagged with a "cjonas" string in the version, both compatible.

Here's how the /? output should look like.

XIMAGE /capture [Drive] [Image File] [Description]
XIMAGE /boot [Drive] [Image File] [Description]
XIMAGE /append [Drive] [Image File] [Description]
XIMAGE /apply [Image File] [Drive] [View #]
XIMAGE /script [Script

/capture - Creates a new image of a drive
/boot - Creates a new bootable image of a drive
/append - Appends a drive image into an existing image
/apply - Applies an image to a drive
/info - Displays available image views
/script - Specifies an answer script
/scroll - Scrolls output for redirection
/nosis - Stores duplicate files
/nocomp - Stores uncompressed file data
/lznt - Use LZNT1 compression
/lzx - Use LZX compression [default]
/flags - User defined image flags
/verify - Verify duplicate files

ximage /capture D: data.wim "Drive D"
ximage /lzx /capture C: cdrive.wim "C Drive"
ximage /lznt /capture E: data.wim "Drive E"
ximage /nosis /nocomp /capture D: data.wim "Drive D"
ximage /scroll /append E: data.wim "Drive E"
ximage /boot D: data.wim "Drive D"
ximage /apply data.wim D: 1
ximage /info data.wim
ximage /script unattend.txt
ximage /flags 128 /capture D: data.wim "Drive D"

Functionality differences from the RTM version are:

- Beta 1 does not support mount/unmount operations, they were added 1 year later.

- There is no mini-filter driver compatible with the resulting WIMs.

- The XML schema is different.

Windows Tools : xImage

Share this post

Link to post
Share on other sites

Update: I will soon have links to the PDF version on my website and on the project's home @ SourceForge.

I will probably release the windows setup SDK and a testable alpha build of the project by the end of the month. My progress with the code is satisfactory; here's a preview of the target system registry designer

Screenshot Link

Edited by dexter.inside

Share this post

Link to post
Share on other sites
ewood    0

Excellent guide dexter.inside! :thumbup I've spent quite a few hours going over these posts and have found them incredibly useful. Thanks for making this all available to the public!

I've got a question for you regarding this whole process (which I'm still trying to wrap my head around).

Is it possible to create an OEM installation of XP this way? I'm asking because I see you're using xImage, which you've said to be a longhorn thing.

I wish I understood the process well enough to answer my own question, alas, I must ask the expert!

In the end, what I'd like to have is a version of XP customized for my corporation, all up to date and with all the standard apps we use. I've used nLite to customize the installer as shown in section 1. All worked well, I have a half-customized iso of xp at this point. I'm on to the next section of creating the VM and adding all the other apps I'll need.

At this point I'm a bit confused because the guide is obviously for Windows Home Server and I'm not working with that platform.

If you have a few minutes could you straighten me out?

Thanks in advance!

-- edit --

Okay, I'm to section 2.2 - prepping the share. All good there.

2.3 is where I've stopped. I don't understand why I need to nLite the source and burn it again in 2.4.1, the reason being I chose to make the ISO at the end of step 1.5 as I dont need to add anything else at this point. (I don't think).

Edited by ewood

Share this post

Link to post
Share on other sites
Is it possible to create an OEM installation of XP this way? I'm asking because I see you're using xImage, which you've said to be a longhorn thing.

It's possible to create a installation of any windows this way. You can't have Windows Setup reading from a Ghost image, but you can from one made with ximage. Before the introduction of WINLOAD.EXE and the new boot code this is how Longhorn was installed.

2.3 is where I've stopped. I don't understand why I need to nLite the source and burn it again in 2.4.1, the reason being I chose to make the ISO at the end of step 1.5 as I dont need to add anything else at this point. (I don't think).

In your case that's not needed, true. I have detalied a more complex scenario for the purpose of customizing some server functionality. The main target for what is described in 2.3 - 2.4 would be server farms / Windows 2003 CCS or Home Server, on which there is no easy or cheap way of doing this kind of customization. If you already have a satisfactory installation in a virtual machine fell free to proceed with its imaging.

I am also planning an alternate preinstallation scenario for Part 2, more simple and intended for Windows 2000/XP, so that I can provide a standard common-base testing scenario for my app, when it will become beta-testable later this month. simply put, a BDD-like bare metal installation method for NT 5.x without all the fuss concerning offline servicing.

Most likely I will include both workstation and server scenarios in the PDF.

Edited by dexter.inside

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.