[How To] Unattended RIS Installs V2

[RogueSpear]

In order of appearance, this guide currently covers:

AutoRIS

Windows XP Service Pack 2

jcarle's Compression Bin

RyanVM's Windows XP Post-SP2 Update Pack V2.0.5

nLite V1.0 RC7 (MSFN Forum)

XPize MCE V4.3

Bâshrat the Sneaky's Driver Packs V6.03.4 (MSFN Forum)

04/12/2006

The scripts have all been removed from this thread as they have turned into a project of their own. They still work with RIS though, so if you like them and use them, they can be found here.

This is likely the last update I will make to the guide. Everything described here can be done automatically, more easily, and with far less chance for error using either my utility AutoRIS or Fencer128's utility RISult. So at this point, the guide is really here for those who like to get into the nuts and bolts of things.

12/31/2005

nLite V1.0 RC4 tested and works.

XPize V4.2 tested and works.

Added a download link to additional NIC drivers w/ RIS specific .INF files.

All of the scripts have been updated and are now downloadable.

This guide will only be minimally updated going forward. At this point it's really for educational purposes more than anything. With AutoRIS reaching V1.5, the entire procedure has become fully automatic and practically bomb proof. You would have to be nuts to go through all this manually now.

11/26/2005

nLite V1.0 RC3 tested and works.

Rewrote the entire RyanVM Update Pack section to bring it up to current.

Step 8 in the BTS DP section has been removed as it is no longer necessary.

Minor tweaks and updates for readablility

Eliminated the Five Archives from the second post in the thread. They have been replaced by my addon pack

10/11/2005

nLite V1.0 RC1 tested and works.

Now there is a tool to go along with the guide. AutoRIS will automatically do most of the chores outlined in post #1 of this guide. In other words, not the scripts.

10/04/2005

Major ommission found by erw987213b regarding copying back over the compressed .inf files prior to RVM integration.

nLite V1.0 RC1 has been released but not yet tested.

10/02/2005

Initial posting

Introduction

The intended audience for this guide is an IT professional who already has a basic understanding of RIS and can set RIS up to work in it’s “out of the box” form. This guide was made using Windows 2000 Server so I cannot guarantee that everything is 100% identical under Windows 2003 Server. My guess would be that the differences are minute, but even those tiny differences can mean the difference between something working or not. As I have the time and opportunity to run through everything using Windows 2003 Server, I will update the guide appropriately. Be forewarned that all RIS work done by me using Windows 2003 Server will be, at a minimum, using Service Pack 1, and in all likelihood will be done using R2.

Everything I am going to outline can easily be done in batch, VBscript, etc. and in fact, I have created a utility for doing this called AutoRIS. As well, Fencer128 has made a batch script called RISult. They each work a little bit different than the other so you should read over the threads for both before using either. AutoRIS more closely approximates what I outline here in this guide. I am presenting the guide so that you know what is going on in the background and to open up my procedure to the scrutiny of others. Windows XP setup and RIS are complex. We're dealing with literally thousands of files. There are a lot of solid rules but there are also a lot of "gotchas" that you need to be aware of. It's these anomalies that will get you in trouble real quick. I've spent literally hundreds of hours working through all of this and I'm sure that there must be some things I have left out. I am an imperfect human and welcome any constructive criticism and help to make this a better guide.

Lastly, you will see some blatant copying of sections from the first guide into this one. With the length of this thing, I had to make things easy somewhere.

A Short Discussion of PNF Files

You will soon begin to hate PNF files. I do anyway. Not because of what they do, but rather because you are forced to jump through hoops with these things when it comes to a RIS based install. From the Microsoft Glossary:

A precompiled INF File. Windows creates a PNF file for each INF file to facilitate efficient processing. A PNF file includes information about the content of the original INF file, as well as the name of the INF file and other file attributes. Setup uses the PNF file instead of the original INF file. If a PNF file does not exist, Setup generates one for the INF file. For vendor-supplied INF files, the information contained in a PNF file also includes the location of the original INF file.

Ok so what does that mean? There's a few things to consider here. Through experimentation and a little conjecture, I am guessing that Windows setup somehow processes these PNF files a whole lot faster than it would INF files. Why else would Microsoft go through the trouble of creating these things? Well security could be one factor. Since setup will generate a PNF file, if one does not already exist, from an INF file, I'm going to go out on a limb and suggest that the slightest change to an INF file would then make it processed differently than the PNF. For instance if have an INF and it's corresponding PNF and decide to edit the INF to add another hardware ID, the PNF will not enumerate that hardware ID.

With RIS we can actually create PNF files for INFs that don't have a corresponding PNF already by restarting the BINL service on the RIS server. I'm going strictly on theory here, but I would guess that if you have PNF files for all of your INFs, that the setup process may go a little faster. For NIC cards not natively supported by RIS, the PNF file seems to be mandatory. But then again so is the INF file. I don't quite get this as it would seem the PNF should be enough from what I've read in Microsoft's documentation. Further, it seems that the only PNF files required are those for non native NIC drivers. I've been unable to find a good documented description of PNF files on Microsoft's web site or elsewhere. Everything I’ve found amounts to the second paragraph of this section.

With a media based installation, there are no PNF files on the disc. They are generated by setup. If you look inside %SYSTEMROOT%\INF you'll find hundreds of INF and PNF files. RIS it seems makes use of these files during setup, again I am guessing for a potential boost in install speed. The trick we need to accomplish in optimizing our RIS install with RyanVM's Update Pack (from here will be referred to as RVM) and nLite is to make our source look as much like a media based source as possible. As of now both projects do not natively recognize a RIS install source and take the necessary steps to complete their job properly. So this will involve swapping out compressed and uncompressed files a couple of times.

Why All the Fuss?

So that you understand WHY we are doing this I will present an example issue. There are many files, but as an example RVM contains a file called SWFLASH.IN_ and a default RIS image will contain a file called SWFLASH.INF. These are the same files, only the RVM version is cabbed (compressed) and it's a newer version, hence one of the major purposes behind RVM. So the problem is that you will end up with lots of files in both compressed and uncompressed formats in your source. This can not only foul up the RVM integration process, but who knows what you're going to get on your workstation installs. Now Shockwave Flash obviously isn't too important, but there a lot of updated DLL files and device driver files where I'm sure this would be fairly critical. The secondary issue is the PNF files. We want to make sure that at the end of this process we have good, valid PNF files that indeed correspond to our INF files. Since some of the INF files themselves are updated (like SWFLASH.INF), we will need to generate a new PNF to go with it. If you haven't died of absolute boredom or information overload by now, keep reading.

Preparing Your RIS Image

1. Create a RIS image on your RIS server using, preferably, a Windows XP Gold (no SP1) CD slipstreamed with SP2. Slipstreaming SP2 over an SP1 source will work. Once you have done this, TEST IT! If it is not working, there is no sense in continuing on. If the test is successful, make a backup of the i386 directory someplace and rename the directory to something like “i386 (Original)”. We will be making lots of backups of things along the way in this guide. If you are either foolish or cocky enough to think you won’t make any mistakes, then by all means skip this process. But I can tell you that I’ve saved countless hours because of all the backup directories I keep when doing something like this. I have a directory called RISDIRS and inside of that are directories called i386-1-Original, i386-2-AfterRVM, i386-3-AfterNlite, and so on. This makes it easy to go back and compare and see what’s going on.

2. Create a directory called RISTEMP in the root of your hard disk. This will be the base of operations for everything we do. Copy the i386 directory from your RIS image on the RIS server to \RISTEMP. Copy the tagfiles (WIN51, WIN51IP, WIN51IP.SP1, WIN51IP.SP2) from your Windows XP SP2 CD to \RISTEMP. In \RISTEMP create the following directories: IN_, INF-Compressed, INF-Uncompressed, nLite-RVM-Compressed, nLite-RVM-Uncompressed, and SystemFiles.

3. Delete the following files from \i386:

OSLOADER.EXE

MULTILNG.OSC

WELCOME.OSC

*.PNF

There is already a compressed version of the first three files in the directory so there will be no need to compress these files. We want to get rid of all the PNF files because we will later generate brand new ones. Be advised the all of the .PN_ files are not compressed PNFs. They are actually compressed PNG files, so don’t delete those.

4. Compress the following files and delete the uncompressed originals:

AVMC20.DLL

AVMCAPI.DLL

BOOTVID.DLL

DIAPI2.DLL

DIAPI232.DLL

DIAPI2NT.DLL

DIGIASYN.DLL

DIGIDBP.DLL

DIGIFWRK.DLL

DIGIHLC.DLL

DIGIISDN.DLL

HAL.DLL

HALAACPI.DLL

HALACPI.DLL

HALAPIC.DLL

HALMACPI.DLL

HALMPS.DLL

HALSP.DLL

IBMSGNET.DLL

KD1394.DLL

KDCOM.DLL

NTKRNLMP.EXE

NTOSKRNL.EXE

OSCHOICE.EXE

SETUPLDR.EXE

XLOG.EXE

*.NLS

*.OSC

*.SYS -- EXCEPT for KSECDD.SYS, NTFS.SYS, and SPCMDCON.SYS

5. Copy *.IN_ from \i386 to \IN_. These file are NOT compressed INFs. The are INI, INC, and INS files. We will need them later.

6. Move *.INF from \i386 to \INF-Uncompressed. Compress ALL BUT the following files and DO NOT delete the uncompressed originals:

BIOSINFO.INF

DMREG.INF

DOSNET.INF

DRM.INF

DRVINDEX.INF

HIVECLS.INF

HIVEDEF.INF

HIVESFT.INF

HIVESYS.INF

HIVEUSD.INF

INTL.INF

LAYOUT.INF

MSTASK.INF

NTPRINT.INF

WAVEMIX.INF

Move the newly compressed files from \INF-Uncompressed to \INF-Compressed. Move the 15 files listed above to \SystemFiles. Leave the remaining uncompressed INFs in the \INF-Uncompressed directory.

Update: 10/04/2005

7. Now for RVM and nLite to do their thing we need to copy over the compressed INF files (.in_) over to the \i386 directory. This is really the entire basis of what we're doing here. With the exception of the important INF files listed above, all other INF files need to be compressed. At the end of the entire procedure, back on the RIS server, the INF files will need to be uncompressed in order for PNF files to be generated. This is where most of my difficulties have arisen. Keeping it all straight.

RVM, nLite, and BTS all make changes to some of these important uncompressed INF files. Likewise there are also some compressed INF files that are modified (SYSOC.INF and SVCPACK.INF are modified by RVM as an example). Making temporary directories to store these files along the way is really important so that you don't accidentally copy the original DOSNET.INF into your final image when DOSNET.INF has been modified three times over. If you're handy with batch, AutoIt, or VBscript, a script or two that automates this procedure will surely save time and cut down on errors.

End Update: 10/04/2005

It is crucial that you get all of this right. I would go so far as to suggest making a checklist. I’ve lost countless hours of my life because I missed a file somewhere. In particular I wasted pretty much a whole day because I forgot to keep DMREG.INF on my list of files to keep. So read carefully. This is also a good reason to make a batch file do all of the heavy lifting for you.

RyanVM’s Update Pack

RyanVM's method of integrating hotfixes directly into the install source is hands down the best method of getting Microsoft hotfixes into your installation source. Using the /integrate switch with the hotfixes if far inferior for a number of reasons. Using RVM's method also makes for the smallest install source size. I've been using it right from when he released the first version and I can confidently say at this point that any teething problems are a thing of the past.

1. Download the RVM Update Pack Integrator, the Update Pack itself, and any applicable addons you wish to apply.

2. Run the Integrator. Point to RISTEMP as the source and destination. It's pretty self explanatory and it works perfect.

3. That's it. Pretty easy huh?

nLite

Provided everything is working up to this point, we can lighten up the load considerably here. I don’t go too crazy removing things. Most of what I get rid of is either innocuous or a security risk. Also I have tested integrating XPize V4 MCE Lite as a “hotfix” with nLite and so far I have not found any problems. Now for what I remove:

Applications

Briefcase

Internet Games

Paint - I use Paint.NET instead.

Pinball

Wordpad - Useless

Drivers

Asynchronous Transfer Mode (ATM)

Display Adapters - The new ones, not the old. I let BTS DPs take care of the modern video cards.

IBM Thinkpad

ISDN

Sony Jog Dial

Sound Adapters - I let BTS DPs take care of these.

Toshiba DVD decoder card

Wireless LAN Adapters - I let BTS DPs take care of these.

Hardware Support

Asynchronous Transfer Mode (ATM)

Bluetooth Support – The Microsoft Bluetooth stack is horrible. I’ve yet to see a native driver as bad as theirs. Plus this is a good security measure, placing a speedbump in front of he guy who’s gonna get cute by installing his own USB Bluetooth dongle.

Languages

I use United States English and don’t ever forsee needing to support anything else, so I nuke it all.

Multimedia

Media Center

Music Samples

Old CDPlayer and Sound Recorder

Tablet PC – If you need to support Tablet PCs, you’ll likely be creating a different RIS image for those machines, so don’t keep this thinking you’ll need it later.

Network

Client for Netware Networks – All of these are potential security risks besides being plain old unnecessary.

Communication tools

MSN Explorer

NWLink IPX/SPX/NetBIOS Protocol

Windows Messenger – You should integrate the most recent version of this application if you need it at all.

Operating System Options

Administrator VB scripts – These are commonly exploited by worms and spyware.

Disk Cleanup

Document Templates

File and Settings Wizard

Framework

Search Assistant

Security Center – Removing this could cause a problem depending on what AV/IDS solution you’re implementing.

Shell Media Handler

Tour

Zip Folders

Services

Alerter – All of these are security risks.

Messenger

Telnet Server

The Other Options

I always disable SFC, enable unsigned themes, leave TCP-IP alone (keeps the natives from effectively running P2P), Remove the MUIs, and keep the keyboard layouts.

So after you’ve gone through all of this, give it a shot and see that everything is working as it should be. When it comes to nLite the phrase “Less is More” has more than one meaning. The less you remove, the better the chances everything will work out right. Remember we’re dealing with computers that will be domain members. As such removing something like the Remote Registry service because you read somewhere it’s a good security measure, will only break the machine.

The BTS Driver Packs

This section of the guide is current as of 10/02/2005. It is to my understanding that Bashrat is reworking the entire Driver Pack integration and moving away from batch in favor of some compiled language. Therefore, this section may not be valid in part or in whole once that changeover has taken place.

For integration of the Driver Packs, I use Method 2 exclusively. Method 1 will work, but it takes longer and puts more stress on the network and the RIS server. Also I have not used the Keep the Drivers (KtD) option, so I can’t say how well this works or not.

1. Run the BTS_DPs_Slipstreamer_Vxxx.cmd file and chose Method 2. Follow the remaining instructions.

2. In your BTS working directory you will see a new directory called UWXPCD_ROOT. Copy the contents over to the RISTEMP directory on your local machine. Run the RUN_ME.cmd file as per the instructions. This will integrate the mass storage drivers and patch various .INF and .SIF files. When finished your directory structure is going to look as follows:

;SetupMgrTag
[Data]
    AutoPartition=1
    DisableAdminAccountOnDomainJoin=1
    MsDosInitiated="1"
    UnattendedInstall="Yes"
    floppyless="1"
    OriSrc="\\%SERVERNAME%\RemInst\%INSTALLPATH%"
    OriTyp="4"
    LocalSourceOnCD=1

[Components]
    AccessOpt=Off
    chat=off
    deskpaper=off
    freecell=off
    hearts=off
    hyperterm=off
    IEAccess=off
    media_clips=off
    media_utopia=off
    minesweeper=off
    msnexplr=off
    OEAccess=off
    pinball=off
    solitaire=off
    spider=off
    templates=off
    WMAccess=off
    WMPOCM=off
    zonegames=off

[Display]
    BitsPerPel=32
    Xresolution=800
    YResolution=600
    Vrefresh=75

[SetupData]
    OsLoadOptions="/noguiboot /fastdetect"
    SetupSourceDevice="\Device\LanmanRedirector\%SERVERNAME%\RemInst\%INSTALLPATH%"

[Unattended]
    AutoActivate=No
    DriverSigningPolicy=Ignore
    NonDriverSigningPolicy=Ignore
    UnattendMode=FullUnattended
    OemSkipEula=Yes
    OemPreinstall=Yes
    OemPnPDriversPath=
    TargetPath=\WINDOWS
    FileSystem=LeaveAlone
    NtUpgrade=No
    OverwriteOemFilesOnUpgrade=No
    CrashDumpSetting=0
    Hibernation=No
    WaitForReboot=No

[GuiRunOnce]
    command9 = "%SystemDrive%\D\BTS_DPs_Finish.cmd"

[Shell]
    CustomDefaultThemeFile="%WINDIR%\Resources\Themes\royale.theme"

[GuiUnattended]
    AdminPassword=encryptedpasswordgoeshere
    EncryptedAdminPassword=Yes
    OEMSkipRegional=1
    TimeZone=%TIMEZONE%
    OemSkipWelcome=1
    DetachedProgram=

[UserData]
    ProductID=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
    FullName="Your CEO's Name"
    OrgName="Your Company Name"
    ComputerName=%MACHINENAME%

[TapiLocation]
    CountryCode=1
    Dialing=Tone
    AreaCode=123
    LongDistanceAccess="9"

[TerminalServices]
    AllowConnections=1

[Identification]
    JoinDomain=%MACHINEDOMAIN%
    DoOldStyleDomainJoin=Yes

[RemoteInstall]
    Repartition=Yes
    UseWholeDisk=Yes

[OSChooser]
    Description="WinXP SP2 - Custom"
    Help="This will install Windows XP SP2."
    LaunchFile="%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com"
    ImageType=Flat

[Networking]
    InstallDefaultComponents=Yes
    ProcessPageSections=Yes

[WindowsFirewall]
    Profiles = WindowsFirewall.TurnOffFirewall

[WindowsFirewall.TurnOffFirewall]
    Mode = 0

You can name it pretty much whatever you want. I happen to name mine SP2.SIF. Just put the .SIF extension on it and place in the \i386\templates directory.

Adding NIC Drivers

This is where everything can get really hairy if you’re not paying attention. Now the easy thing to do (and I’ve been tempted) would be to just have all your INF and PNF files uncompressed in the i386 directory. And if you want to do that, it’s really not a huge deal. Here I will outline adding NIC drivers, generating new PNF files, and having it all be compressed.

Some newer NICs are not natively supported by RIS and in order to boot to RIS, you will need to download the drivers and integrate them into your source. With some vendors, you will need to either a.) get a special inf file for RIS or b.) modify the inf file so that it will work with RIS. In the case of modification, you are at the mercy of the vendor. The title of this section, right above, is a download link for the NIC drivers and the custom .INF files that I have put together so far. There is support for Broadcom, Intel, Marvel, and RealTek.

A couple of things I have noticed:

As of version 10.2 of Intel’s NIC drivers, there are seperate inf files for RIS installs. You no longer need to modify inf files for Intel NICs.

With newer RealTek NICs, they will no longer boot using Intel Pro drivers and you may need to rename the .SYS file from the drivers you download. I cannot possibly express how much I hate this company and that I wish they would simply vanish from the planet.

I am COMPLETELY UNABLE to get SiS mobo integrated NICs to boot to RIS even though they are claiming to be PXE V2.0 compliant. Actually I should clarify this - I cannot get it to perform a PXE boot at all, let alone boot to RIS. You have been warned. If anyone figures out the trick to this one, please let me know.

With 3Com NICs that require a RBFG boot disk, you should go to the BIOS and set to “No” or "Disable" the option for “PnP OS” or "Plug n Play Operating System."

1. Ok first, we deleted all of the .PNF files earlier in the guide and we compressed all but a few of the .INF files. We also made directories to store the compressed and uncompressed INFs. Those were just fine for earlier, but chances are RVM and nLite both added and deleted some INF files. Make new temp directories to work in for this stage. Move *.IN_ to a temp directory and decompress them. Then delete *.IN_, *.INI, *.INS, *.INC so that all that is left are .INF files.

2. Copy back to \i386 *.INF.

3. Copy back to \i386 all of the files in the IN_ directory created earlier.

4. Copy your \i386 directory back to the RIS server.

5. On the RIS server stop and then start (or simply restart) the Boot Information Negotiation Layer (BINL) service. This is necessary in order for the new NIC drivers to work.

6. Try to boot to RIS using a VM or a real computer. The first time you do, the DHCP may fail if you try to soon after restarting the BINL service. Once it does boot, when the text mode portion of the setup says “Please Wait…” at the bottom of the screen, you may have a long delay. This is when the RIS server is creating .PNF files for the INFs. When the "Please Wait..." goes away, you can halt the install if you like.

7. This Step is Optional and NOT Necessary. Once you have determined that everything is working, you can compress all of the INF and PNF files except for the following:

BIOSINFO.INF, .PNF

DMREG.INF, .PNF

DOSNET.INF, .PNF

DRM.INF, .PNF

DRVINDEX.INF, .PNF

HIVECLS.INF, .PNF

HIVEDEF.INF, .PNF

HIVESFT.INF, .PNF

HIVESYS.INF, .PNF

HIVEUSD.INF, .PNF

INTL.INF, .PNF

LAYOUT.INF, .PNF

MSTASK.INF, .PNF

NLHIVE.INF, .PNF (if you used nLite)

NTPRINT.INF, .PNF

WAVEMIX.INF (no PNF file is generated for this file)

If this all seems like a bit much, I would agree with you. You don’t have to compress your INF and PNF files once the image is back on the server for RIS to work. You DO have to compress the INF files (and some DLL and EXE files) when you're working with the image on your local computer in order for RVM and nLite to properly do what they do. It’s this last step where you don’t need to recompress everything.

And you may seriously decide to forgo compressing them in the end because if you later decide to add more NIC drivers you’ll have to decompress everything all over again. It’s definitely an imperfect system, one that could be made much easier and problem free with scripting, but it’s the best I’ve been able to come up with. In fact if you simply restart the BINL service at all, nothing will boot to RIS anymore. This has become less of an issue for me as I have integrated all of the third party NIC drivers I envision needing for a while. Also with AutoRIS, it takes me all of a half hour to go through what is in this guide from end to end.

Once you run through this a few times, you’ll get in a groove and get to know what is going on much better. The first time is always the worst.

Closing Words

This is for the most part blatantly copied from the first guide.

I cannot stress enough the importance of getting your RIS server up and running properly before attempting anything at all in this guide. If the basics are not there, you can't reasonably expect anything else to work. I have not and would not attempt to explain RIS itself and all of the little details about it. There are simply too many resources out there that do a fine job at that already. The same goes for all of the other products named here. They have support forums, web sites, etc. You will have to do a certain amount of legwork all on your own for this to work for you. I cut my teeth in RIS with the help of Mark Minasi's excellent book "Mastering Windows 2000 Server." I would not only recommend it to anyone involved with administering a Windows network, but would go so far as to say it should be required reading. I'm sure it has been updated to "Mastering Windows 2003 Server" and should be easily located at BarnesandNoble.com or Amazon.com. If you want it cheap try going over to Bookpool.

Remember basic troubleshooting. Start with as little as possible and work your way up, adding things one piece at a time. Yes it's very time consuming, but understanding how and why something works (or doesn't work for that matter) is so much better than just having everything handed to you on a silver platter. This way when a problem crops up down the road, and they will, you will have some idea as to how to fix that problem yourself.

Lastly, I am preparing to post my VBscripts that I use in cmdlines.txt and RunOnceEx. So stayed tuned!

Edited April 23, 2008 by IcemanND
fixed link to ryanvm's site

[RogueSpear]

Update 04122006

All of the scripts have been removed from this thread as they have become an ongoing project independant of RIS itself. You can read all about them here: http://www.msfn.org/board/index.php?showtopic=71890

A subset of these scripts is included with AutoRIS which you can find here: http://www.msfn.org/board/index.php?showtopic=57941

Edited April 13, 2006 by RogueSpear

[RogueSpear]

Removed

Edited March 27, 2006 by RogueSpear

[RogueSpear]

Removed

Edited March 27, 2006 by RogueSpear

[RogueSpear]

Removed

Edited March 27, 2006 by RogueSpear

[RogueSpear]

Removed

Edited March 27, 2006 by RogueSpear

[InTheWayBoy]

Nice call on adding the script source...gonna have to pick through that and see what I can use

I use AutoIt exclusively, as I find the syntax a litter easier to jump to from batch scripting...haven't tried any VBS yet, but it's on my my mind.

Thanx for the excellent updated guide!

[InTheWayBoy]

Just so you know:

In step 3 you say to delete osloader.exe since there is already a compressed copy...

But in step 4 you say to compress osloader.exe...

Just a little typo I would think, but just helping out where I can!

[RogueSpear]

@erw987213b, indeed it would appear that this is a major omission in the procedure. Thank you for pointing that out. I figured with a guide of this size I would have made boo boo or two, but this is kind of a biggie. Thank you for pointing it out. The guide will be updated ASAP.

[RogueSpear]

10/11/2005

nLite V1.0 RC1 tested and works.

Now there is a tool to go along with the guide. AutoRIS will automatically do most of the chores outlined in post #1 of this guide. In other words, not the scripts.

[Zoom7000]

This is a Great Guide! Thanks a million RogueSpear!

Mods: This one deserves a sticky!

Zoom7000

[RogueSpear]

11/26/2005

nLite V1.0 RC3 tested and works.

Rewrote the entire RyanVM Update Pack section to bring it up to current.

Step 8 in the BTS DP section has been removed as it is no longer necessary.

Minor tweaks and updates for readablility

Eliminated the Five Archives from the second post in the thread. They have been replaced by my addon pack

[RogueSpear]

12/31/2005

nLite V1.0 RC4 tested and works.

XPize V4.2 tested and works.

Added a download link to additional NIC drivers w/ RIS specific .INF files.

All of the scripts have been updated and are now downloadable.

This guide will only be minimally updated going forward. At this point it's really for educational purposes more than anything. With AutoRIS reaching V1.5, the entire procedure has become fully automatic and practically bomb proof. You would have to be nuts to go through all this manually now.

[Travelcard]

Sorry for such a n00b question. I did search - honest.

Where exactly do you place the cmdlines.txt? I have put it in a folder alongside $OEM$ i.e.:

D:\RemoteInstall\Setup\English\Images\WINDOWSXPSP2\

- $OEM$
- I386
- cmdlines.txt

But that didn't work.

Then I placed it inside the $oem$ folder but that doesn't appear to work either. It could be possible that my cmdlines.txt is being parsed, but just doesn't work. If so, does a log get created that I can check somewhere?

Cheers!

[Fencer128]

Hi,

I have a working cmdlines.txt inside of $oem$. I'm pretty sure that's where it should be. I suspect your problem lies with cmdlines.txt itself, or failing that possibly your sif file.

Good luck,

Andy