Posted 25 February 2010 - 01:48 PM
Posted 25 February 2010 - 02:57 PM
Just to be clear, APUP downloads / maintains the release(s) and AutoPatcher installs the updates to your system.
I just updated a new install of XP SP3 x86 in VPC 2007 and had zero problems running AutoPatcher in a virtual environment. If you had
every update checked for installation that may be part of the problem, I think there were 60+ updates needed, that's a lot in one pass,
Also, most of the updates have the /quiet switch so only in rare occasions should you get a prompt, I don't recall seeing any but Cristiano
can address this issue better, he does the release, there may be a few updates that require user input, if this is what your referring to.
Posted 25 February 2010 - 03:07 PM
And another thing. WGA must be installed manually !!! Why not use autoit (or something similar) to resolve that ?
Edited by OmYcroN, 25 February 2010 - 03:10 PM.
Posted 25 February 2010 - 03:41 PM
Posted 25 February 2010 - 03:52 PM
Let's say the hang CPU problem and the slow installing are Vmware related. In "real life PC" how much time does AutoPatcher need to install those 65 critical updates ? I hope it's muck quicker than the online one .
Posted 25 February 2010 - 04:49 PM
i run some vms with ms virtual pc 2007 in a athlon xp 2600+ and i us to set only about 300mb of ram to the vms. and the install doesn't take so long. for sure, with an better hardware, it's possible that you can deploy all the updates a lot faster than 60minutes. as an guess, it may be an issue in the vm himself. also, the deploy task us to take a lot less when you disable system restore (but of course, you know what happens when you disable that)
> AutoPatcher is doing something else when installing updates (like expanding exes into temp folders and then running them, checking files etc.
no. autopatcher is just an interface. when autopatcher loads, it reads the infos about your OS, language and do the proper detections to check for already installed updates. after that, autopatcher loads the update tree. with that ready, according to your selections, autopatcher will run every single update like this:
"Module:\WindowsXP-KB975713-x86-ENU.exe" /quiet /norestart /overwriteoem
where: module is the folder with the same name than the .apm file (unless specified in the .apm file).
any other task is done only by the update himself, according to the settings /quiet /norestart /overwriteoem . most of the updates extract the content of the update to an temp folder and then deploy the update himself. but that task isn't done by autopatcher, it's done by the kb
> And another thing. WGA must be installed manually !!! Why not use autoit (or something similar) to resolve that ?
because ms says that the user must agree with the eula to this one and have removed the /quiet option. also, every single update must come from ms website. due that, any change in the update himself needs to be done in the user's machine
> and some times hangs with 100% CPU
that us to indicate that the system is busy with something. perhaps an av scanning?
> In "real life PC" how much time does AutoPatcher need to install those 65 critical updates ?
well, how fast is your machine? a few days ago, i've fixed an customer machine and, after set autopatcher to run deploying all the updates at once (including .net, java, direct x, etc), i've left the room to take an juice and feed my cats. after that (i was away for less than 10min) autopatcher was already finishing the deployment of adobe reader. for sure that machine was really faster, but even in my 2600+ the whole deployment doesn't take longer than 30minutes. but (there's always an but) i've already found several machines that was painfully slow and the deployment in certain cases toke more than 1 hour.
Posted 25 February 2010 - 05:05 PM
Posted 25 February 2010 - 05:35 PM
no. the user must read and accept the eula
> can't AutoPatcher show the user that EULA or even move the priority of WGA's installation to top
that can be done, but updates needs to be deployed in a proper order. we us to choose release date as order. i will do some checks (but not sooner than next week) about change that date to allow that
Posted 28 February 2010 - 08:37 PM
Maybe it helps or not but the CPU is always too high (and updates take a lot to install than installing theme from a .bat (~10s small ones) file (i know autopatcher does the same but what is wrong here ?!). If somebody is trying this on VMWare 7 please post.
1. I see that each update has it's installing time (10s ?!) so if an update is faster than that it has to wait that time ?
2. What is that with the red marks : Unofficial/Unsupported version ?
IGNORE PICTURE BELOW !
Edited by OmYcroN, 28 February 2010 - 09:00 PM.
Posted 01 March 2010 - 12:34 AM
If you could, run the .md5 file inside the \apup folder, if it verifies all the files you likely have an extra somewhere. If you have
multiple releases in the \apup folder run each .md5, as well, fire up AutoPatcher, click About - Release Info, the offending release
is the one marked False.
If you have only XP SP3 x86 by itself, can you create an .md5 of the entire release and I will run it against my Official release and
maybe we can find the stray file, assuming it is a stray, it may be that a file didn't pass hash and needs to get downloaded again.
Also, are you having troubles with AutoPatcher running in the host OS at 100% CPU or is it only the virtual machine? I can't be sure but
it looks as if you have some sort of anti virus or other security software running, if so, disable it while AutoPatcher is updating the OS.
Posted 01 March 2010 - 01:55 AM
that it's an issue from your vm.
> 1. I see that each update has it's installing time (10s ?!) so if an update is faster than that it has to wait that time ?
no. that is just to give the user an idea of the remaining time. that time was true in the past, but now, with really fast machines, that time is very wrong. but when the executable from the update closes, autopatcher moves to the next, doesn't matter if the update has an time to install = 1 hour. also, if the update has an time to install = 1s the deploy time will not be faster just due that
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users