How to bypass the SP update timeouts?

  • Thread starter Thread starter PC Pete
  • Start date Start date
P

PC Pete

I've just spent around 4 hours trying to apply the SP2 and SP3 updates
to a WinXP Pro SP1 box from a clean install.

During the update, both SP installers try to access the MS update site,
and of course any firewall (any *real* firewall, not defender) will
block such accesses when they first occur. Since the box I'm installing
on uses a shared monitor, I switch back to my real work while the
updates were going ahead.

I've now found that both SP2 and SP3 try to run a process that attempts
to connect to the MS update site very late in the install/update stage -
and then THE INSTALL SCRIPT TIMES OUT, because the firewall (quite
properly) blocks access to the unkown files/processes that were
installed during the early part of the install!

Now I've had to wait another 2+ hours while the installer undoes all the
changes it made, then wait until it demands that I reboot the machine,
and then after the reboot I have to go through the whole circus again.

If there's a way to disable this utterly inexplicable behaviour, I'd
appreciate hearing how to do it.

Even better, if there's a way to avoid this kind of behaviour in the
first place, that'd be even better... but I'm not holding my breath.

This is a fundamental flaw in the design logic of the service pack
scripts. I wouldn't do that in any code I write (well, not intentionally
anyway), so why does MS do it? I don't understand why an update process
that must install so many security patches and flaw and bug fixes and
changes won't just wait until the access is enabled for any new process
it initiates - it should wait until hell freezes over, not simply time
out and then stay in an unservicable state waiting for a user response!
That's a "comms access 101" mistake.

If the timeout was intended to prevent unauthorised access during an
unattended install, then not being able to automatically roll back the
changes without operator intervention is a truly mind-numbingly
illogical step.

If the access was initiated asynchronously, I can understand that the
order of completion is important to a successful update - but then why
are there no options to restart the process that's been paused waiting
for permission to go through the firewall?

And to top things off, I've just now found that after the SP3 install
timed itself out and failed to properly uninstall itself, I now have a
completely U/S OS. I'm going to have to do a complete reinstall all over
again.

You will understand my frustration.
 
I've now found that both SP2 and SP3 try to run a process that attempts
to connect to the MS update site very late in the install/update stage -
and then THE INSTALL SCRIPT TIMES OUT, because the firewall (quite
properly) blocks access to the unkown files/processes that were
installed during the early part of the install!
Click to expand...

I was unclear.

The firewall is actually waiting for permission for the new file/process
to access the internet connection, so it's not a matter of an
incorrectly set up firewall just blindly blocking, it's just waiting for
permission - but meanwhile, the updater times out.
 
I was unclear.

The firewall is actually waiting for permission for the new file/process
to access the internet connection, so it's not a matter of an
incorrectly set up firewall just blindly blocking, it's just waiting for
permission - but meanwhile, the updater times out.
Click to expand...

For your information, you do not need to install SP2 before installing
SP3. SP3 contains all the updates that were in SP1 and SP2. The only
requirement is that SP1 must be installed on the PC that you are
updating.
 
Back
Top