[Dogway]

Hello, I have a workstation that isn't plugged to internet, so I download my hotfixes on the laptop and then I plan to move and install there.
I would like to know if there is any kind of hotfix installer because I'm aware of some issues if the installations are not done correctly in some way, in order, or after reboots, etc.

Actually I found RyanVM XP64 pack and everything is already unpacked, perhaps is there a way to integrate that on a LIVE OS?

Any help Id be grateful.

This post has been edited by Dogway: 29 July 2012 - 01:32 AM

[-X-]

To install, simply make a batch file in the folder that holds the updates with this content...

echo update post SP3...
for %%a in (*.exe) do (
start /wait %%a /quiet /norestart /nobackup )
pause

Then just run the batch file. You may or may not want the /nobackup switch. It's up to you.

And no, you can not use an update pack.

EDIT: I just noticed that you linked to an x64 pack is it XP x64?

This post has been edited by -X-: 29 July 2012 - 02:24 AM

[Dogway]

Thanks a lot! yes, it's XP x64 (in this case) but the question applies to any OS I think.
The laptop I use is x86, that's what I follow your list for mainly for slipstreaming. But on my studio workstation I have x64, and it's a bit of a burden to make a slipstreaming CD, so for the moment I'm only going to install the hotfixes.
I read this link and seemed very complicated, is it safe to run your script then? will the files install by order (maybe I need to add KBZ2510531 to force order?)

As for the update pack, it's ok, I will download them manually instead.

[xpclient]

@-X-, I use a similar batch file!!!! Just the switches I write in old style: /Q /N /Z

[tomasz86]

Dogway, on 29 July 2012 - 02:14 AM, said:

will the files install by order (maybe I need to add KBZ2510531 to force order?)

Normally the order should not matter unless something is messed up with the update itself. A higher number doesn't necessary mean that the update is newer

This post has been edited by tomasz86: 29 July 2012 - 02:36 AM

[Dogway]

tomasz86, on 29 July 2012 - 02:35 AM, said:

A higher number doesn't necessary mean that the update is newer

I have been mistaken then... I remember to read something about hotfix order for nLite, maybe that's another story...(?)

[tomasz86]

Essentially it would be the best if you installed them chronologically but in order to do this you would have to check the date when they were compiled, ex. the date listed next to the "BUILDTIMESTAMP" entry in the "update\update.inf" of each update.

If you don't want to make the things complicated too much you can just use this modified version of the -X-'s script:

echo update post SP3...
for /F %%a in ('DIR/B/OD *.exe') do (
start /wait %%a /quiet /norestart /nobackup )
pause

Just make sure that your browser/download manager doesn't change the date of the downloaded file (some do ).

This post has been edited by tomasz86: 29 July 2012 - 03:31 AM

[Dogway]

tomasz86, on 29 July 2012 - 03:28 AM, said:

browser/download manager doesn't change the date of the downloaded file (some do ).

ah yes, nice one, I had an addon for that. I'll try tonight.

[-X-]

tomasz86, on 29 July 2012 - 03:28 AM, said:

Just make sure that your browser/download manager doesn't change the date of the downloaded file (some do ).

What browser doesn't change the date? I tried FF, IE and Chrome and they all have a timestamp of when the file was downloaded.

[tomasz86]

-X-, on 29 July 2012 - 09:48 AM, said:

What browser doesn't change the date? I tried FF, IE and Chrome and they all have a timestamp of when the file was downloaded.

DownThemAll for Firefox doesn't change the date.

I thought that it was Firefox itself but no. By default all browsers seem to ignore the original date. I've just checked it again to be 100% sure and downloaded a few files using DownThemAll. One of them is Win2k SP4 and while the creation date is set to a few minutes ago the modified / accessed date is still the original one, i.e. 2003/06/20 and this date is used by the system.

This post has been edited by tomasz86: 29 July 2012 - 10:14 AM

[Dogway]

Ok, I already installed them, everything perfect, The only thing that got stuck was WMP11, that I needed in order to install its hotfixes later, at that point I just ctrl+s, installed manually and resumed.
Now I need to redownload XP x86 hotfixes as well, what a pain haha at least it's faster than extracting update.inf for each of them and re-timestamping.

Thank you!

This post has been edited by Dogway: 30 July 2012 - 12:30 AM

[Ascii2]

tomasz86, on 29 July 2012 - 02:35 AM, said:

Dogway, on 29 July 2012 - 02:14 AM, said:

will the files install by order (maybe I need to add KBZ2510531 to force order?)

Normally the order should not matter unless something is messed up with the update itself.

Unfortunately, there are quite a lot of defective update packages with defective installation, migration, or integration logic. So due care should be taken.

There are Appcompat (not sure of the spelling at the moment) updates to allow a target system to automatically workaround the problem. An example of one such update (which also supports Windows XP Service Pack 1 level) is the KB928595 update.

tomasz86, on 29 July 2012 - 02:35 AM, said:

What tomasz86 states regarding is correct.

A higher number doesn't necessary mean that the update is newer

The Microsoft Knowledge Base article numbering seem to be ordered ascending and in direct relation to the order that they are assigned. The updates typically are also assigned the Microsoft Knowledge Base article number.

[Ascii2]

tomasz86, on 29 July 2012 - 10:13 AM, said:

-X-, on 29 July 2012 - 09:48 AM, said:

What browser doesn't change the date? I tried FF, IE and Chrome and they all have a timestamp of when the file was downloaded.

DownThemAll for Firefox doesn't change the date.

DownThemAll is an extension for Mozilla Firefox. There is another extension that allows preserving the original timestamp; that extension is Preserve Download Modification Timestamp.

It should be noted that it is not accurate that DownThemAll (and Preserve Download Modification Timestamp) do not change the date; rather they do change the , and change it such that it matches that of the host copy. This distinction is important because it means that the correct timestamp might not always be preserved. This typically happens due to antivirus software locking the downloaded file longer than whatever amount of time is given to timestamp the file.

tomasz86, on 29 July 2012 - 10:13 AM, said:

I thought that it was Firefox itself but no. By default all browsers seem to ignore the original date. I've just checked it again to be 100% sure and downloaded a few files using DownThemAll. One of them is Win2k SP4 and while the creation date is set to a few minutes ago the modified / accessed date is still the original one, i.e. 2003/06/20 and this date is used by the system.

Windows Explorer on Windows 2000, Windows XP, and Windows Server 2003 family operating systems' Windows Explorer is able to retain when the Copy handler is used (the usual way downloading from an FTP site using Windows Explorer).

Browsers do not ignore the timestamp by default. The browsers typically retain timestamp information when it is available (view cached objects to see an example). However, it seems to be the convention that the browser not append the timestamp to a file and when a file is explicitly requested or specified for download.

[Ascii2]

For Dogway,

I recommend you examine my thread at:http://www.msfn.org/...treaming-order/ . The thread pertains directly to order of updates and also lists some information about updates being defective by design.

Also, I recommend that you run qchain.exe after running the . Although many patches should include the qchain.exe logic, many do not implement it correctly. FOr acticles regarding qchain.exe, see:
http://support.microsoft.com/kb/815062 and http://support.microsoft.com/kb/296861 .

To downloa qchain.exe go to: http://www.microsoft...s.aspx?id=23908

This post has been edited by Ascii2: 30 July 2012 - 10:31 PM

[Dogway]

Yes, I used "Preserve Download Modification Timestamp" addon.
While in the big picture the order was clearly ascendent it wasn't in a strictly manner:

KB931261 08/02/2007 18:28:20
KB925902 02/03/2007 13:12:08
KB932168 21/03/2007 16:51:12
KB929123 04/05/2007 08:06:26

I added the qchain.exe line just before the pause. But placed it in another folder to don't interfere with the "call all .exe in current folder" loop.
What I don't understand from reading the bulletin you offered me is that an example for installing the hotfixes is given using the update.exe program and a command line script. Maybe that is another option (better?) for installing hotfixes?

EDIT: Anyway it looks qchain to be a bit rendundant: link

This post has been edited by Dogway: 31 July 2012 - 12:00 AM

[submix8c]

1- Offline After OS Installed - the BAT/CMD method (above)
2 - OEM Integrated Install - the $OEM$ folder (note that the WINNT.SIF needs that Section to copy the OEM folder)
3 - Non-OEM/OEM Integrated Install - QCHAIN method
4 - Full Integration Method - nLite (or manually)

Been using #2 to preserve Original Install (for OEM Refurbishing) - "quick" install from HDD using the Section, remove the Section for the CD (must install Fixes/Drivers manually double-click BAT/CMD). $OEM$ inside I386 for HDD, next to it for CD (so a "Repair Re-Install" will work).

This post has been edited by submix8c: 01 August 2012 - 09:42 AM

[Ascii2]

Dogway, on 30 July 2012 - 11:51 PM, said:

Yes, I used "Preserve Download Modification Timestamp" addon.
While in the big picture the order was clearly ascendent it wasn't in a strictly manner:

KB931261 08/02/2007 18:28:20
KB925902 02/03/2007 13:12:08
KB932168 21/03/2007 16:51:12
KB929123 04/05/2007 08:06:26

I added the qchain.exe line just before the pause. But placed it in another folder to don't interfere with the "call all .exe in current folder" loop.
What I don't understand from reading the bulletin you offered me is that an example for installing the hotfixes is given using the update.exe program and a command line script. Maybe that is another option (better?) for installing hotfixes?

Typically, When an update package is run, use of select arguments notwithstanding, it is extracted and an update program (typically "update.exe") from the extracted files is run. Extracting the update packages first, then running the update program seems only better in the following circumstances:

• It is preferred to explicitly specify the extraction location (determination of such explicit location may still be variable)
  
• Update package does not (or cannot) invoke update program
  
• It is desirable to perform another or other operations between the extraction of an update package and the running of the update program.
  
• It is not desired to use an argument that update package supports that the the update program does not support ("/integrate" switch is an example )
  
• Alternate method or software of or for package extraction is proffered.

Dogway, on 30 July 2012 - 11:51 PM, said:

EDIT: Anyway it looks qchain to be a bit rendundant: link

The use of QCHAIN.EXE often is redundant. However, considering that QCHAIN runs quickly and is a small program, it is often preferable to run QCHAIN.EXE after installing multiple updates with only a single reboot, than it is to check the versions of the individual update programs to determine whether they should contain the QCHAIN program logic. Trying to script also much more complex.

Newer (within about the last 9 years) updates often should contain the QCHAIN logic; sometimes or oftentimes what should happen or exist does not always happen or exist (this is often due to error or defect). It is safer to use QCHAIN.EXE than to not.

[Ascii2]

Also, I noticed that Dogway has stated the he is using Window XP Professional x64 Edition. QCHAIN.EXE was developed originally for use on 32-bit Windows 2000 family operating systems; it may or may or work well on that operating system. I am not sufficiently familiar with 64-bit versions of Windows Server 2003 to be able give good council on this.

Also, the FOR loops above are only applicable when it is desired that updates packages with branching start evaluating from the default branch.

[Dogway]

@submix8c : sorry I don't understand #2. Indeed my XP x64 is OEM, it came installed with the system. I used method #1 so I did it wrong?

@Ascii2: Maybe QCHAIN.exe runs in x86 compatibility mode, haven't tested but is a possibility.

[submix8c]

#2 - ref. this. Using appropriate BAT/CMD and a CMDLINES.TXT you can do it in an "unattended" install. Properly set up, you can both install from HDD (via a WinPE) and have a CD ready in case of "failures" and use the BAT/CMD to reapply the Fixes (what I do).

Also see this topic.

No, you didn't err using #1 - my #2 method "incorporates" #1 (see above). The fact that it's an OEM version is not (necessarily) relevant - it may already have Drivers and some Hotfixes "integrated".

Was just inserting variations of the same "theme".

This post has been edited by submix8c: 01 August 2012 - 09:50 AM