Forwarding to our installer team. Will let you know what they say.
From review of the log, we've determined that this is failing because version.xml could not be retrieved (indicated by warning 1403.) Usually this is due to firewall restrictions. Can you verify that you can access fpdownload2.macromedia.com on both port 80 and 443?
Here is some additional info that might just about answer.
We are on a corporate network
The network has no route to the internet
All traffic is handled by Microsoft ISA/TMG proxy
All users are required to authenticate to the proxy when they browse.
Anonymous access is not allowed
The question is:
As what user or entity is the updater trying to access the internet.
User context or System Context.
I will try and verify with ISA TMG administrators tomorrow and verify logs.
Is there a way to specify proxy for the updater, it would still
require to be authenticated.
The user for the updater is SYSTEM. I imagine that the proxy settings are the same as Internet Options, but I'll confirm. As an FYI, we're currently considering adding the ability to host these updates on corporate networks and allowing admins to redirect the updater to internal servers.
if the context of the updater is SYSTEM, then no, by default it does not have the same proxy as the USER. You would need to use the proxycfg.exe tool to transfer the proxy settings from a current logged in user to the system. Which must be an administrator http://msdn.microsoft.com/en-us/library/windows/desktop/aa384069(v=vs.85).aspx
From your response I understand the developer team still has some work to do for the following scenarios
- enterprise proxy use
- authenticate to proxy
count this as a "please, please, please" for letting up self host the updates. we are running into the same issue here as foobsz. We can't use the autoupdater until either it respects and works with our authenticating proxy or we can host the update ourselves.
(however, I do love the way you have set this up using a scheduled task instead of a constantly running process. especially for the home users I help support...)
For those admins that would like to use the silent auto update service, but are behind a proxy server, you now have the capability to do background updates from an internal server using the SilentAutoUpdateServerDomain property.
Please see the section "Background updates from an internal server" in the Flash Player 11.2 Administration Guide for complete information.
While this is an improvement, still....
1 should it not be (page 17), the manual has error SilentAutoUpdateEnable=0 (boolean value 0 means the silentautoupdate is disabled)
2 You don't really expect admins to perform the sequence for internal server as a source update everytime a new version is released (page 18 and 19)? (like every 7-14 days or so?) Do you know how that would impact the workload for an Enterprise environment?
Could adobe not provide a utility that would
- retrieve the updatefiles (with proxy account to a proxy server)
- extract the updates and maintain the correct folder structure
- run as either a scheduled task on windows server or cronjob for linux?
- have two settings: 1 autoapprove all updates (immediately available to all clients)
2 download updates but wait for approval by admin
3 rollback history (eg keep last three releases)
I know many of the Enterprise admins on this forum would agree with the above.
So while some improvement, needs further engineering and customer care.
It looks like we might have reintroduced the guide error on page 17 again. I'm talking with the folks responsible to see if we can get this fixed. It should be:
Hopefully you won't have to do this every 7 - 14 days, but regardless having a utility sounds like it would make your life easier. I'd recommend opening up a new feature request for this at bugbase.adobe.com and posting back with the report's URL. I'd recommend other interested admins visit your report and cast their vote for a fix.