XPCREATE re-ISO re-Burn

[trainee]

Hi! I'm using XPCREATE to create my unattended install and I was wondering if there was a way to make a few changes in my included files (aka RunOnceEx, winnt.sif, etc.) and re-ISO and re-Burn without having to go through the entire process of integrating hotfixes and servicepacks again?

I have the hotfixes installing (GreenMachine's list) and I just want to tweak and add to the RunOnceEx. I prefer to make changes incrementally to help contain errors (personal preference).

I believe that I should put the changed files in the correct locations under CDROOT and then execute a subset of the commands in the xpcreate.cmd, specifically:

CALL :SETVARSCALL :MAKEISOCALL :BURNISOCALL :DONE

I think this works, but I want to make sure I'm not doing anything blatantly wrong or *bad* by doing this. Thanks in advance!

Since this is my first post I wanted to say thanks to GreenMachine for the awesome program and resources he has made available, AND to the entire MSFN community for all the information provided here. These forums have taught me a lot in the last week and have the greatest breadth, depth and accuracy of any XP forum I know of.

[GreenMachine]

You are welcome, trainee, and welcome to MSFN!

In theory, that sounds about right. You do have to know what you are doing ... My personal preference is to rebuild each run. Makes less variables to debug. I set DOCABS=NO, and pick up about 10 minutes per creation.

For testing, much can be tested seperatly from an installation. RunOnceEx can be easily tested from a command prompt or batch file.

[trainee]

@GreenMachine

Okay. I found another post where you mentioned keeping the XP source on the hard drive. This definitely cut down on creation time for me. But what are the side effects of DOCABS=NO? My wild guess is that the cd size will be larger because the new files will not get packed into the cabs. If this is true (big if), won't the install size also be larger? I admit that I have little knowledge of what is going on when the install runs, but it was my impression that most of the cabs get copied over to allow for PnP hardware etc.

For the original question: If you feel safer re-running the entire batch then so do I! I was really testing this one software/driver package that was giving me headaches. I was having difficulty recreating the initial install condition; ie. the package installs so many different files in multiple locations that uninstalling, and reinstalling did not produce the same order of events as the initial install. I made the decision that it was faster to re-burn and re-install than develop a full uninstall methodology. In retrospect there is probably a tool perfectly suited to this, but I have it working now and hindsight is 20/20.

Thanks again.

[GreenMachine]

DOCABS=NO will prevent XPCREATE from re-creating the DRIVER.CAB and SP1.CAB files. This results in non-updated files on the CD, but should have no side effects in a "test" environment: it simple reduces CD integrity in case certain files are updated, or needed again from the CD. In all production builds, I use DOCABS=YES. The size is the same.

[Vadikan]

I was wondering if there was a way to make a few changes in my included files (aka RunOnceEx, winnt.sif, etc.) and re-ISO and re-Burn without having to go through the entire process of integrating hotfixes and servicepacks again?

Interesting. Firstly, I've always thought that going through the entire process is not neccessary unless I'm integrating new hotfixes. RunOnceEx, winnt.sif, and basically everything in $OEM$ can modified, and then CDROOT can be burnt in a burning applicaton (Nero or Roxio). There are plenty of guides on the Net explaining how to burn a bootable XP CD with Nero/Roxio. I assume, GreenMachine is answering from the XPCreate standpoint, but, please, correct me if I'm wrong.

Secondly, if I need to integrate just a few new hotfixes, then I

• place them in the folders corresponding to the hotfix type

• move my previous CDROOT directory somewhere and

• use it as XPSOURCE

My personal preference is to rebuild each run. Makes less variables to debug.

That makes me insecure ;-) I'd better switch to svcpack.inf method for integrating just a few updates then.

I appreciate any comments. I can't find the similar discussion, but if one exists, please supply me with a link. Thanks for your attention.

[jrzycrim]

I've modified files (just $OEM$ stuff) in the CDROOT folder and used CDIMAGE.EXE to burn an ISO using CDROOT as the source. I've encountered no problems. I'm not sure about using CDROOT as the source when running XPCreate again. When I've added additional hotfixes/updates, I've always just used my original XP source. I copy my $OEM$ folder from CDROOT to FILESCD, delete CDROOT, then run XPCREATE. Nary a problem.

Cheers,

[Vadikan]

I've modified files (just $OEM$ stuff) in the CDROOT folder and used CDIMAGE.EXE to burn an ISO using CDROOT as the source. I've encountered no problems.

Me either, thanks for the comment.

[GreenMachine]

You can add and re-burn, but unless you follow 8.3 UPPER conventions, be careful of your CD File System options.

You can use CDROOT as XPSOURCE, but that would be very silly:

• You would loose the previous SVCPACK.INF
  
• DOSNET.INF would have many double listings
  
• TXTSETUP.SIF would be all screwed up if you added SATA drivers
  

in short FUBAR ...

XPCREATE is quite simple to set up with system files on one side and user files on the other. Adding a new update is as simple as dropping it in the correct directory, and go. One minute user intervention, and 30 minutes wating. Just enough time for a beer, or a couple vodka's, da?

[Vadikan]

You can add and re-burn, but unless you follow 8.3 UPPER conventions, be careful of your CD File System options.

This is clear.

You can use CDROOT as XPSOURCE, but that would be very silly:

• You would loose the previous SVCPACK.INF

• DOSNET.INF would have many double listings

• TXTSETUP.SIF would be all screwed up if you added SATA drivers

Well, none of these problems seem to really bother me, but I guess there are may be other issues. I have done that once, and got the system installed ok, but I haven't used it extensively enough to notice any problems. I'll take your word. 20 minutes of time saving are not worth any potential troubles. Thanks for your reply.

Just enough time for a beer, or a couple vodka's, da?

If I drank a shot of vodka during every XPCreate experiment, I'd be in serious trouble ;-))) Beer or Captain Morgan Spicy Rum with orange juice is fine ;-)

[jrzycrim]

I never use CDROOT as the source when running xpcreate.cmd. What I meant was creating an ISO from CDROOT using CDIMAGE.EXE (not xpcreate.cmd). If I need to add a couple of reg tweaks, apps, etc, I just modify/add the appropriate files in CDROOT\$OEM$ and create the new ISO.

Cheers,

[GreenMachine]

Just to be clear: DO NOT USE CDROOT AS XPSOURCE (Strange and mysterious happenstances will occour ... )

[Vadikan]

jrzycrim

I got your point.

GreenMachine

Thanks for clarification.

[GreenMachine]

It is true. Things may appear to be OK, but this easily results in slipstreaming the hotfix files without updating the registry with the necessary information. XPCREATE is NOT a non-destructive process.