Spheris

not possible to slipstream it, planned to be included in sp-3 as I know it right now but no plans for a bundling thru sp-2 the msi can be unfolded but the dlls and reg entries it creates as well as the account it creates are done with the OS up for now. It is an addon for now but 2.0 is being built for ground up installs due Q-3 '04

Medic, I'll recommend not slipstreaming 9b. It's been tried in house but only with limited success because the structure is registry wise much different from 8.1. but if you have to give it at go use the svcpack method which does seem to work so far create a sub dir with a sub path in the matching dosnet and svcpack infs and use the usual command switch

Look at it this way, you're not done yet. You'll find another part of it to tinker with. I know I always do So you'll have the idea to use for then if it needs it.

Fair enough, I did notice the q hotfixes were giving path trouble its by design but easy enough to fix you alter path in the extracted inf and change copyto target

could you point me to which one it was, the thread got a little confused towards the end I counted 7 scripts along the way. but not sure where others took up and yours left off.

You're welcome. It's not the best method by any means or the most flexible (the MS OPK) but it does give a place to start. I know we're terrible at providing much in the way of good documentation but we do make great marketing literature

Absolutely agree with you there. Even the OPK method comes up short on some key points and you compensated for them. Personally if I had my way I'd recommend some of these ideas at work. But I think I'd rather not have the forum turn into a brawl between ms developers and the engineers/admins/hobbyists. You guys are doing some truly inventive stuff.

Not quite correct medic, but a good alternate. And only because if you had to go to support with it, they'd probably scratch their head and hand the phone to one of us. Personally, I think its relative - the MS approved versus what can be home brewed if it works it works . Again, thank you for taking the time to show me your work.

Yours seems to the the closer of the two on this thread I'm still not quite following why there are so many variations on this when an established method exists that is supported. Again, I am impressed. very fine script work.

Interesting take on slipstreaming the files Definitely inventive and not far from some of the custom builds being done here. But I am confused as to which one of them actually is working. Seems not to be entirely stable depending on the user of script?

Okay, Ill bite Maybe I read that wrong but Medic, where is the slipstream?

I'd recommend looking back through the threads for the MS approved method. I've looked at medic script, though it does seem to appear correct, i've seen the same behaviour randomly as components are added, removed whether a flaw in the script or the installers handling of, I cannot determine quite yet and I will add in its defense. it is an intermittent failure. So don't blame the script or the OS yet.

only the hardware/software hotfixes apply for myself.. it depends entirely on your own end use for the OS and how diligent you are the security hotfixes are by and large issued to the users least likely to maintain their own ipsec and firewall settings for themselves if you have a knowledge of how to set your own security..those hotfixes can hold till a rollup comes along

very welcome I'll be getting together with aaron on the next few days to sort out all the download links and availability for the opk components

to answer the reversion to sp1 components not possible if done right best practice is to automate a sfc /cachesize=1536 command then followed with sfc /scannow to be carried out at first boot that takes care of the question and future possibility of overwrite by elder components

On a last note the notes on adding the dlls and such from the hotfixes to the i386 are best practice scenarios. Not requisite.

here's a quick guideline for you guys to follow. Though it looks like the majority are well on your way with it. Some incredibly inventive scripting happening with some of you. Now if we can just use those powers for good but seriously this is taken from my own cd. there is no means to update the sp1 or driver cab, nor is one needed if the hotfix packs are delivered correctly. DOSNET.INF {content} [Version] signature="$Windows NT$" DriverVer=07/01/2001,5.1.2600.1106 [Directories] d1 = \I386 d2 = \cmpnents\tabletpc\I386 d3 = \cmpnents\mediactr\I386 d4 = \cmpnents\netfx\I386 [OptionalSrcDirs] \I386\SVCPACK [Miscellaneous] ProductType = 0 MinimumMemory = 67108864 DestinationPlatform = i386 ServicePack = 1.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% SRVPACK.INF {contents} [Version] Signature="$Windows NT$" BuildNumber=2600 MajorVersion=5 MinorVersion=1 [setupData] CatalogSubDir="I386\SVCPACK" [setupHotfixesToRun] Q282010.EXE /Q /U /Z /N Q322011.EXE /Q /U /Z /N Q322069.EXE /Q /U /Z /N Q323183.EXE /Q /U /Z /N Q323255.EXE /Q /U /Z /N Q327979.EXE /Q /U /Z /N Q328310.EXE /Q /U /Z /N Q329048.EXE /Q /U /Z /N Q329115.EXE /Q /U /Z /N Q329170.EXE /Q /U /Z /N Q329256.EXE /Q /U /Z /N Q329390.EXE /Q /U /Z /N Q329441.EXE /Q /U /Z /N Q329604.EXE /Q /U /Z /N Q329623.EXE /Q /U /Z /N Q329834.EXE /Q /U /Z /N Q330994.EXE /Q:A /R:N Q330512.EXE /Q /U /Z /N Q330909.EXE /Q /U /Z /N Q331953.EXE /Q /U /Z /N Q331958.EXE /Q /U /Z /N Q810032.EXE /Q /U /Z /N Q810243.EXE /Q /U /Z /N Q810272.EXE /Q /U /Z /N Q810565.EXE /Q /U /Z /N Q810577.EXE /Q /U /Z /N Q810833.EXE /Q /U /Z /N Q811114.EXE /Q /U /Z /N Q811493.EXE /Q /U /Z /N Q811630.EXE /Q /U /Z /N Q812035.EXE /Q /U /Z /N Q812415.EXE /Q /U /Z /N Q814033.EXE /Q /U /Z /N Q814995.EXE /Q /U /Z /N Q815021.EXE /Q /U /Z /N Q815485.EXE /Q /U /Z /N Q816073.EXE /Q /U /Z /N Q817287.EXE /Q /U /Z /N Q817606.EXE /Q /U /Z /N Q818043.EXE /Q /U /Z /N Q818529.EXE /Q:A /R:N Q819696.EXE /Q /U /Z /N Q820128.EXE /Q /U /Z /N Q820291.EXE /Q /U /Z /N Q821253.EXE /Q /U /Z /N Q821557.EXE /Q /U /Z /N Q821581.EXE /Q /U /Z /N Q822603.EXE /Q /U /Z /N Q823559.EXE /Q /U /Z /N Q823980.EXE /Q /U /Z /N DX90AMDX.EXE /Q:A /R:N VBS56NEN.EXE /Q:A /R:N JS56NEN.EXE /Q:A /R:N QCHAIN.EXE DX9NTOPK.EXE WMP9MM2.EXE [ProductCatalogsToInstall] Q817287.cat kb282010.cat kb815021.cat kb819696.cat kb820128.cat kb820291.cat kb821253.cat kb821557.cat kb821581.cat kb822603.cat kb823559.cat kb823980.cat q322011.cat q323183.cat q323255.cat q327979.cat q328310.cat q329048.cat q329115.cat q329170.cat q329256.cat q329390.cat q329441.cat q329604.cat q329623.cat q329834.cat q330512.cat q330909.cat q331953.cat q331958.cat q810032.cat q810243.cat q810272.cat q810565.cat q810577.cat q810833.cat q811114.cat q811493.cat q811630.cat q812035.cat q812415.cat q814033.cat q814995.cat q815021.cat q815485.cat q816073.cat q817606.cat q818043.cat q819696.cat Q330994.cat Q818529.cat hotfix exe's go to SVCPACK dir cat files go to SVCPACK dir unpack of files to i386 is unnecessary - burn and install

/ switch is required for preinstallation - switch can be used post install in theory both will work, however, there have been varying degrees of failures when a hotfix was delivered out of context to the development and support teams ie, broken setup/non standard setup etc

at microsoft is the ieak kit for 6.0/XP that will enable you to make any preset config you'd like

modified grafix, stripped grafix, sometimes modified/impaired function and the like kind of interesting design work though. I think the mac mods are probably the cutest of the lot and just seems to irk the s*** out of the UI team

The OPK method does have one more flex to it which is used in house the cat and hotfix files are all that are required the second section describing the unpack isn't necessary if the dosnet and svcpack are modified to match up they'll install directly after self reg of the cd dlls and services with no interaction and no pop ups in the same manner that they were originally part of the cd itself without having to seed the unpacked dlls into the disc i386. the converse can be done with the unpacked files but still require the cat files in the svcpack dir also the -m switch needs to be upated to /u for the xp versions of the hotfixes some of them will respond to -m but the newer may not as support for 2k and xp diverge

not a problem or a bother to me But the idea of the forum as I understood from aaron was to refine and discuss/share alternates and ideas for the methods laid out already in the guide. And that is why the opk hotfix instructions are posted and explained the batch method itself has a good foundation and solid methodology but two things to bear in mind when the batch calls out, it switches context from win32 to win16 api's so there is always a stability risk second the native api method goes much more quickly in the time wait factor for it all to seed in not that the batch idea is all that bad of a thing and it does afford some flex in that you get to watch the readout as each hotfix is applied, which is educational at least. Or at least looks cool if your kids are watching while you test it out. but if a better method exists, usually its better to go with

It's funny that for years, MS has caught it in the head for buggy and crash prone systems. Funny enough, did a listcheck on actual bugs and the hotfixes for actual bugs (not the endless security issues that resolve through being aware and conscientious about their own ip security) only add up to less than 11 megs. Fairly impressive that the OS has finally reached a state nearing UNIX integrity. Thought I'll never say its approaching the elegance of Solaris

amari, absolutely correct and the svcpack method is the only method working at this time why their bothering with this batch nonesense is beyond me but it is fun to watch

scary way to kill a half an hour guys but it can beat watching tele, sometimes