20 replies to this topic

[Berni42]

Rerun several times today. Here a log from earlier today:

Download Error: C:\apup\modules\Critical\KB2281679_seven_x64.apm_files\Windows6.1-KB2281679-x64.msu

File size does NOT match. Expecting 868573, but found 681371!!!



Download Error: C:\apup\temp_bin\___windows_critical_seven_x86.7z

File size does NOT match. Expecting 3899, but found 10820!!!



Download Error: C:\apup\temp_bin\___windows_noncritical_seven_x86.7z

File size does NOT match. Expecting 1755, but found 5880!!!


And the latest re-run:

Download Error: C:\apup\modules\Critical\KB978542_seven_x86.apm_files\Windows6.1-KB978542-x86.msu
File size does NOT match. Expecting 1883558, but found 1704666!!!

Download Error: C:\apup\temp_bin\___windows_critical_seven_x86.7z
File size does NOT match. Expecting 3899, but found 10820!!!

Download Error: C:\apup\temp_bin\___windows_noncritical_seven_x86.7z
File size does NOT match. Expecting 1755, but found 5880!!!

[_def_x_]

Hi Berni42, welcome.

We need to see an unedited log file, please read the following pages - Logs - Creating! & Logs - Reference! - and re post the new log.

OK, it looks like you may be getting an old script, maybe a cache issue for you. I downloaded the files and they are fine. Make sure you are getting the last updated script for Windows 7 pre SP1 - autopatcher_seven_x86_20110208.script

Windows 7 has a new requirement - Service Pack 1 - if you decide to continue use of AutoPatcher SP1 for Windows 7 will be necessary. The 2 pre SP1 scripts (x86 & x64) are becoming outdated.

Edited by gUiTaR_mIkE, 25 March 2011 - 04:22 PM.

[Berni42]

Huge thanks for hints. I turned off the squid transparent proxy here and no improvement. I disabled all the windows 7 selections, and added the 4 back. Each seems to work fine separately but some combinations failed with file verification errors.

Interestingly a re-run just now with all four windows 7 selections has worked with no errors.

[_def_x_]

>>> the squid transparent proxy

see if the Options - Proxy settings help in APUP.

>>> I disabled all the windows 7 selections, and added the 4 back. Each seems to work fine separately but some combinations failed with file verification errors.

On a first run you likely had close to the 4GB limit with APUP. This is a theoretical limit, it may be less, regardless, selecting too many scripts causes APUP to choke.

The remedy, select fewer scripts, once they are downloaded and only maintenance updating is needed - as your re-run essentially is, your trying a second time to get the few remaining missing files that failed - this usually works.

Btw, if you should have issues in the future please follow the log file guidelines - it makes our job much easier.

[_def_x_]

>>> I disabled all the windows 7 selections, and added the 4 back.

Boy, I hope you read this. I believe the Windows 7 SP1 scripts will delete all the pre SP1 updates - that means most if not all of them if you download to the same \modules folder. I would guess but I'm not positive that both the x86 and x64 releases can download to the same folder, you simply need to have a new instance of \apup for the x86 and x64 SP1 releases.

==>> If I was you I would have separate \apup folders for the Windows 7 'pre' and 'post' SP1 scripts.

C:\Updates
.................\Win7
.................\Win7SP1
win7_apup.exe
win7_autopatcher.exe
win7sp1_apup.exe
win7sp1_autopatcher.exe

Each Win7 folder will have all the files and folders that are needed to make AutoPatcher and APUP work, including their own \modules folder. You could create a shortcut to the log file in each folder as well,

win7_apup.log
win7sp1_apup.log

Of course you will want to run APUP with logging - apup.exe /log - you may also want to run AutoPatcher so it bypasses the 2 EULAs - autopatcher.exe /nolicense - once you get it all setup up have APUP Remember Selections, and you're good to go.

The folder layout could look something like this, with shortcuts to all the important files:

Spoiler

C:\Updates
.................\Win7
.................\Win7SP1
win7_apup.exe
win7_apup.log
win7_autopatcher.exe
win7sp1_apup.exe
win7sp1_apup.log
win7sp1_autopatcher.exe

[Berni42]

Good spot this explains the inconsistencies. Good work round but I can see this causing lots of problems for those who are in transition to SP1.

Would it not be easier all round for SP1 scripts to use separate folders?

[Berni42]

Actually the work round is not ideal. Do we really now have to maintain two separate apup copies including duplicates of office Adobe updates etc and remember to check which apup to run on different machines depending on the version of Windows 7?

Up to now it has been possible to take a DVD to an office and and update in one shot the various windows, office and all the other apps in one autopatcher run. It would be more than really nice to have the Windows 7 SP 1 scripts use separate names.

[_def_x_]

>>> I can see this causing lots of problems for those who are in transition to SP1. Would it not be easier all round for SP1 scripts to use separate folders?

The guys who put the scripts together are much smarter than I am at this stuff but I will say I had mentioned many moons ago to have each release download to it's own directory within \modules - \modules\xpsp3_x86 or \modules\7_x86 - you could also have \os_shared or \off_common directories for items shared or common to the OS or Office release. It would be too much work to rewrite the scripts at this point.

>>> Do we really now have to maintain two separate apup copies including duplicates of office Adobe updates etc

I guess you missed my example - there are no duplicates except the 7MB used for each base folders (\apup_bin, \bin, etc).

It sounds like you've had no issues downloading everything into one \modules folder up till now. Now that an OS (7) has a significant update (SP1) you need to make a decision - both editions of 7 (pre & post sp1) can't coexist in the same folder - I would keep all the ongoing releases in one folder, and move releases that are getting outdated to their own folder.

The problem your approach creates is it takes too long to try and explain but having everything (older and newer scripts) in one folder you risk a chronic case of Unofficial status, also, trying to find the source of the problem becomes difficult. I call this script gluttony mixed with a high speed connection which causes some people to simply select too many scripts before they contemplate maintaining the setup, worse, asking if it's a good idea.

I'm not going to try and convince you otherwise, it never works. I will only say you need to move 7 out and keep 7SP1 with all your other releases and keep an eye on the Official status.

[_def_x_]

The other problem you will (should) have is the 7 SP1 script, if I understood Domenico correctly, will delete all the 7 pre SP1 updates from the folder. You should get a loop of delete (7SP1 script) and re-download (7 script) if they coexist as you have them now. Another reason to have them separated.

[Berni42]

Righto :-)

I do not understand your example...

Quote

C:\Updates
.................\Win7
.................\Win7SP1
win7_apup.exe
win7_autopatcher.exe
win7sp1_apup.exe
win7sp1_autopatcher.exe

e.g what is win-apup7.exe please and how does it know not to load the updates for Windows 7 Sp1?

[_def_x_]

Looking at your quote above...

You start by creating a new empty directory on the drive - I'll call it C:\Updates.

Now, you decide you want to create a few AutoPatcher releases and keep them separate, you extract the contents of apup131.zip to your new directory creating,
-> \apup - you want to rename the folder to match the release - ...\Win7

You also want to have 7SP1, and you know they can't share the same folder, extract apup131.zip and rename \apup to ...\Win7SP1

You now have a main C:\Updates directory and 2 new sub directories - \Win7 and \Win7SP1.

>>> e.g what is win-apup7.exe please and how does it know not to load the updates for Windows 7 Sp1?

First, I created shortcuts for each of these 'exe' files inside their respective folders - right-click, create shortcut. I added the commands mentioned in post #5 to the shortcut properties. Finally I renamed the shortcuts and moved them to C:\Updates.

You will want to make sure APUP has the first 2 selections checked - 'Updater' and 'Engine', and once you select the main release or releases, use APUP 'Options' to 'Remember Selections'. Now, every time you dbl-click win7_apup.exe - if you did it correctly - should start APUP with Win7 selected and ready to download.

The same goes for win7_autopatcher.exe - every time you dbl-click this shortcut AutoPatcher will load Win7.

It takes longer to write this than it would take to setup my example. I know it's not perfect but it is one option that keeps things in order.

Please understand, I'm not telling you how to run your system, I'm trying to help you prevent a bunch of issues that can creep into an AutoPatcher setup when too many releases are combined. I find it much easier to fire up a few different instances of AutoPatcher than trying to pile everything into one folder.

I have three shortcuts for all my releases - 1 to apup.exe, 1 to autopatcher.exe, and 1 to apup.log. I name them in such a way that they all line up by name...

win7_apup.exe
win7_apup.log
win7_autopatcher.exe

[Berni42]

Slightly different but I now have:

c:\apup - loaded with windows Xp, Vista, office, adobe etc updates
c:\apupw7 - loaded with windows 7 updates only
c:\apupw7sp1 - loaded windows 7 sp1 updates only

It occurs will Vista Sp2 and Xp Sp3 conflict in the same way as Windows 7?

[_def_x_]

I'll make a few final suggestions based on your log you posted regarding the Office Addon Pack.

You might want to combine similar releases, something like this...

=> \OSes - XPSP3, VistaSP2, Win7SP1, DirectX, NET Framework, MS Security
=> \Office - Office XP, Office 2003, Office 2007, Office Addon Pack, any service packs
=> \Extras - Extras Addon Pack, any Adobe addons, any new addon pack
=> \Win7 - because Windows 7 with no service pack is being phased out, can't be combined with Windows 7 SP1

One final suggestion: Pay attention to the dates in APUP for any given release, except for obvious releases like DirectX that may not get updated for months, if a release is getting old, months, or even years since it was last updated - Windows 7 (no service pack) hasn't been updated since February 2011, Office XP hasn't been updated since March 2009. If you have an Official release, uncheck it from your list, know it's in your combined releases (it will show in AutoPatcher).

I would also test a release to see if it fails before updating the combined folder - example: Office Addon Pack. I would simply 'copy' the whole lot to a temp location, try to update only that release, or, each release one at a time. If a release fails it only affected your test and not the original. You can post a single log file for the failed release and maybe we can fix it.

Please don't post log files with 10 scripts selected like the one in the Office Addons post.

Read and try to follow our guidelines for creating and posting log files - Logs - Creating! & Logs - Reference!

[Berni42]

gUiTaR_mIkE, on 30 March 2011 - 04:57 PM, said:

You might want to combine similar releases, something like this...

=> \OSes - XPSP3, VistaSP2, Win7SP1, DirectX, NET Framework, MS Security
=> \Office - Office XP, Office 2003, Office 2007, Office Addon Pack, any service packs
=> \Extras - Extras Addon Pack, any Adobe addons, any new addon pack
=> \Win7 - because Windows 7 with no service pack is being phased out, can't be combined with Windows 7 SP1

Huge thanks. Combining is very handy for real autoapatcher.exe only users, and scripts. Does this arrangement now mean that autopatcher.exe loaded with W7 SP1 updates can now be run on a plain W7 system, after all it can be run on XP?

[_def_x_]

Berni42 said:

Does this arrangement now mean that autopatcher.exe loaded with W7 SP1 updates can now be run on a plain W7 system, after all it can be run on XP?

No, it is not advisable. We covered this already in another thread Here! I understand if you might not completely get exactly how AutoPatcher works but at some point it needs to sink in.

The point is we at AutoPatcher don't wont users coming in when they break something and blame us. SP1 for Windows 7 is new, it is unknown exactly what will happen if the wrong updates get applied,
...maybe they will simply not install, this would be OK I suppose, but,
...what if an older update reverts a SP1 file to an older version, this may cause a user all kinds of problems and guess who gets blamed.

AutoPatcher code was updated to distinguish between Windows XP SP1, SP2, SP3 - this is why you can have an XP release mixed with a 7 release - XP updates wont load, they'll remain hidden. Vista is the same as XP, Vista updates will only load on a Vista system with the required service pack level.

You should open and view a few apm files from the \modules\Critical folder (use Notepad) - one for each of the OSes you have, XPSP3, VistaSP2, and 7SP1, and look at the section - WindowsVersion= - when you see XP_SP3_X86, this update will only load on an XP SP3 system. When you see SEVEN_X86, this update will load on any x86 based Windows 7 system, and try to install.

AutoPatcher's code needs updating, until a developer offers we're stuck.

[Berni42]

gUiTaR_mIkE, on 31 March 2011 - 09:03 AM, said:

No, it is not advisable. We covered this already in another thread Here! I understand if you might not completely get exactly how AutoPatcher works but at some point it needs to sink in.

Please avoid making personal comments.

[_def_x_]

Berni42 said:

Please avoid making personal comments.

What personal comments are you referring to?

I say to you that at some point it needs to sink in - this is insulting to you, sorry, I can't help that you take this statement personally.

Translation of my comment - I've said about all that can be said, it's in your hands now, learn from it and enjoy AutoPatcher - whats the problem?

[Berni42]

At the start of this topic the advise is to keep releases separate. Now the advise is to have all the Oses together less windows 7. Fine but this easily risks an autopatcher user running windows 7 sp1 updates on a windows 7 system. Which is why I wanted the clarification.

[_def_x_]

Berni42, on 31 March 2011 - 11:13 AM, said:

At the start of this topic the advise is to keep releases separate. Now the advise is to have all the Oses together less windows 7. Fine but this easily risks an autopatcher user running windows 7 sp1 updates on a windows 7 system. Which is why I wanted the clarification.

Wrong, let's get this corrected. First, this thread is not isolated to just this conversation. You have peppered the forum with questions on numerous accounts, my comments are in total trying to get this all straight for you. Your last post was not asking for any clarification, you accused me of saying something to you!

Second, I never said to you - "put all the scripts in one folder" - wrong, you did this on your own. Post #3 above you say...

Quote

I disabled all the windows 7 selections, and added the 4 back.

This sounds like you put all 4 Windows 7 scripts in one folder, or 4 of something in one folder. I did not tell you to do this so please don't say I recommended it. Also, in your post regarding the Office Addons you have 10 scripts in your log, 10 - I did not tell you to do this either, so please don't say I did.

Now, what I have done is explained over and over again one option that may work if you insist on having XP SP3, VistaSP2, and 7SP1 in one folder, what did I say...

Keep Windows 7 no service pack in a separate folder - isolated from Windows 7 service pack 1. I also answered your question regarding 7 SP1 and made a pretty clear suggestion - post #15 above points to the thread.

Now, how in the world can I monitor a person's use of AutoPatcher that has nearly every release we offer in one folder. How can you have Office XP, Office 2003, and Office 2007, XP, Vista, and 7, both x86 and x64 installed on the same system? If you can manage this, cool, then surely you can manage not to load the wrong version of Windows 7?

Honestly, I will be straight up with you at this point. If your issue is with my suggestion (it was only a suggestion) of folder structure in post #13 above that also includes \Win7 - if you feel you may start the wrong version of AutoPatcher and load the wrong version of 7 - remove the release from the list, get it out of there.

The matter is closed as far as I'm concerned, I can't offer anymore.

[Berni42]

agreed.