Jump to content

Hotfix Slipstreaming


GreenMachine

Recommended Posts


GreenMachine, it looks like your links for the script are not on the site any more.

I would love to get my hands on this script since it fixes a big problem -- I want to use RIS to roll out Windows XP, but post-SP1 hotfixes modify ntoskrnl.exe and so I can't create a RIS image unless I can either slipstream the hotfixes into my I386 folder, or the method used here -- just put all the hotfixes in a script to run after setup.

Anyway, when I try any of GreenMachine's links, I get 404.

Link to comment
Share on other sites

I want to use RIS to roll out Windows XP, but post-SP1 hotfixes modify ntoskrnl.exe and so I can't create a RIS image unless I can either slipstream the hotfixes into my I386 folder, or the method used here -- just put all the hotfixes in a script to run after setup.

I think you are a little mistaken about this. Let me know what your problem is in a little more detail and maybe I can help you. :)

Link to comment
Share on other sites

Okay, here's the situation. I'm rolling out XP. I want to use RIS for speed and so everyone gets the same build. I want the XP that gets installed to have as many of the programs we'll be using as possible, but for right now I'm stuck just on the Microsoft stuff.

I ran RISETUP on my server and had it copy over the install files from my Windows XP CD-ROM. The CD has service pack 1 applied already. (It's a gold volulme license key CD from Microsoft, not something I slipstreamed myself.)

I boot a computer using the RBFG.exe boot disk. The machine finds the RIS server and XP gets installed.

I go to the newly created machine and run Windows Update to get the latest hotfixes, .NET framework, stuff like that. At this point, I've got XP SP1 with all the latest updates and Microsoft software (DX9, .NET framework, etc.) Before going any further I want to put an image of that system back up on my RIS server.

But I can't. I run riprep from the RemInst share on my RIS server, and I get the error message "The RIS server to which you are attempting to post this installation does not have the correct CD-based image..." This error is discussed in MS KB article 324573 -- http://support.microsoft.com/default.aspx?...kb;en-us;324573

Some hotfix I installed modifies ntoskrnl.exe. The version on my RIS server is 5.1.2600.1106 and the version on my new XP box is 5.1.2600.1151. Because of the mismatch RIS won't accept the OS image. (I'm not sure which hotfix modifies ntoskrnl.exe, maybe it would be easiest to just not apply that one and run it in a script after the OS is installed...)

My plan was to create an install of XP that's got all the latest hotfixes applied. This looks to be extremely time consuming. I'm thinking now that the easiest thing will be a batch file to run Qchain and all the hotfixes I want. As new hotfixes come out, I'll just need to modify by batch file and make sure the hotfix executable gets into the right folder.

It's very annoying that I can slipstream a service pack, but can't (easily) slipstream a hotfix. The Microsoft suggestion described in http://www.microsoft.com/WindowsXP/pro/dow...p1/hfdeploy.asp involves expanding the Qxxxxxx.exe hotfixes, finding the latest binaries, and replacing the compressed binaries in my RIS i386 folder with the ones from the expanded hotfixes. Then you have to make a list of all the .cat files as well. For twenty-two hotfixes, that's WAAAAY too much work. I'm getting paid by the hour but I need to get this job done too :)

Thanks for taking the time to read all this! And thanks for fixing your link GreenMachine. Mabye my answer is there.

Link to comment
Share on other sites

The easy fix is to slipstream the hotfixes. You do not need to run them manually once per machine, and the files you mention will be up to date. Though I do not use RIS, the script I use does have an option to just slipstream the hotfixes. The script is based upon the document that you quote, and all the steps in that document have been automated. For good measure, I also update the CAB files, and the ntdll.dll in the systems32 subdirectory. Though you may need some minor modifications for RIS, this is a valid solution to the problem you describe. Again, if I can help you specifically with this script, PM me.

Link to comment
Share on other sites

GreenMachine: RIS is a totally different beast, and because it's in a corporate environment and there is a lot of licensing you have to deal with, hacking up the files is not really an option and I definately wouldn't recommend it.

ipierce: The reason I asked you about RIS is because I use it myself. I have a technique that I use that does not require you to use RISPREP. I do not like the idea of using anything other than a base image because every time you need to change something you have to redo the image. You can find a HOW TO for RIS that I am working on currently here on my website. It is not completed yet, but there is a lot of information. There is a complete section for RIS as well as a section for automation.

To give you an idea of what I do... I use a base Windows image with no service packs installed. If you have tried to slipstream SP1 you have probably run into the problem with BSOD on the boot to GUI mode. This is caused by the lack of SP4 on your domain controller. It's possible that you haven't tried this, or that you aren't using 2000 Server as your domain controller... I was just pointing that out. Anyways... I have edited the Client Installation Wizard screens to allow for customization, asking versions of different software that you might want to install, and questions such as PC type (laptop, desktop...) and remote locations (we have 14). Using a method I devised (Microsoft and everyone else I have spoken to said it wasn't possible) I pass those variables to the registry for use later... During the GUI Mode setup when cmdlines.txt runs I install the VLS package for DirectX9.0b as well as our IEAK package and any HKCU keys. On GuiRunOnce I have it launch a file that installs SP1, places an item in the RunOnce and reboots the PC. Second boot the RunOnce item runs and installs all hotfixes (rollup, critical, recommended), places another item in the RunOnce and reboots again. Third reboot the RunOnce installs all of our standard software that goes on every PC and then launches a script that pulls the variables passed in the CIW and installs the specified versions, places another item in RunOnce and reboots again. Final boot RunOnce installs HKLM REG keys, moves the PC to the correct OU (dependant on the variable for remote location from the CIW), creates a log file locally and on the server, sets the local adminstrator password and cleans all of the temp files and folders off of the PC and reboots again.

I would be more than happy to give you a hand in setting something like this up. I love to help and RIS is my forte. :)

Later!

Link to comment
Share on other sites

Well, I was able to get RIS to do what I wanted, by tricking it. If you read the stuff in the KB article 324573 you'll see that RIS checks the version of ntoskrnl.exe that you copied up from your Windows installation CD against the version of ntoskrnl.exe that resides on the machine you'd like to RIPrep and use for future images. If the versions don't match, the RIS server barfs and won't let you upload the image. (This to me seems like a pretty glaring flaw in RIS implementation, one that stems from the use of Single Instance Storage. SIS made sense when I couldn't buy a 78.4 GB HDD... now it's just using CPU cycles to save room on a NTFS partition that is in no way full. But I digress)

The upshot is that if you apply a hotfix that updates ntoskrnl, you can't stage that image back to the RIS server.

My solution: I went through the back door. I just replaced the original ntoskrnl.exe on the RIS server with the hotfixed ntoskrnl.exe from the workstation I wanted to RIPrep. Error bypassed :)

For what it's worth, I did use GreenMachine's XPCREATE application to create an ISO for Windows XP with all the hotfixes and optional components (.NET framework, etc.). I pointed RISetup to the I386 folder that XPCREATE made, and then rolled out a workstation using RBFG and pulled down the XPCREATE I386 image. The OS installed, and then all the hotfixes got installed. But the particular hotfix that updates ntoskrnl.exe didn't get slipstreamed into I386; it was run towards the end of Setup on the new workstation. So I still ran up against the original problem of mismatched ntoskrnl.exe on RIS server and new workstation. That's when I decided it would probably be much easier to make an end run around the whole hotfix process and just manually patch ntoskrnl.exe on my RIS server.

When installing from XPCREATE's I386 folder, all the hotfixes installed silently -- except for two. The first one is KB817778, and it threw an "invalid arguments specified" error. My guess is that it's not the type of hotfix (TYPE1, blue/white icon) that it appears to be based on its icon. Also, Q823718 asked if I wanted to reboot now; maybe it was miscategorized too. Based on the icon it's a TYPE2 but it wasn't completely "silent."

Thanks for your help with this project guys. Now I'm off to create an administrative install point for Office XP...(/me crosses fingers) and install that on my target machine. GreenMachine your XPCREATE is quite a piece of work and I'm glad I found it!

Link to comment
Share on other sites

  • 2 weeks later...

The RoyalBox HotFix SlipStreaming Method has come a ways since I first started this thread, so I thought I would give a brief progress report.

Firstly, I've added the GuiRunOnce section to the CD creation process. Five types of files can be run from here:

- Type I Hotfixes

- Type II Hotfixes

- Switchless installers

- MSI installers

- MS Packaged MSI installers (in .EXE format)

This, combined with the OPK or MSFN repackaged versions of MDAC, WMP9 and DirectX allow the script to produce a CD that has zero recommended or critical updates showing at Windows Update, without the need to manually edit one single file (WINNT.SIF is generated by Setup Manager)

Secondly, the Type I hotfixes are now run using the /O /U /N /Z switches. The newly adopted /O switch decreases installation time dramatically. This switch has the side effect of disabling the OEM driver search that causes Type I hotfixes to take a considerable amount of time per hotfix if run from the SVCPACK.INF / CMDLINES.TXT portions of setup.

Lastly, for ease of use, I have integrated a primitive TUI menu, allowing the user to select different options or sections of the entire process.

The basis for this whole project is to be able to produce the most up to date XP CD possible, with as many outdated files as possible removed from the CD, and replaced with the updated file versions. Neither speed, nor disk space were major concerns.

There has been much debate about which Hotfix Slipstreaming Method is best, or truest, or biggest, or fastest. For this reason I have compiled a comparison chart of a few of the different methods presented on MSFN. If statistics, numbers and hard facts are your concern, check out the results HERE!

Happy Slippin'!

Link to comment
Share on other sites

GreenMachine: Fantastic work on that comparison chart! It was really informative as I'm trying to work out what solution I like best. Generally I like to keep as "hands-off" the install source as possible to stay as close to the Microsoft-supported realm as I can. Blaster and Welchia, however have really pushed me into the slipstreamed hotfix world, and it's been a wild ride. Thanks for the info and keep up the good work.

Link to comment
Share on other sites

Thanks, baliktad. I gotta give credit to you, for tipping the scales in my favour with the /O thing. Who ever would'a thought!

I agree with you about staying as kosher (or orthadox) as possible. The slipstream only option I propose is simply an automated version of the process outlined by MS HERE and HERE. I consider that to be safe, even in a corporate environment.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...