Obsolete
Status Update
Comments
[Deleted User] <[Deleted User]> #2
[Empty comment from Monorail migration]
ri...@gmail.com <ri...@gmail.com> #3
We have the same issue. We've deployed v12.xxx.xxx to several thousand users and have now discovered that it is unable to update via our proxy servers (which require authentication). Normal web access through Chrome is fine, but the Updater side of things just pauses and then returns and error code 7. How hard is it to allow Google Update to use the same proxy that is specified in Windows? Alternatively please let us know the URL that Google updater uses and I can create a proxy exception rule for it.
[Deleted User] <[Deleted User]> #4
Reese,
Can you try some of these to see if they'll work for you? Either:
a) Allow access totools.google.com:80 , dl.google.com:80 , cache.pack.google.com:80 , clients2.googleusercontent.com:80
b) Allow access to port 80 of all IP addresses contained in the IP blocks listed in Google's ASN of 15169. This list can change, so you need to update it periodically.
Rich,
What auth does your proxy use? HTTP Auth?
Can you try some of these to see if they'll work for you? Either:
a) Allow access to
b) Allow access to port 80 of all IP addresses contained in the IP blocks listed in Google's ASN of 15169. This list can change, so you need to update it periodically.
Rich,
What auth does your proxy use? HTTP Auth?
al...@gmail.com <al...@gmail.com> #5
For Google Update to work via proxy, you must allow Windows (Internet Explorer) and Google Chrome to save (remember) your proxy credential (login and password). You must do it in both places: 1) in the checkbox "Remember password" in _Internet Explorer_ proxy authentification prompt window and 2) in Google Chrome during first proxy authentification (remember password in yellow top line of the window). If you already told Google Chrome NOT TO remember proxy password, you should go to Chrome settings - password settings and delete you proxy address from the list of sites, for which Chrome should not remember passwords.
You should also disable getting automatic proxy settings in Internet Explorer network configuration window.
After that you should close Internet Explorer, close Chrome window, and in windows task manager kill all processes Chrome.exe and GoogleUpdate.exe. When you start Chrome again, automatic update should work fine.
PS The problem comes from the fact, that standalone updater (GoogleUpdate.exe) has no GUI and therefore is not able to ask for user proxy login and password and is also not able to use chrome proxy session in any way.
Regards,
Anton Alisov
ry...@google.com <ry...@google.com> #6
Google Update actually does have the ability to show a UI for proxy login/password, and will ask for it if there's a logged-in user running it that it can ask for updates. Otherwise, yes, it will query browsers for saved password settings.
The issue with automatic proxy settings overriding manual proxies has been root-caused and will be fixed in an upcoming release later this month. (That release also contains the ability to manually set a proxy for Google Update to use using Group Policy.)
The issue with automatic proxy settings overriding manual proxies has been root-caused and will be fixed in an upcoming release later this month. (That release also contains the ability to manually set a proxy for Google Update to use using Group Policy.)
al...@gmail.com <al...@gmail.com> #7
Not sure, how Chromium interacts with GoogleUpdate, but Google Chrome never attempted to show any dialogs to enter proxy login/password while updating. GoogleUpdate.exe was automatically installed as a service by Chrome. The only difference when this service was running under system account and under user account was in the fact, that under system account it hanged (progress was "circling" forver in the Chrome's "About" window, when under my user account "About" window immediately showed "Error 7"). So, update never happened when there was no saved password. Even more strange is that saved password works only when it is saved BOTH in MS Windows (IE) authentification window AND in Google Chrome. When it is saved just in one of this places, automatic update also don't work.
st...@gmail.com <st...@gmail.com> #8
I also faced this issue initially when testing the update service within our corporate network, which also filters through our Authenticated Proxy SurfControl.
Since the update service is running as the local system account, the only two choices we had, were to customize the update service with an Active Directory account, and grant that account access to the Google update URL's, or to whitelist the URL's within our proxy to allow Unauthenticated access.
In our situation with more than 20,000 workstations utilizing the update service, an AD service account on all machines was not in our favor. After capturing all inbound/outbound activity on one of our lab machines, we were able to locate all URL's the update service was calling on, and whitelist those for Unauthenticated access, which corrected our issue.
Luckily, these URL's appear to be services, which return no real content within a browser, so there was no risk to granting corporate users access they did not need.
Here are all of the URL's we located during testing. These may only be the URL's used for Chrome, and there could be others processed for additional Google applications:
Dest. URL:tools.google.com , tools.l.google.com
Dest. IP Addresses: 74.125.225.14, 74.125.225.12, 74.125.225.0, 74.125.225.15, 74.125.225.7, 74.125.225.8, 74.125.225.2, 74.125.225.6, 74.125.225.1, 74.125.225.3, 74.125.225.4, 74.125.225.9, 74.125.225.10, 74.125.225.11, 74.125.225.5, 74.125.225.13
Dest. URL:dl.google.com , dl.l.google.com
Dest. IP Addresses: 74.125.225.10, 74.125.225.14, 74.125.225.12, 74.125.225.2, 74.125.225.15, 74.125.225.6, 74.125.225.3, 74.125.225.1, 74.125.225.0, 74.125.225.9, 74.125.225.8, 74.125.225.11, 74.125.225.7, 74.125.225.4, 74.125.225.13, 74.125.225.5
Dest. URL:pack.google.com , cache.pack.google.com , www2.l.google.com , cache.l.google.com
Dest. IP Addresses: 74.125.225.16, 74.125.225.17, 74.125.225.19, 74.125.225.20, 74.125.225.18, 74.125.170.208
Since the update service is running as the local system account, the only two choices we had, were to customize the update service with an Active Directory account, and grant that account access to the Google update URL's, or to whitelist the URL's within our proxy to allow Unauthenticated access.
In our situation with more than 20,000 workstations utilizing the update service, an AD service account on all machines was not in our favor. After capturing all inbound/outbound activity on one of our lab machines, we were able to locate all URL's the update service was calling on, and whitelist those for Unauthenticated access, which corrected our issue.
Luckily, these URL's appear to be services, which return no real content within a browser, so there was no risk to granting corporate users access they did not need.
Here are all of the URL's we located during testing. These may only be the URL's used for Chrome, and there could be others processed for additional Google applications:
Dest. URL:
Dest. IP Addresses: 74.125.225.14, 74.125.225.12, 74.125.225.0, 74.125.225.15, 74.125.225.7, 74.125.225.8, 74.125.225.2, 74.125.225.6, 74.125.225.1, 74.125.225.3, 74.125.225.4, 74.125.225.9, 74.125.225.10, 74.125.225.11, 74.125.225.5, 74.125.225.13
Dest. URL:
Dest. IP Addresses: 74.125.225.10, 74.125.225.14, 74.125.225.12, 74.125.225.2, 74.125.225.15, 74.125.225.6, 74.125.225.3, 74.125.225.1, 74.125.225.0, 74.125.225.9, 74.125.225.8, 74.125.225.11, 74.125.225.7, 74.125.225.4, 74.125.225.13, 74.125.225.5
Dest. URL:
Dest. IP Addresses: 74.125.225.16, 74.125.225.17, 74.125.225.19, 74.125.225.20, 74.125.225.18, 74.125.170.208
bu...@chromium.org <bu...@chromium.org> #9
Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.
la...@google.com <la...@google.com> #10
[Empty comment from Monorail migration]
da...@gmail.com <da...@gmail.com> #11
problem still present even with the latest version MSI chromium; impossible to update. Using an ISA proxy with authentication. No explicit error message.
dm...@gmail.com <dm...@gmail.com> #12
3 years now! Problem still present even with the latest version MSI chromium. Impossible to update Chrome via google update. Fix it please already!
bu...@chromium.org <bu...@chromium.org> #13
[Empty comment from Monorail migration]
bu...@chromium.org <bu...@chromium.org> #14
[Empty comment from Monorail migration]
so...@chromium.org <so...@chromium.org> #15
[Empty comment from Monorail migration]
ma...@gmail.com <ma...@gmail.com> #16
Also having this problem with Version 27.0.1453.110 m
Can't update.
Can't update.
[Deleted User] <[Deleted User]> #17
er...@gmail.com <er...@gmail.com> #18
Is this problem still existing?
I try to update Chrome automatically via GoogleUpdate but it seems not to be working.
Already addedtools.google.com to our proxy whitelist without authentication but nothing happens.
Is there no list with all URLs available which need to be whitelisted or something else?
I try to update Chrome automatically via GoogleUpdate but it seems not to be working.
Already added
Is there no list with all URLs available which need to be whitelisted or something else?
[Deleted User] <[Deleted User]> #19
vt...@gmail.com <vt...@gmail.com> #20
For your information, the URLs used for updates are:
http://cache.pack.google.com/edgedl/chrome/win/
http://www.google.com/dl/chrome/win/
https://dl.google.com/chrome/win/
http://dl.google.com/chrome/win/
http://google.com/dl/chrome/win/
More details here:
https://support.google.com/chrome/a/answer/3204698?hl=en&ref_topic=2936229
I hope it might be helpful.
More details here:
I hope it might be helpful.
ni...@gmail.com <ni...@gmail.com> #21
Problem still present with Chrome 31.
[Deleted User] <[Deleted User]> #22
jo...@gmail.com <jo...@gmail.com> #23
Added all the above URls to our proxy white list but still wont update.
vt...@gmail.com <vt...@gmail.com> #24
It works for me. Do you allow anonymous connections to the white list? The
user that make the update is SYSTEM (the one who runs the google update
service)
user that make the update is SYSTEM (the one who runs the google update
service)
az...@gmail.com <az...@gmail.com> #25
Problem still present with Chrome 33.0.1750.154 m
Very annoying...
Very annoying...
ma...@gmail.com <ma...@gmail.com> #26
Same here. Password-protected proxy.
Version 35.0.1916.114 m
Update failed (error: 7)An error occurred while checking for updates: インターネットに接続できません。プロキシ サーバーの認証が必要です。
(The Japanese says: Can't connect to internet. Need proxy server authentication.)
Automatic proxy config in Windows Internet settings is OFF.
Proxy is configured by file in local network.
For normal web surfing, Chrome has stored the username and password (but still requires me to click OK every time.)
Annoying!
Version 35.0.1916.114 m
Update failed (error: 7)An error occurred while checking for updates: インターネットに接続できません。プロキシ サーバーの認証が必要です。
(The Japanese says: Can't connect to internet. Need proxy server authentication.)
Automatic proxy config in Windows Internet settings is OFF.
Proxy is configured by file in local network.
For normal web surfing, Chrome has stored the username and password (but still requires me to click OK every time.)
Annoying!
ma...@gmail.com <ma...@gmail.com> #27
Additional comment: Firefox 29 updates on my system without issue.
ma...@gmail.com <ma...@gmail.com> #28
[Comment Deleted]
az...@gmail.com <az...@gmail.com> #29
@#26 :-/
gr...@chromium.org <gr...@chromium.org> #30
+sorin
gr...@chromium.org <gr...@chromium.org> #31
+sorin
so...@chromium.org <so...@chromium.org> #32
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]> #33
le...@gmail.com <le...@gmail.com> #34
The issue still exists in current beta release, after almost 5 years.
az...@gmail.com <az...@gmail.com> #35
[Comment Deleted]
sh...@chromium.org <sh...@chromium.org> #36
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
is...@google.com <is...@google.com> #37
This issue was migrated from crbug.com/chromium/91160?no_tracker_redirect=1
[Multiple monorail components: Internals, Internals>Installer]
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Internals, Internals>Installer]
[Monorail components added to Component Tags custom field.]
Description
Chrome Version : 14.0.835.8
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: fail
Firefox 4.x: fail
IE 7/8/9: ok
What steps will reproduce the problem?
2.
3.
What is the expected result?
Chrome should be updating itself using the proxy settings that have been set without having to change the ini file.
What happens instead?
It doesn't update
Please provide any additional information below. Attach a screenshot if
possible.
I've tried changing the proxy manually and it still will not ask for the username and password for the proxy server that we use. Is it a bug or just not built into chrome?
If not it should be!