Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

Integrating Many Updated Patches

- - - - -

  • Please log in to reply
10 replies to this topic

#1
Ascii2

Ascii2

    Advanced Member

  • Member
  • PipPipPip
  • 427 posts
  • Joined 31-December 06
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

Edited by Ascii2, 29 January 2010 - 01:35 PM.



How to remove advertisement from MSFN

#2
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag
Try with:
FOR %%f IN (*.exe) DO start "" /wait "%%f" /passive /integrate:%~dp0Source

EDIT: Fixed title.

Edited by strel, 29 January 2010 - 06:36 AM.


#3
Ascii2

Ascii2

    Advanced Member

  • Member
  • PipPipPip
  • 427 posts
  • Joined 31-December 06
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?

Edited by Ascii2, 29 January 2010 - 01:03 AM.


#4
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 802 posts
  • Joined 24-November 06
  • OS:none specified
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...

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#5
Ascii2

Ascii2

    Advanced Member

  • Member
  • PipPipPip
  • 427 posts
  • Joined 31-December 06

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.

Edited by Ascii2, 30 January 2010 - 09:49 PM.


#6
Ascii2

Ascii2

    Advanced Member

  • Member
  • PipPipPip
  • 427 posts
  • Joined 31-December 06
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.

Edited by Ascii2, 10 July 2012 - 02:39 AM.


#7
strel

strel

    segmentation fault

  • Member
  • PipPipPipPip
  • 629 posts
  • Joined 24-February 08
  • OS:XP Pro x86
  • Country: Country Flag

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.

#8
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 802 posts
  • Joined 24-November 06
  • OS:none specified
If you do not understand the HFSLIP cmd syntax, then you can PM me with any quastions you're having... :)

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#9
Ascii2

Ascii2

    Advanced Member

  • Member
  • PipPipPip
  • 427 posts
  • Joined 31-December 06

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.

#10
Ascii2

Ascii2

    Advanced Member

  • Member
  • PipPipPip
  • 427 posts
  • Joined 31-December 06

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.

#11
Guest_frankjohnson8_*

Guest_frankjohnson8_*
  • Guests
  • Joined --
That is a great site! I saw the information is very usefule!
Posted Image
Posted Image




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users