I'm on a non enterprise Asus Flip. Can not change to Beta or Dev.

Version 54.0.2840.93
Platform 8743.83.0 (Official Build) stable-channel veyron_minnie
ARC Version 3433215
Firmware Google_Veyron_Minnie.6588.197.0

Deleted: Screenshot 2016-11-16 at 5.44.13 PM.png 27.8 KB

	Screenshot 2016-11-16 at 5.44.13 PM.png 27.8 KB View Download

A couple of things to note -

- currently, the ASUS Chromebook Flip C100PA (minnie) is missing from https://cros-omahaproxy.appspot.com/all
so we can't tell what stable, beta & dev channel versions are current.

- #c1's device shows the platform version is on the stable-channel but the 'Channel' below shows 'currently on dev channel'
I guess it's possible all three channels are using the same version but it's unusual, I don't see why else it would display that way.

Chromebook Central Topic: 
https://productforums.google.com/forum/#!topic/chromebook-central/esco_yqFZxA

#CBC-RS/TC-watchlist

Note, this issue also occurs on ASUS C202 with the same steps above taken.

@monachow, are you seeing this issue?

t.d.pieper@:
Could you please attach the data from the chrome://policy page?
Also, when you tested a device at version 50, was it in the same OU that you used for reproducing the issue?

emaxx,

Yes, the Device is in the same ou that it was in previously and I have tried moving it (even to a brand new OU) and toggling the settings to make sure they are correct.  Here is the Policy page: https://docs.google.com/a/maranausd.org/document/d/1oXVRtgOSiytV426HdZihkA8qDQ6MZLkQd1-iytnchAo/edit?usp=sharing

I'm still unable to reproduce this issue on a test device (including C100PA Minnie DVT SKU 3 with M54 stable).

Regarding not displaying the device at cros-omahaproxy - we are investigating this, but this is probably a completely separate issue.

t.d.pieper@:
In the meantime, could you please collect the device debug logs using "Store Debug Logs" at chrome://net-internals#chromeos ?
Would be great if you would do this on a freshly rebooted device. Probably also worth doing "Check for and apply updates" at chrome://chrome.

I have now one idea why the channel switch was disallowed in the case from the bug description.
The channel switching on managed devices is allowed only for the users with _exactly_ the same domain as the enrollment domain. This is documented at https://www.chromium.org/administrators/policy-list-3#ChromeOsReleaseChannelDelegated :
> If this policy is set to True and the ChromeOsReleaseChannel policy
> is not specified then users of the enrolling domain will be allowed
> to change the release channel of the device.

It may be discussed how reasonable this behavior is.
At first glance, it seems fine to relax this restriction to include secondary domains too (or, technically speaking, decide this by comparing affiliation ids).


t.d.pieper@, could you please confirm that the issue happens for you only when using secondary-domain accounts?
It seems that it was the case, judging on the policy dump in comment #7 (the enrollment domain is "maranausd.org", while the signed in user has the "g.maranausd.org" domain).


However, I'm wondering whether there are other issues left here, given that handling of secondary domains here doesn't seem to be changed recently (or ever).


RE comment #1:
Could you please describe the steps that lead your device into this state?

@ #11
I tried with the account e@maranausd.org on the same exact device, the "Change channel" button was still greyed out.  I did confirm on the Policy page that ChromeOSReleaseChannelDelegated = true.

So I did some more experimenting with this.  

We use e@maranausd.org as our "enrollment" account (shorter to type).  When I enroll a device under that account, it shows "managed by maranausd.org"

I deprovisioned the device and re-enrolled it as myself (t.d.pieper@g.maranausd.org) and it now says "managed by g.maranausd.org"  It seems it's getting the organization name from the user that enrolled it, not the primary domain (which I think would make more sense to display as the management organization).

With it now being managed as "g.maranausd.org", I am able to change release channel logged in as myself.  I am not able to change the channel when signed in as e@maranausd.org.

I deprovisioned/wiped/re-enrolled again as e@maranausd.org.  I was able to change the channel logged in as e@maranausd.org but not as myself.  

I then reset the device WITHOUT deprovisioning it (turn OS verification off+on) and at the enterprise enrollment screen came up (as expected since it was still provisioned).  It auto-completed "@maranausd.org" since that was the last organization that "managed" it.  I typed in t.d.pieper@g.maranausd.org at the enrollment screen and lo and behold, it is now managed by g.maranausd.org.  

It seems that anyone in the organization can reset a device and log in as a user within the organization with a different domain and thus change the "managed by" domain.  The enrollment options under User Policies (like "Do not allow users to enroll new or deprovisioned devices") don't take effect because the device is still technically provisioned.  

Should I rewrite everything above and post a new issue for the "managed by" domain changing?

Re #13: t.d.pieper@, yes, please file the issue with the management domain changing separately, so that it can be discussed specifically. (It may turn out that the displayed management domain is intended mainly for the informative purposes.)
Thanks for confirming that the problem with the release channels was related to secondary domains to you. I've filed a separate issue 674561 for tracking this.


Are there any other reports for this bug?

As there are no other reports here, duping this bug to the one that tracks release channel switching for secondary domains.