The Art of OEM - nLite & OEM Preinstallation

[dexter.inside]

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"?>
<WIM>
        <IMAGE INDEX="0">
                <DIRCOUNT>3519</DIRCOUNT>
                <FILECOUNT>24518</FILECOUNT>
                <TOTALBYTES>4417022357</TOTALBYTES>
                <CREATIONTIME>
                        <HIGHPART>0x1C79FD0</HIGHPART>
                        <LOWPART>0x3E2BF020</LOWPART>
                </CREATIONTIME>
                <DESCRIPTION>Windows Home Server</DESCRIPTION>
                <FLAGS>0</FLAGS>
        </IMAGE>
</WIM>

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.

Picture 5 - mirkes.de Tiny Hexer

Picture 6 - Open as Large File

Picture 7 - 0x2000 Sector Size

Picture 8 - First Sector readout

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.

Picture 9 - Loaded Last Sector

And replace that 0 with a 3.

Picture 10 - Modified data

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.

[dexter.inside]

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:

background.jpg
background_low.jpg
bulk_cbb.xml
bulk_ibs.xml
button.jpg
button_low.jpg
cmiagent.dll
cmiv2.dll
dosnet.inf
dotnetpe.cab
eula.txt
hivewinibs_software.inf
hivewinibs_system.inf
hwcomp.dat
idwlog.exe
inplace.inf
install.wim
migcore.dll
migsys.xml
migui.dll
miguihlp.dll
migxml.dll
mlang.dll
msvcp60.dll
offline.xml
ooberes.dll
ooberesl.dll
oobeui.dll
pantherutils.dll
pidgen.dll
seqmanage.dll
setup.exe
setup.exe.local
setupp.ini
sflist2k.dat
sflist98.dat
sflistme.dat
sflistnt.dat
sflistxp.dat
spflvrnt.dll
spuilib.dll
spwizeng.dll
sysabst.dll
upgload.dll
upgmaster.dll
upgmaster2.dll
upgrade2.xml
wdscore.dll
wdsmngqueue.dll
wdsutil.dll
win32ui.dll
win32uitheme.dll
winsetup.dll
xmlrw.dll

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.

Picture 1 - Setup Welcome Screen

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

Picture 2 - Product Key

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

[Version]
signature="$Windows NT$"
DriverVer=10/01/2002,6.0.4074.0


[Directories]
d1 = \I386
d2 = \cmpnents\tabletpc\I386
d3 = \cmpnents\mediactr\I386


[Miscellaneous]
ProductType = 0

MinimumMemory = 67108864

DestinationPlatform = i386

ServicePack = 0.0

[UnsupportedArchitectures]
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 May 31, 2007 by dexter.inside

[dexter.inside]

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.

Picture 3 - Dependency Walker with SETUP.EXE

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:

Picture 5 - Plugins

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

Picture 6 - Build Finished

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.

Picture 7 - Make ISO

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

Picture 8 - Test VM

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

Picture 9 - Command Prompt

[dexter.inside]

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

Picture 10 - Missing Files

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

Picture 11 - Missing Files (2)

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

ADVPACK.DLL
CDFVIEW.DLL
CLBCATQ.DLL
EFSADU.DLL
HNETCFG.DLL
INETCOMM.DLL
MSHTML.DLL
MSRATING.DLL
PRINTUI.DLL
WZCDLG.DLL
COMRES.DLL
HLINK.DLL
MSOERT2.DLL

As you can see, now SETUP.EXE starts.

Picture 12 - Setup on BartPE

4.5. Setup Billboards

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

Picture 13 - Setup Billboards

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"
X:\SOURCES\SETUP.EXE

- 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.

Picture 14 - Starting Setup

Picture 15 - Welcome

Picture 16 - Product Key

Picture 17 - Drive Selection

Picture 18 - Settings

Picture 19 - Working

Edited June 6, 2007 by dexter.inside

[dexter.inside]

Picture 20 - Task Manager

Picture 21 - Finish

Picture 22 - First Boot

Picture 23 - Starting

Picture 24 - Computer

Picture 25 - Final Tasks

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.

Picture 26 - Login

Picture 27 - Personalized Settings

Picture 28 - Desktop

Conclusion

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 June 6, 2007 by dexter.inside

[Roost_12]

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

[dexter.inside]

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 June 18, 2007 by dexter.inside

[dexter.inside]

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.

Edited June 18, 2007 by dexter.inside

[JuMz]

How did you get the OS/Version/Build No. on the bottom right of your installations in screenshots on the first page?

[dexter.inside]

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."

[Bilou_Gateux]

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.

Usage:
        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

Commands:
        /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

Examples:
        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

[romsempire]

your guide rocks!!

Please give us pdf version.

THX

[dexter.inside]

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 July 4, 2007 by dexter.inside

[ewood]

Excellent guide dexter.inside! 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 July 5, 2007 by ewood

[dexter.inside]

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 July 6, 2007 by dexter.inside