hotfix slipstream script v2

[GreenMachine]

RoyalBox!

There was another thread about slipstreaming the security rollup, which got me thinking about DRIVER.CAB. I think you also mentioned about checking out the .cab files. It looks to me like DRIVER.CAB does, in fact, have some files that are updated. This and SP1.CAB appear to be the only ones (at this point). I decided to unpack them all, update tham all (if necessary) and repack them all (regardless). I don't think that should matter for the .cat files, it is the files, and not the cabs, that are signed. (I hope ...). There was also a link to the MS Site, which is worth reading. After reading that, I decided to automatically update DOSNET.INF in the [ForceCopyDriverCabFiles] section (fortunatly at the end), and the [OptionalSrcDirs] just afterwards.

I also decided to use SVCPACK.INF to install the other updates, like MSJavaVM, DirectX, etc. To that end, I have a few more hotfix directories, that determine both the execution order and the switches. I need to run WMP9 before the corresponding hotfix, and QCHAIN.EXE at the end. I also now use the Unatteded switch instead of Quiet, so there is animation at the T-13 point.

I've tested it with all hotfixes installed/slipstreamed except 4 non-critical, and HFNetChk, and it all jives.

In terms of 817778, I have determined (in my own mind...) that it needs the shell to work, and running from SVCPACK.INF, or CMDLINES.TXT, the shell is not loaded. I'm afraid I will finally need to use GuiRunOnce HERE'S WHY (read the Choosing a Method for Automating Post-Installation Tasks section) ... know any good guides ...

For the rest of SuperhumaN's questions, I haven't the foggiest. They work for me.

I use HFNetChk, an alterantive to QFECHECK. Don't have the download, but MS has it.

[royalbox]

@greenmachine

Thanks! A lot of info there to read, looks like you've done your homework on it! I'll probably just wait now until aaronxp publishes it and try it out, but I'll have a look at those links anyway just out of interest.

Thanks again for all your help on this over the past few weeks.

[royalbox]

OK,

I was going to remove my script to avoid confusion as I thought aaronxp was going to post a script on his site but I completely misunderstood.

I've updated mine again to include 'driver.cab updating' as suggested by greenmachine. I tested this and saw many files getting updated so it should be worthwhile, though I haven't installed xp with it yet.

I enjoy working on this when time allows and will continue doing so until someone posts a better one. (probably greenmachine as he knows a lot more about how windows setup works than me!).

@greenmachine or aaronxp

Forgetting about slipstreaming for the moment, what was the problem with instaling service packs using the $oem$ folder that caused the info to be moved from the site? I don't get much time to look through all the posts at the moment.

Many thanks.

@greenmachine

Removing the /q switch and just using /n /u /z, was that just so you can see what was happening during installation? I take it there is still no user interaction required?

Thanks again.

[Aaron]

@greenmachine or aaronxp

Forgetting about slipstreaming for the moment, what was the problem with instaling service packs using the $oem$ folder that caused the info to be moved from the site? I don't get much time to look through all the posts at the moment.

Many thanks.

1. The hotfix batch was being executed from GuiRunOnce, and I have spoken with a contact from Microsoft on this who says that WFP may interfere

2. QCHAIN.exe wasn't used

3. A wrong switch was being used

It was ok for most people, but some other had issues, which is why I removed it.

[royalbox]

@AaronXP

Ok, many thanks for the info.

@everyone

I've updated the script yet again so that it now automatically updates dosnet.inf, as greenmachine was saying previously, with the required...

[OptionalSrcDirs]

svcpack

I don't like copying other peoples ideas if I can help it but this is one more thing the end user of the script has to worry about so I put it in. I hope you don't mind greenmachine.

[GreenMachine]

I'm flattered. If I wanted to keep it for myself, I probably would just be a lurker. Glad it helps.

[specialk]

Greenmachine, have you posted your script that updates the [ForceCopyDriverCabFiles] of the DOSNET.inf file? I've been curious since reading the slipstream installation guide on MS's support site a while back as to why nobody has done this.

[royalbox]

I've just read the microsoft article regarding the [ForceCopyDriverCabFiles] in dosnet.inf. It strikes me that if you add the updated file names to this section then there is no need to update driver.cab as the whole idea, as far as I see it, is so that the updated files are used rather than the ones in driver.cab. If on the other hand you updated the files in driver.cab then it's ok to use them anyway so there would be no need to add them to [ForceCopyDriverCabFiles]. Would that not be the case?

I started adding a section to my script to update dosnet.inf as greenmachine suggested but realized I need to give it some more thought. If you do all your hotfixes at once there is no problem but if you later just add 1 or 2 to update the i386 folder (the output folder my script uses) then dosnet.inf will just contain these new file names and all the file names from previous hotfixes will no gone.

You might say why not just 'add' the file names to the existing updated dosnet.inf? Well, the [OptionalSrcDirs] section has to be added to dosnet.inf so the file names would be added to this section at the end of the file and not the [ForceCopyDriverCabFiles] section. Obviously this would mess things up. I don't want to rely on 3rd party apps to do search and replace either.

Any ideas on that welcome.

[GreenMachine]

That must have been the short article I passed you ... The other one is actually quite a good reference, though not exactly easy reading. (See previous posts for links)

Yes, updating the [ForceCopyDriverCabFiles] section is to allow updating files inside, without updating the cab itself. This, I would think, is the prefered method, as the system will look in the I386 directory, find the file, and not need to extract it. Updating DRIVER.CAB is, perhaps, not needed. I do the [ForceCopyDriverCabFiles] thing, because I think it the better way, but I update the DRIVER.CAB for two reasons (Three, if you count my sometimes compulsive tendencies...) Firstly, I do not want to have any outdated files on the system. I do not see that it would ever help me. Secondly, I was thinking about all the cabs, and I extract, update and recompress all of them (See point three above). This way I do not have to treat it as an exception, it is just one in the loop like the others.

In terms of updating DOSNET.INF, my approach is this: I always start with DOSNET.INF (along with over 5000 other files) off the distrubution CD. I slipstream the latest service pack (I think this updates DOSNET.INF, but I do not know: I wait till slipstreaming is done before touching it.) At that point I take the file, and assume that the [OptionalSrcDirs] has not been added, and that the [ForceCopyDriverCabFiles] is the last section. I loop trough all files to be slipstreamed, and if they exist in the DRIVER.CAB file, then I add them to the end of DOSNET.INF (with the ECHO >> DOSNET.INF append option). After all the files have been added to the list, I add the [OptionalSrcDirs] section. Note that I can no longer add any files to the [ForceCopyDriverCabFiles], as this section is now closed. (That is one reason to start fresh each time.)

I think I just realized that above is kind of what you said... I do not have the problem of an updated DOSNET.INF, as I start with a new one each time. In fact, my staging area only contains files that are NOT on the CD (WINNT.SIF, CMDLINES.TXT, INSTALLS.CMD, *.REG, HOTFIXES, UPDATES). Each and every time I create a CD (or ISO) I go through the whole process, from rip to burn. It takes about 10 minutes, but it is a click once and wait thing, so that is OK.

Basically, my ideas on the subject: Start from a known state each time (virgin DOSNET.INF, un-service packed files). Search and replace is messy at best. This also allows you to remove superceeded fixes.

[specialk]

Once again greenmachine, is there some way I can get a copy of your script? :-)

[GreenMachine]

Sorry, specialk, I was not ignoring you. I posted it HERE

[specialk]

LOL, you weren't ignoring me bud, I saw your post and got your script and am most grateful. Keep up the excellent work

RoyalBox, I was thinking about your dilema about updating DOSNET.INF. Correct me if I'm mistaken, but in your current build of your script, you update DOSNET.INF in the \etc. directory before you copy it to the i386 directory. Why don't you copy it first, then update the DOSNET.INF in the i386 directory. That way, if somebody wants to add a hotfix, you have a fresh DOSNET.INF sitting in the \etc directory and you don't even have to bother searching through it to see what's been added already. You can just add everything, and there will be no worries about having multiple references to the same hotfix. Just my 2 cents