[Kingskawn]

Yo dexter.inside, I like your post. Just an idea, you have to make a blog or website with all this content.

[jimmsta]

I cannot wait for the next part - I'm most interested in capturing a WIM of a fully configured system, but cannot make sense of Microsoft's documentation. Hope to see this somewhat finished in the near future!

[dexter.inside]

jimmsta, on May 26 2007, 03:08 AM, said:

I cannot wait for the next part - I'm most interested in capturing a WIM of a fully configured system, but cannot make sense of Microsoft's documentation. Hope to see this somewhat finished in the near future!

lol, there is no microsoft "official" documentation on how to deploy pre-NT 6 this way... their only attempt is called Codename Eiger

Good news: this guide will soon be available in HTML and PDF in nuhi's guide collection.

This post has been edited by dexter.inside: 26 May 2007 - 10:16 AM

[dexter.inside]

Part 3: Windows Imaging

In Part 3 of this tutorial, I continue were we left off with Sysprep. Covered here are two issues of great importance that will greatly enhance the NT deployment experience - one is the Microsoft WIM technology, arguably the best idea that Microsoft Research came up with in the past 10 years and the other is called virtual to physical migration - V2P - a free alternative solution that I managed to make instead of using expensive software like Symantec, Acronis and VMware to migrate a closely tweaked windows installation from a virtual, controlled environment to physical bare metal hardware.

3.1. Some legal considerations

As you may know, WIM is closed source. Although the Vista SDK and WAIK are free to use, the windows setup UI and installer logic capable of reading from a WIM is not. Using components from Vista RTM to install other windows editions this way is a clear violation of the EULA. Fortunately, there is a way around this.

Back in 2004, when Vista was called Longhorn and was based on the NT 5.1 codebase (unlike builds 5xxx that are based on NT 5.2 codebase) the setup was a simple Visual C++ program that used the Beta 1 format of WIMs to install builds 4xxx on your computer. After build 4093, the entire codebase was scrapped and the new Beta 2 WIM format was no longer compatible with the previous one. Microsoft considers the 4xxx builds as abandonware and is no longer interested in what people do with them. You might have heard of some people from the joejoe forums trying to make good use of them. The good part is that I can make some very good use of the Beta 1 format of WIMs, which is also abandonware, along with the Longhorn 4033 SDK. Using these for personal use should not be of any legal concern, the same case as with nLite.

Sysprep is part of the same EULA of it's corresponding NT build, so, as covered by the OEM reseller license, it should be legal to deploy through your organization network evaluations of windows that include the WIM Beta 1 technology, as well as keeping a backup of your licensed retail edition of windows to be deployed with the same technology. This is covered by the same regulations that allow products like Symantec Ghost Suite or VMware V-Motion / Converter. So... enjoy!

3.2. The WIM Beta 1 format

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.

This post has been edited by dexter.inside: 26 May 2007 - 11:02 AM

[dexter.inside]

3.3. Needed INSTALL.WIM settings

If we want to create a proper image, we must look for its settings in another that is accepted by the Longhorn setup routine. In this example, I use Longhorn 4074, one of the most popular.


Picture 1 - Longhorn 4074 CD


Picture 2 - INSTALL.WIM

Here's what the /INFO looks like:

 
Available Image Choices:
------------------------
<?xml version="1.0" encoding="UTF-16" standalone="no"?>
<WIM>
        <IMAGE INDEX="1">
                <DIRCOUNT>38</DIRCOUNT>
                <FILECOUNT>1287</FILECOUNT>
                <TOTALBYTES>183629593</TOTALBYTES>
                <CREATIONTIME>
                        <HIGHPART>0x1C42CDF</HIGHPART>
                        <LOWPART>0x4BE6614</LOWPART>
                </CREATIONTIME>
                <DESCRIPTION>WinPE Boot Image</DESCRIPTION>
                <FLAGS>1</FLAGS>
        </IMAGE>
        <IMAGE INDEX="2">
                <DIRCOUNT>37</DIRCOUNT>
                <FILECOUNT>1284</FILECOUNT>
                <TOTALBYTES>183629406</TOTALBYTES>
                <CREATIONTIME>
                        <HIGHPART>0x1C42CDF</HIGHPART>
                        <LOWPART>0x50127EC</LOWPART>
                </CREATIONTIME>
                <DESCRIPTION>WinPE Drive Image</DESCRIPTION>
                <FLAGS>2</FLAGS>
        </IMAGE>
        <IMAGE INDEX="3">
                <DIRCOUNT>1491</DIRCOUNT>
                <FILECOUNT>15762</FILECOUNT>
                <TOTALBYTES>2612836956</TOTALBYTES>
                <CREATIONTIME>
                        <HIGHPART>0x1C42CEC</HIGHPART>
                        <LOWPART>0xCA2101A2</LOWPART>
                </CREATIONTIME>
                <DESCRIPTION>Windows Longhorn pro</DESCRIPTION>
                <FLAGS>0</FLAGS>
        </IMAGE>
</WIM> 

Image #1 contains Windows PE 1.6 (before Beta 2, both BOOT.WIM and INSTALL.WIM were stored together), image #2 contains the drive image of the same Windows PE with setup program added and #3 is the Longhorn image. Thus, the setup program has IMAGE INDEX="3" hardcoded. Also, notice the "0" flags. Both are required by the setup to identify the source image.

3.4. VMware Mount

VMware Workstation 6 has a great feature: the vmount2 service that allows you to mount any partition stored in a VMDK file as a disk in your host OS. I will mount the C: drive from the WHS VM on Z:


Picture 3 - Mount Partition


Picture 4 - R/W Warning

You can delete temporary files, like pagefile or hiberfil to save space. Also, you can read what modification sysprep did to your installation in \WINDOWS\setupapi.log. For components, there will also be logs like iis6.log. In my case, I had the services disabled, you can see what happened here:

 
[5/8/2007 12:5:43] LogFile Open. [***** Search on FAIL/MessageBox keywords for failures *****].
[5/8/2007 12:5:43] SysPrepBackup:start
[5/8/2007 12:5:43] SysPrepBackup:InetStartService():ServiceName=IISADMIN unable to start WARNING.  Err=0x422.
[5/8/2007 12:5:44] SysPrepBackup:!FAIL! 
[5/8/2007 12:5:44] SysPrepBackup:CoCreateInstance on IID_IMSAdminBase2 failed
[5/8/2007 12:5:44] SysPrepBackup:end,ret=0x80070422
[5/8/2007 12:5:44] Final Check:RtlValidateHeap(): Good.
[5/8/2007 12:5:44] Final Check:LogFile Close. 

Thanks to vmount, you will be able to image the drive without having to boot from a rescue disk with ximage on it.

There are some minor issues with sysprepping a nLited OS. The thread is here. It's a good idea to copy the files specified there to the \WINDOWS\Driver Cache\I386 and check \sysprep\sysprep.inf for InstallFilesPath="C:\WINDOWS\Driver Cache\i386" in Unattended section. Even if you don't do this, installation will still succeed, but you will see some annoying prompts regarding missing files during mini-setup.

This post has been edited by dexter.inside: 26 May 2007 - 11:50 AM

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

This post has been edited by dexter.inside: 31 May 2007 - 03:22 AM

[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[/url]

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

This post has been edited by dexter.inside: 06 June 2007 - 01:28 PM

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

This post has been edited by dexter.inside: 06 June 2007 - 01:49 PM

[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]

Roost_12, on Jun 11 2007, 03:22 PM, said:

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.

This post has been edited by dexter.inside: 18 June 2007 - 11:52 AM

[dexter.inside]

I've started my project at http://sourceforge.n...rojects/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.

This post has been edited by dexter.inside: 18 June 2007 - 07:28 AM

[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]

JuMz, on Jun 18 2007, 05:18 PM, said:

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]

dexter.inside, on May 26 2007, 06:58 PM, said:

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

This post has been edited by dexter.inside: 04 July 2007 - 12:59 PM

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

This post has been edited by ewood: 05 July 2007 - 02:29 PM

[dexter.inside]

ewood, on Jul 5 2007, 11:05 PM, said:

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.

ewood, on Jul 5 2007, 11:05 PM, said:

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.

This post has been edited by dexter.inside: 05 July 2007 - 07:20 PM