dexter.inside

man this andrew guy must be one of those IT employees that can't make a difference between winsock and the print spooler, and for some reason somebody promoted him into a high responsability job thus, this article. Also, probably one of the many that never even heard about the Windows XP Embedded concept.

Greetings, I have documented in Part 2 of my guide how to perform a manual installation of WHS, how to use nLite on it, and how to generate new installation media. I believe it might help you reach your goals faster. http://nliteos.com/oemguide2.html and the forum topic is in my signature.

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.

I mean he could be using parts of his code for commercial stuff, like in gaming technology... if he were to release the source code maybe somebody else would do that and get all the benefits...

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

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

ok maybe I can clear the issue a bit for those reading this topic: 1) WIM technology is free, but closed source. Basically, using the technology for you needs is free, but there's no real documentation for how to build an API for this purpose. Thus, each one of us that programs a new layer of functionality based on WIM technology has to do it by experimenting on their own. 2) Let's say somebody were to make such an API to suit whatever needs they want with it... related or not to Vista. It's their decision alone to make it commercial, shareware, freeware, opensource or flush it down the drain, because it's their intellectual property. For example, I am retrofitting WIM technology for a specific purpose, other than Windows Setup, and that API will be a part of a patent request. Nuhi is also free to do whatever he likes with the vLite API just for the sole reason he made it. 3) There are a lot of programmers using WIM in their projects, because it's a great piece of software technology. vLite just happens to be popular. Nobody were to ask Symantec, for instance, to release parts of the code from Norton Ghost 12 just because it's based on WIM or other free stuff. So, this is not just about some version number arguments here, it's about criticism on something to what nobody except the author has access. Experimentation was needed to make vLite possible and there is no way to predict for one individual how it's software would react in conditions that were not taking into consideration before that software was made. That's the entire point of the label "for personal use". It means if you are not happy with it, do something better yourself. Few or no programmers, even if you pay them, would have the nerves to make modifications or explain stuff to anyone regarding their intellectual property. And I say these because I have my own stuff and I'd react exactly the same.

what version info? AFAIK, ImageX and the WIMGAPI have identical functionality, the rest is up to you to script/code

It's normal to assume ppl know about wimgapi as there are only 2 major APIs for the WIM format: wimgapi / ImageX for free and SmartDeploy SmartWIM. wimgapi is out for almost 3 years.

It might be useful for you to know that the BCD store is a registry hive, add that option by loading it in registry

Now seriously, you can look in the vLite program folder for yourself...

fi you really want to modify and shrink, apply the WIM image to a formatted mounted VMDK partition, do the modifications and then capture it to a new WIM with the same settings as the initial one, or with max compression. This is the way to do it... mounting a WIM for R/W was not invented for major changes and it is very wasteful with compression and storage.

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.

There will be a "OEM Guide to vLite" soon in which I will also include this issue.

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.

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.

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.

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.

I add my sysprep drivers in folders in \WINDOWS\Driver Cache\I386. A quick workaround is to also add those files from the original CD to there. If not, there's no problem; sysprep won't break. Remember - resealing means windows in already installed in there and works, sysprep only does minor changes. If you do something that can actually break the process, you won't be able to complete the initial reseal shutdown.

As there's no Vista Embedded Designer yet, there's little or no use for regular users to this tool. Microsoft SMSv4 and BDD2007 use it to make unattended adjustments to Vista, and that's about all until now.

the network drivers that are installed by VMware and the vmount2.exe service require administrator privileges.

I'd call that a feature, not a problem...

it seems the -activated option is no longer available since beta, it now detects by itself if yours is OEM or not. Try it without parameters, and maybe with the licensing service disabled. I am still waiting for them to send me the OEM edition of Windows Server 2008. When I'll have something appropriate to experiment on, I will be able to provide more specific info.

It is called "Adolescent Eyes", and it's made for a 3-display desktop. I have also included individual parts. 3840x1024 2560x1024 Left<---------- ----------> Center <---------- ----------> Right

that's the entire point of using sysprep, yes.