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.
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.