Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
CLASYS

Too many hotfixes to integrate?

Recommended Posts

I am just attempting to use the

WindowsXP-KBxxxxxx-x86-enu.exe /integrate:<path to image>

method repeatedly to update a vanilla image of XP SP2 OEM with about 60 or so hotfixes. [i am using the hotfix tool beta 1.0 for the "hard" cases like 885250, etc.]

All hotfixes are being added in chronological order.

As I add in new ones, the last ones added [it's in a batch file, but that isn't a factor; once the others are present, it won't work even if run manually from RUN, etc.] stop working. Batch file aborts; wants to send to MS, etc.

Is there an "upper limit" on just how many hotfixes the /integrate method allows?

Fortunately, the hotfix beta 1.0 tool seems to add in those final ones anyway, but what gives here?

cjl

Share this post


Link to post
Share on other sites

I have an update on the problem:

I added still more integrated hotfixes via the /integrate:<path to image> method, and the problem didn't worsen. Apparently, this problem only applies to two specific hotfixes, both fairly recent:

900725

896688

which I tend to integrate last due to their being pretty new.

Again, all works fine if I INSTEAD use the hotfix tool beta 1.0, but using the MS method it crashes merely because there are quite a few hotfixes in the image already, etc. [Currently, when the problem arose, I was attempting to put in about 12 more hotfixes than the set associated with Windows Update; there really are a whole lot more than those available! Also, I saw the need for some of them to obviously be a part of Windows Update, but they weren't added until more recently some of them have been added. But, as of this writing, there are even some that are the subject of recent security bulletins that still aren't in Windows Update! I can't believe that this should somehow "invalidate" them relative to hotfix integration, etc.]

Installing a system from the image seems completely fine; this is just an observation of a problem with the /integrate switch within these two hotfixes and only in this narrow context; it formerly worked when there were less prior-installed integrated hotfixes in the image. I am using a batch file to create the larger amount of those other fixes applied to a clean image. Just using the RUN command to use the integrate switch on either of these two makes it blow up in this circumstance, etc. So clearly, the use of a .bat file isn't the problem, etc.

any ideas?

cjl

Share this post


Link to post
Share on other sites

Well...one: IE6.0sp1-KB896688-Windows-2000-XP-x86-ENU.exe

Needs to be slipped into IE directly I do believe...

Not sure about the 900725 problem.

Share this post


Link to post
Share on other sites

I had some problems slipstreaming updates, i fixed this by running the updates from a batch file that ran at the first logon..

Just type the update.exe /? in a cmd box, youll see all the options then.

Mostly it is just update.exe /q or /quiet ..

Share this post


Link to post
Share on other sites

I am aware that a batch can be run LATER to add in all of the hotfixes, as each release generally is good enough to be able to self-update with regard to just about any hotfix. [The last time this wasn't true is if you needed to install on a disk larger than 127 GB and you didn't have SP1 integrated in already!]

The point is that I believe there is conventional wisdom that the ONLY thing "wrong" with the MS /integrate method is the sore cases such as 885250 I think it's called because of the inherent anomaly of the updated files inside, etc. It would appear that these two pretty new updates have some other sort of internal flaw associated with the /integrate function itself, such that if other updates are already integrated into the install image ["too many" whatever that number is, I apparently have exceeded it!] then they will refuse to integrate via that method, instead crashing in the attempt, yet install fine if these updates are added before so many of the other updates are added, etc.

But since the overall recommendation is to add in the integrated updates in chronological order, this means that these quite new updates are generally added in relatively "last" etc.

A related question: Is it REALLY necessary to have them ordered? Or is this just a matter of time efficiency?

I thought that as of SP2, the "QCHAIN functionality" is built-in, thus order would appear to be superfluous? Does it fix it up regardless, or am I missing something about some interaction elsewhere?

Also, please note that if you use the /integrate method to build the lists in SVCPACK.INF, the lists are updated chronologically; the NEWEST updates are at the top of the list, etc. Isn't this precisely the OPPOSITE of the recommendation? Thus, the "correct" way to build the list would be to have a REVERSE chronological batch file of invoking the /integrate method placing the EARLIEST update at the top of the lists within SVCPACK.INF?

In any case, you can lift the body of a batch file from inside of SVCPACK.INF to become the guts of a post-install batch file to be run at the first log-in or later that will have all of the /q /n /z switches set on all of the invocations of the name-shortened kbxxxxxx.exe forms of the fix files, etc.

cjl [attempting to rise above newbie status in this forum!]

Share this post


Link to post
Share on other sites

Yes, it's still pretty important to install patches chronologically, because you're patching a source that has no way of knowing if you're integrating an older file from an older hotfix on top of a newer file already in the source - the source you're integrating to isn't running, so the whole smart patching thing goes out the window.

Negating the need for qchain on a running system is nice, but when you're /integrate'ing a flat file source, how is it going to know if you're doing it right??? :) And some files get updated EVERY patch (and I can think of a few that if you break, Windows won't boot right), so it's even more important to be careful!

Share this post


Link to post
Share on other sites

So, the simple answer is that:

1) Hotfix integration is a convenience that works only if it works. If not, use an alternate method to get the hotfix into SVCPACK.INF. The hotfix beta 1.0 tool is probably fine, but if necessary do it by manual edit, etc.

2) QCHAIN functionality is meaningless during an install within an image; only applies to batch files run after the install is complete [or perhaps *almost* complete?]

3) Hotfix integration should be added in reverse chronological order to ensure that the SVCPACK.INF file has the file list re-reversed back to chronological order within the image.

Is this correct?

cjl

Share this post


Link to post
Share on other sites

896688: Got problems only through kb896688 /integrate but doing it through nlite integrated well!!! Remember that 896688 there are a lots of vers.... 3.7MB (cabinet), 4.1MB (cabinet) and the last one 4.8MB (security update) - Date published: 10/10/2005 the only one that works -

Be sure to download the right one!

http://www.microsoft.com/downloads/details...DD-CB365F6FD3C5

Edited by vanen

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...