I run daily scans of my network and have also noticed that the 50.x release has not been updated on my network except for a few machines that have had the .msi executed.  

One one of the machines with the older version, the help-> about did allow the user to upgrade.

Over to the installer/updater team.

Apparently, last week (tuesday, May 3) Chrome updated to the latest stable version, 50.0.2661.94 ... Not sure why this happened, and why it skipped a version.. ?

I've noticed this same issue.  There are two differences with my setup, though.  I am using Windows 10 on all my PC's.  And also, a few months ago, I upgraded to 64-bit Chrome from 32-bit Chrome.  I am not sure if the update issue started at the same time, but it's possible.

We roll out stable updates gradually, so it is expected that some machines will autoupdate before others. This is working as intended. Thanks for checking.

Ok, thanks for the reply. I will keep an eye on it, because I still find it a bit strange that it skipped a version. I would also expect it to update a bit faster than after 5 days, because 5 days is rather long if it comes to security fixes...

I want to ask this again: the latest stable version (51.x) was released May 25th. Today it's june 1st, which is exactly one week later. And still my chrome is running on the previous version (50.x). I really think this is a security risk...

Same here.  I'm still stuck on v50.x.  I don't get it.  I still wonder if the reason is that I'm now using 64-bit Chrome.

My scan from today just finished, we still had installed version : 50.0.2661.102 and not Fixed version : 51.0.2704.63.

This is NOT the 64-bit but the x86 version.

I'm glad I'm not the only one!  I understand that updates are rolled out gradually, so this is probably not a bug, but imho the rollout could be a lot faster. 

I'm happy to hear the issue isn't 64-bit.  (It had started for me around the same time I updated to 64-bit, so I thought it might be related.)

But I do think this might be a bug and not just a staggered roll out.  All the computers in my home that I have Chrome installed on do not update automatically at all.  If it were due to a gradual roll out of some sort, then you'd think at least some of my computers would have an updated copy of Chrome as of now.

I can tell you that I scan my workstations daily (at a minimum) so I have a pretty keen eye on how fast these things update.  When this original thread was started and this last update, it is/was longer than normal.  Usually by the time tenable/nessus knows about the new chrome version, it starts to drop off.  It hasn't been so fast in this case and the original case, we pushed the latest version to avoid catastrophe.

Maybe they knew 51.0.2704.79 was coming out and held back updates?  (as it did yesterday)

Today another stable version was released (51.0.2704.84), but my version is still 50.0.2661.102 :-(
Any idea how to re-open this bug? I don't think anyone will do something with this as long as it is closed...

I'm still on the same version.  No auto updates.  I just don't understand it.

I'm not sure if this has anything to do with anything.  But I just realized my current installations of Chrome are installed in the Program Files folder (Windows 10).  However, I could have sworn Chrome usually installed itself in Appdata.

Also, whenever I manually update (in Help/About), I get the UAC confirmation from Windows before Chrome updates.  So perhaps the auto update *is* running in the background, but can't get past the UAC dialog box.  I don't know how to fix that, though.

I work in an enterprise environment where we have the enterprise version of Google Chrome browser (googlechromestandaloneenterprise.msi) installed on nearly 5,000 Windows 7, 8.1, or 10 systems and automatic updates are enabled.  Currently most of those systems are stuck at version 50.0.2661.102 even though the latest stable release of Chrome is 51.0.2704.  Looking at the two scheduled tasks on the systems GoogleUpdateTaskMachineCore and GoogleUpdateTaskMachineUA, they seem to run without issue and do not generate any errors.  After enabling logging during the update, I see that it returns back "Update check not needed at this time."  A snippet from the log can be seen below.	

[06/08/16 08:40:23.698][GoogleUpdate:goopdate][6744:1680][DllEntry]["C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /c]
[06/08/16 08:40:23.702][GoogleUpdate:goopdate][6744:1680][C:\Program Files (x86)\Google\Update\1.3.30.3\goopdate.dll][version 1.3.30.3][opt][official]
[06/08/16 08:40:23.703][GoogleUpdate:goopdate][6744:1680][is machine: 1]
[06/08/16 08:40:23.705][GoogleUpdate:goopdate][6744:1680][Current dir][C:\Program Files (x86)\Google\Update\1.3.30.3]
[06/08/16 08:40:23.708][GoogleUpdate:goopdate][6744:1680][Started process][6540]
[06/08/16 08:40:23.838][GoogleUpdate:goopdate][6744:1680][Started process][5988]
[06/08/16 08:40:23.849][GoogleUpdate:goopdate][6744:1680][DllEntry exit][0x00000000]
[06/08/16 08:40:26.900][GoogleUpdate:goopdate][6736:2236][DllEntry]["C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" /ua /installsource scheduler]
[06/08/16 08:40:26.905][GoogleUpdate:goopdate][6736:2236][C:\Program Files (x86)\Google\Update\1.3.30.3\goopdate.dll][version 1.3.30.3][opt][official]
[06/08/16 08:40:26.905][GoogleUpdate:goopdate][6736:2236][is machine: 1]
[06/08/16 08:40:26.907][GoogleUpdate:goopdate][6736:2236][Current dir][C:\Program Files (x86)\Google\Update\1.3.30.3]
[06/08/16 08:40:26.908][GoogleUpdate:goopdate][6736:2236][GoopdateImpl::DoUpdateAllApps]
[06/08/16 08:40:27.044][GoogleUpdate:goopdate][6736:2236][Update check not needed at this time]
[06/08/16 08:40:27.046][GoogleUpdate:goopdate][6736:2236][Update all apps process finished][0x0]
[06/08/16 08:40:27.048][GoogleUpdate:goopdate][6736:2236][DllEntry exit][0x00000000]


If I go to "chrome://help/" and let the updater run from there, it will update the browser to version 51.0.2704. Why doesn't the updater when run from the scheduled tasks find the update and install it?

I know that the updater in help about is running in the context of a user account with administrative rights on the system while the scheduled tasks run in the "NT AUTHORITY\SYSTEM" context.  Both of those accounts should have enough privileges to run the updater, so I don't think it's a permission issue.  

Yesterday, I upgraded my Windows 7 to Windows 10, and today my Chrome has updated to 51.0.2704.84 ... 

We're experiencing the same issue.

On Jun 18th we pushed out 51.0.2704.63 the msi installer via SCCM.
On Jun 24th we enabled auto updating via the Google Update gpo.
As of Jun 29th almost all of our workstations have only upgraded to 51.0.2704.103m, which makes no sense to me as 51.0.2704.106 is the current version.

Our Google Update GPO consist of:
Enable "Allow Installations" for Google Chrome and Google Chrome Binaries
Enable "Update Policy override", setting it too "Automatic silent updates only" for Google Chrome and Google Chrome Binaries
Enable "Update policy override default", setting it too "manual updates only"

So to reinterate Our Google chrome did update but it didnt update to the latest version.

When I look at the request and response messages sent from Google Update in Sawbuck I think I can see an issue.

                <app appid="{FDA71E6F-AC4C-4A00-8B70-9958A68906BF}" brand="" client="" lang="" nextversion="" version="51.0.2704.103">
                                <updatecheck updatedisabled="true"/>
                                <ping ping_freshness="{89463AC3-43A5-4C8B-817C-52CEA4FB3860}" r="1" rd="3466"/>
                </app>

See the attached screenshots, what is this new software GUID {FDA71E6F-AC4C-4A00-8B70-9958A68906BF} used for? Google Updater doesnt seem to be handling it properly.

I think this issue needs to be escallated as corporate users are being left with unpatched versions of chrome

  

Deleted: request.png 61.1 KB

	request.png 61.1 KB View Download

Deleted: response.png 33.5 KB

	response.png 33.5 KB View Download

Is there anyone here who knows how to re-open this case? I have version 51.0.2704.103 on my computer at the moment, which was released 40 days ago. 33 days ago, version 51.0.2704.106 was released, and 6 days ago they released version 52.0.2743.82 ... 

This really needs to be fixed!

I'm still impacted as well.  Hasn't auto-updated on any of my machines.  It's maddening!

I manage a few thousand Windows machines, and I'm also seeing this issue.  The last version to be deployed via auto-update was 51.0.2704.103.  We've removed all GPOs that affected Google Update as part of our troubleshooting, but it hasn't made a diffrence.  All clients are Win7, running the 64-bit msi version of Chrome.  Sawbuck shows requests that look like:

<request protocol="3.0" version="1.3.31.5" shell_version="1.3.30.3" ismachine="1" sessionid="{8596C251-28B8-421D-B325-4C8263E88534}" installsource="core" requestid="{7A5EC38B-08D4-4DDD-8B2E-9C0712250488}" de
dup="cr">
  <hw physmemory="16" sse="1" sse2="1" sse3="1" ssse3="1" sse41="1" sse42="1" avx="1" />
  <os platform="win" version="6.1" sp="Service Pack 1" arch="x64" />
  <app appid="{430FD4D0-B729-4F61-AA34-91526481799D}" version="1.3.31.5" nextversion="" lang="" brand="GGRV" client="" installage="23" installdate="3479" cohort="1:9co:" cohortname="Everyone Else">
    <updatecheck />
    <ping rd="3503" ping_freshness="{DBF95118-80D2-4060-8520-FEBAB00DF391}" />
  </app>
  <app appid="{4DC8B4CA-1BDA-483E-B5FA-D3C12E15B62D}" version="51.0.2704.106" nextversion="" ap="x64-stable-multi-chrome" lang="" brand="GGRV" client="" cohort="1:b8:ffx@0.05" cohortname="Stable">
    <updatecheck />
    <ping active="0" rd="3503" ping_freshness="{AEFD8B11-6343-49F3-A6B0-2A0AF533E71C}" />
  </app>
  <app appid="{8A69D345-D564-463C-AFF1-A69D9E530F96}" version="51.0.2704.106" nextversion="" _numaccounts="1" _numsignedin="0" ap="x64-stable-multi-chrome" lang="" brand="GGRV" client="" experiments="CrVar1=
3312309;CrVar2=3300161" installage="23" installdate="3479" cohort="1:gu:" cohortname="Stable">
    <updatecheck />
    <ping active="0" rd="3503" ping_freshness="{B5A4A115-1B53-46E4-B718-8DF4D48AB4D4}" />
  </app>
  <app appid="{FDA71E6F-AC4C-4A00-8B70-9958A68906BF}" version="51.0.2704.106" nextversion="" lang="" brand="" client="">
    <updatecheck />
    <ping rd="3503" ping_freshness="{A6EE4931-C886-4630-9E00-8E98FAA248D2}" />
  </app>
</request>

Responses look like:

<response protocol="3.0" server="prod">
  <daystart elapsed_days="3502" elapsed_seconds="71662" />
  <app appid="{430FD4D0-B729-4F61-AA34-91526481799D}" cohort="1:9co:" cohortname="Everyone Else" status="ok">
    <updatecheck status="noupdate" />
    <ping status="ok" />
  </app>
  <app appid="{4DC8B4CA-1BDA-483E-B5FA-D3C12E15B62D}" cohort="1:b8:ffx@0.05" cohortname="Stable" status="ok">
    <updatecheck status="noupdate" />
    <ping status="ok" />
  </app>
  <app appid="{8A69D345-D564-463C-AFF1-A69D9E530F96}" cohort="1:gu:" cohortname="Stable" status="ok">
    <updatecheck status="noupdate" />
    <ping status="ok" />
  </app>
  <app appid="{FDA71E6F-AC4C-4A00-8B70-9958A68906BF}" status="error-unknownApplication" />
</response>

 Issue 625669  has been merged into this issue.

Everything is okay with your configurations. Your machines have not updated as a result of internal deployment decisions. We've started a conversation internally to see how we can better communicate the release rollout process. I hear that things are confusing now when we announce a new stable release, yet it takes a long time for your machines to update to it. I hope we can do something better in the future. Thanks for your feedback.

Thank you for your comment.  It would be very useful to us if you could explain the expected behavior.  I don't think anyone here is reporting that they don't get Chrome updates instantly and calling that a bug, we're saying that weeks, or even months after a new stable release, we're still not seeing updates.  There are published vulnerabilities (http://googlechromereleases.blogspot.com/2016/08/stable-channel-update-for-desktop.html) for the versions of Chrome we have on our machines and seemingly the only way we can update them is to bypass the auto-update mechanism and push a new msi.

Thanks for the good feedback. I understand where you're coming from. We are continuing discussions regarding how we can do better.

52.0.2743.116 is now being delivered to all clients requesting an update, so you should find that your clients are picking up the update soon.

That seems to be correct, my computer has updated to that version indeed!

I still wonder why the decision was made not to offer the latest version to clients... Maybe if you tell us a bit more about it, we could be more understanding?

 Issue 662389  has been merged into this issue.

 Issue 701728  has been merged into this issue.

We found a simple solution for the "delayed" roll out of updates when relying on the GoogleUpdateTaskMachineCore Schedualed task.  Just modify the task so it uses the"update2web-ondemand" installsource string.  While looking at the differences from a help / about update vs the scheduled update, the major difference is the installsource string in the outgoing http string sent to Google.

the Google update server will always reply back with the lastest version to a "update2web-ondemand"

To force an update now don't forget to reset the following reg key :

reg add HKLM\SOFTWARE\Wow6432Node\Google\Update /v LastChecked /d 0 /t REG_DWORD /F

Change made to the task :

SCHTASKS  /Change /TN GoogleUpdateTaskMachineCore /TR "'C:\Program Files (x86)\Google\Update\GoogleUpdate.exe' /ua /installsource update3web-ondemand"

My pc is still running 56.0.2924.87. The first v57 was released almost a month ago. Why oh why don't you release the newer stable versions sooner? 

I can confirm that modifying the "GoogleUpdateTaskMachineUA" scheduled task's arguments from "/ua /installsource scheduler" to "/ua /installsource update3web-ondemand" resolves the issue.

It's very frustrating that Google's been throttling the v57 update nearly a month when it's supposed to resolve a bunch of High security vulnerabilities.  At the very least, make it so enterprise installations get security updates immediately so we can placate our Nessus-wielding overlords.

Hi, has anything changed in the last 6 months to resolve this issue? are we still needing to manually change scheduled tasks to ensure machines are updated when a new version is released rather than the machines requesting the update? thanks 

Comments 5 and 26 explain that delays in updating are due to Google performing slow rollouts of updates. In some cases, these rollouts are much slower than we would wish.

I'm curious to understand why this is a problem for your organization. There have been cases where we've halted a stable release while waiting for a bug fix to land. In these cases, it may be in your best interest to allow your machines to receive the updates whenever they receive it rather than trying to force them to update.

In general, if you require a specific update schedule, you may be better off using the enterprise installer (MSI) and pushing it to your fleet on your own schedule.

I think part of the issue is that Google doesn't have any clear documentation on how long an organization can expect to wait for a patch when using the automatic updater.  Outside of this thread, I'm doubtful that there's much awareness that Google throttles Chrome updates the same as they do with Android.

For example, DISA's Chrome STIG that the DoD is using as a baseline for locking down Chrome requires that auto-updates be turned on.  (V-44805).  The STIG check goes on to say "the timely update reduces the window for zero day attacks".  That reasoning sorta breaks down if patches with high-security fixes can take roughly a month to deploy through the automatic channel like what happened with 57.0.2987.98.

Having a clear-cut, visibly documented policy that stable updates are guaranteed to deploy within X days or weeks would go a long way.  If there's no supported GPO option to bypass the throttling, then it should be in the Chrome documentation that Google recommends MSIs and not the auto-updater for *rapid* security updates.  I don't believe the bugtracker is the best way to convey this information since it can be hard to find.