Bug possibly connected to a first bug I just reported - when I actually run an update on a Win 2003 SP2 system here, the first time round it works fine, but trying to run it a second time causes some kind of lock-up on the first module AP tries to install. Enabling different updates in the answers tab doesn't have an impact, in that trying to update one or 2 modules at a time has a similar effect whichever the modules happen to be.
Screenshot attached - has anyone seen anything like this before? (link to screenshot) (left running overnight in case it was running slow, rather than failing)
May be connected somehow to this one -- same shared APUP download folder, but being used to update a different machine.
Autopatcher lockup bug
Started by Fox2, Jul 12 2008 08:28 AM
3 replies to this topic
#1
Posted 12 July 2008 - 08:28 AM
#2
Posted 15 July 2008 - 07:55 PM
Hey there Fox,
I'll take a look into this one. Your screenshot indicates that you have six other updates, is it always locking up on GPMC? I've never had any issues installing GPMC on a fresh Server 2K3 image but I'll make sure.
In the mean time, go to the components\GPMC_x86_files and run gpmc.msi. What error do you receive?
I'll take a look into this one. Your screenshot indicates that you have six other updates, is it always locking up on GPMC? I've never had any issues installing GPMC on a fresh Server 2K3 image but I'll make sure.
In the mean time, go to the components\GPMC_x86_files and run gpmc.msi. What error do you receive?
#3
Posted 16 July 2008 - 05:33 AM
Just confirmed that everything installed just fine on my SP2 integrated 03 VM. I noticed that Windows Update was offering another "version" of KB943729 which I did update in the XP and 2003 releases. Other than that, everything seems to be good to go.
Let me know what happens when you try to install GPMC manually.
Let me know what happens when you try to install GPMC manually.
#4
Posted 26 July 2008 - 10:35 AM
Hmmm, pity OP has not responded...
There have been fairly well documented random instances of the DNS patch destroying Windows 2003 servers due to a port conflict. These are not reproducible on other servers because of the randomization element in the 2500 ports chosen by the patch. Registry edits to solve this are, by now, quite well known.
--
There have been fairly well documented random instances of the DNS patch destroying Windows 2003 servers due to a port conflict. These are not reproducible on other servers because of the randomization element in the 2500 ports chosen by the patch. Registry edits to solve this are, by now, quite well known.
--
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users











