[Ascii2]

Windows patches that support the "/integrate" switch may be integrated into a Windows 2000/XP/Server 2003 installation source easily by running the patch with the "/integrate" switch at the command line.


At first, it may seem that something like the following should work in a batch script to automate the integration of all patches that support the "/integrate" switch, but running it reveals problems:

FOR %%f IN (*.exe) DO "%%f" /passive /integrate:%~dp0Source

When the simple FOR loop to run all patches with the "/integrate" switch is run, update patches may run simultaneously. I have noticed that the batch file running the update patches continues to run the update patches while other update patche(s) (previously run) are still running. Patches start extracting or running while other patches are being extracted or running.

Most update patches (but not all) seem to integrate correctly while other updates patches are running. When this happens, integration may fail.


How can the integration of many update patches into a Windows 2000/XP/Server 2003 installation source be copletely automated when the update patches support the "/integrate" switch?

EDIT: I run all my integration tasks on Windows 2000 Professional with Service Pack 4

This post has been edited by Ascii2: 29 January 2010 - 01:35 PM

[strel]

Try with:

FOR %%f IN (*.exe) DO start "" /wait "%%f" /passive /integrate:%~dp0Source

EDIT: Fixed title.

This post has been edited by strel: 29 January 2010 - 06:36 AM

[Ascii2]

I do not like the start command; it is unreliable (it has multiple, optional string parameters, but does not require an order for the strings).

I have, however, tried the START command (but included the "title" parameter so the filename parameter is not interpreted as the title).

The START command seems to have yielded smoother results, but the same patches that may would not integrate as expected seem to fail to integrate.


I have been trying to integrate update patches into a Windows XP Professional with Service Pack 2 installation source.

Many newer Windows XP patches seem to be defective. Many update packages with update.exe with versions greater than 6.1.22.0 seem to fail to integrate correctly batch.

Run individually, the updates may integrate, but log (when logging is enabled) service pack level mismatch, undefined branch, etc. and may use the Service Pack 3 level patches. For these patches, shuffling the order of integration yields different results.

I speculate that the defect in the patches may not affect Windows XP with Service Pack 3.

What can be done to ensure that updates may be integrated correctly into a Windows XP installaiton source?

This post has been edited by Ascii2: 29 January 2010 - 01:03 AM

[Martin H]

Sorry cannot be of much help with this, other than maybe a few pointers...

If the "waiting time" is a problem during NT command script execution, then in my experience the 'start /wait'('' title isn't mandatory if the file to run has no spaces in filename), has no effect on the outcome, so i would instead do something like this:

for %%g in (*.exe) do %%g /q /integrate:%~dp0Source&ping -n 10 localhost

About SP-branch mismatch, then maybe the '/b' switch also works together with '/integrate'? :

for %%g in (*.exe) do %%g /q /b:SP2QFE /integrate:%~dp0Source&ping -n 10 localhost

Actually then i have no experience with using the '/integrate' switch to slipstream updates, since IMHO it's an ineffecient slipstreaming method; the updated binaries from the updates are slipstreamed into the source, but still all the updates are added to the source and set to run at T-13, just for getting the reg-entries and possible post-install commands applied, and also the updated binaries are left uncabbed in the source...

Personally, then i'm a big fan of the HFSLIP script for doing this kinda job perfectly...

[Ascii2]

Martin H, on Jan 29 2010, 07:45 AM, said:

About SP-branch mismatch, then maybe the '/b' switch also works together with '/integrate'? :

for %%g in (*.exe) do %%g /q /b:SP2QFE /integrate:%~dp0Source&ping -n 10 localhost

Actually then i have no experience with using the '/integrate' switch to slipstream updates, since IMHO it's an ineffecient slipstreaming method; the updated binaries from the updates are slipstreamed into the source, but still all the updates are added to the source and set to run at T-13, just for getting the reg-entries and possible post-install commands applied, and also the updated binaries are left uncabbed in the source...

Personally, then i'm a big fan of the HFSLIP script for doing this kinda job perfectly...

I also do not like /itegrate approach, however, t is sufficiently documented document

Not all recent update packages (within the past few years) have an SP2QFE directory, nor may it be desirable to use it when it exists., so a simple FOR loop integrating with the /b switch may not work.

I am trying to see if there is an order of integration method to integrate all updates and that would (hopefully) work for future updates. So far, i have not found an order that integrates all patches successfully.

In the past, I had rejected HFSLIP because it was not evident how patches would be integrated, and what other things it would do to the installation source. Without knowing what it does could make it difficult to reliable customize the installation source after HFSLIP is used.

This post has been edited by Ascii2: 30 January 2010 - 09:49 PM

[Ascii2]

Too many of the update patches' integration functions are defective and integration may not occur correctly when /integrate switch is used.

I shall try to find a utility that may integrate update patches and that does not require the Microsoft .NET Framework.

This post has been edited by Ascii2: 10 July 2012 - 02:39 AM

[strel]

Ascii2, on Jan 31 2010, 04:48 AM, said:

In the past, I had rejected HFSLIP because it was not evident how patches would be integrated, and what other things it would do to the installation source. Without knowing what it does could make it difficult to reliable customize the installation source after HFSLIP is used.

Fortunately is a script you can read, not a compiled appication.

[Martin H]

If you do not understand the HFSLIP cmd syntax, then you can PM me with any quastions you're having...

[Ascii2]

strel, on Jan 31 2010, 01:56 AM, said:

Ascii2, on Jan 31 2010, 04:48 AM, said:

In the past, I had rejected HFSLIP because it was not evident how patches would be integrated, and what other things it would do to the installation source. Without knowing what it does could make it difficult to reliable customize the installation source after HFSLIP is used.

Fortunately is a script you can read, not a compiled appication.

I see that now.

[Ascii2]

Ascii2, on 30 January 2010 - 11:28 PM, said:

Too many of the update patches' integration functions are defective and integration may not occur correctly when /integrate switch is used.

It seems that updates for Windows XP and Windows Server 2003 are available that might get around the defective updates integration problem (using the operating systems' AppPatch functionality).

The update is described:
http://support.microsoft.com/kb/928595

The update mayh be found:
http://download.micr...-custom-ENU.exe

Interestingly, the actual update supports Microsoft Windows XP family at the Service Pack 1 level (after support officially retired).

I have not tested the update yet.