I could repro this and to be honest it seems like this is not something that has been recently broken. 

I think we should prioritize resolving this asap.

Is this only for Azure AD joined device?

I tried repro with a standalone (Workgroup) device, but Chrome is picking up the registry policies without issue.

Interesting I tried in a standalone Win10 VM in Skytap and ended up not seeing a single policy applied. Which version of Chrome did you try and on which Win version?

So it looks like this was broken in 63 but working on 64.

I tried it on my home machine and Chrome 63.0.3239.132 was not picking up the registry policies.

After updating to 64.0.3282.119, Chrome was picking up and applying them.

I validated that on the first test machine I used, I had already upgraded to 64.0.3282.119.

(Win10 in all cases)

Chrome policies are not being applied in Windows Home (7, 8, 10) as of build 64.0.3282.119. Is this by design?

No, not by design. I tested on Win10 Pro. It might be an issue with Win10.

I'll try to repro soon and will update this thread.

I meant to say: It might be an issue with Windows Home.

It's not Windows Home. It only occurs after updating Chrome to the latest stable build (64.0.3282.119). This has been tested thoroughly on all Windows Home versions 7-10. The easiest way to test is to install GPO on Windows Home, then apply the Chrome adm template, then apply some policy settings. You'll notice that Chrome://policy lists no policies.

Prioritizing repro and bumping to p0.

I was able to reproduce this on standalone win 10 Home device but if i restart chrome ( by closing all chrome process) or upgrade chrome (in this case from 63.0.3239.132 to 64.0.3282.140) then the policy gets reflected. 

Once the policy page has some policy adding additional policies in registry gets picked up when clicking on reload polices from chrome://policy page even without restart of chrome.


Steps used:
1. Install chrome and open chrome://policy ( to see no polices are added.)
2. Add a policy in registry [HKCU/Software\Policies\Google\Chrome\DefaultPopupsSetting] set value to 1 or 2
3. Refresh chrome://policy page or reload the policy. The popupSetting policy is not reflected.
4. Close chrome and kill any process from TaskManager (if any process still running).
5. Restart chrome and visit chrome://policy (they popup policy gets reflected there).
6. Add another policy and this gets reflected even with restart of chrome by just reloading polices from chrome://policy page.

Tested with Windows 10 Home / Windows 10 Pro, Chrome version: 64.0.3282.140

So the issue is that policies are only applied post-restart of Chrome and not in realtime as policies are configured during a Chrome session?  

Yes but once a policy is loaded in chrome://policy page adding subsequent policy gets reflected without restart only the first time when no policies are there it is not reflecting.

Moving to P3.  I consider this a feature request: Support to apply policy in real-time.  To date, this has never been an issue in Enterprise deployments, so it is something we can consider for the future but not a priority right now.

Thank for your the repro/testing! 

Thank you for digging in.

This explains the divergence between our test cases. Thankfully, this is a much lower impact than originally anticipated.

Matt, I'll still change this to P2 as it's a weird behavior (only happens on a fresh install of Chrome), so it's definitely a bug (but low impact).

Hopefully we can tackle it next quarter.

As part of my new year's bug cleanup I verified this bug again and can't observe it on a recent version of Chrome. I started a fresh Chromium build with a new profile and no policies. Chrome showed no policies on the chrome://policies page. I then added some policies by directly manipulating the registry, which doesn't trigger immediate notification because we observe for GPO changes not direct registry changes and after 15minutes (currently the polling interval for changes) the policies appeared. Another test I did was instead to set a policy by GPO and this time the change appeared as soon as I ran gpupdate /force on the computer. Therefore I am going to close this bug now. If someone still observes the issue please describe precisely the steps you followed to recreate it or even better record a screencast of it to make it easier to reproduce.