Bernie, could you help triage this issue ?

Andrew, do you know whom would be best to investigate this?

Igor, I'm guessing what we have here is an enrolled device (ownership in install attributes) but device policy file is unreadable (maybe due to disk corruption)?

I think we should probably be handling this case with a stateful partition clear (driving device through FRE) - WDYT?

+dkalin

Doesn't look like a disk corruption, according to logs the device went through re-enrollment on Dec 13 and the first policy fetch returned an error:
[1295:1295:1213/162459.518228:WARNING:device_management_service.cc(300)] DMServer sent an error response: 902

I'm checking why the device still managed to enroll, since the policy fetch failed.

Denis, could you help with understanding what error 902 for server means?

Error is kPolicyNotFound. I have no idea what this means though and how that could ever happen for a newly-enrolled device, but definitely seems like this should map to an enrollment error.

The device policy fetch that fails happens after enrollment actually. It's triggered after the device is enrolled:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/enrollment/enrollment_screen.cc?l=333

Also the session manager saved the policy on disk as result of enrollment process:
2017-12-13T16:24:58.770141+09:00 INFO cryptohomed[1482]: Firmware Management Parameters created.
2017-12-13T16:24:59.189751+09:00 INFO cryptohomed[1482]: Encrypted partition finalized.
2017-12-13T16:24:59.195016+09:00 INFO cryptohomed[1482]: InstallAttributes have been finalized.
2017-12-13T16:24:59.212999+09:00 INFO session_manager[1268]: [INFO:policy_service.cc(108)] Attempting to install new policy key.
2017-12-13T16:24:59.220333+09:00 INFO session_manager[1268]: [INFO:policy_service.cc(143)] Persisted policy key to disk.
2017-12-13T16:24:59.225764+09:00 INFO session_manager[1268]: [INFO:policy_store.cc(71)] Persisted policy to disk.

Hard to tell now why the next fetch after enrollment fails.

The Customer(14432604) who reported about the affected device can be disabled when they moved the device to the organization “Chromebook”.
The device policy cannot be found only when the device is located in the specific organization. 

ref: 
-Organization name info.
https://drive.google.com/open?id=1WhdPKO5exTFbZGrQ0Mh24H3kkNWmzZwru-hTXxdPZmU

-Chrome policy (when the affected device is located in “Chromebook”) 
https://drive.google.com/open?id=1-efCWFrBsgsztILPyhPRvlQAULXLsEeS
*chrome://chrome shows that “Policy cache is OK” (Screenshot of Chrome policy above) 
https://drive.google.com/open?id=1mV7Id-i6DHwI8havm7l_Qg7_I5tVGrHF


-Chrome policy (when the affected device is located in the specific organization) 
https://drive.google.com/open?id=1i0J--l5KS601rfg3AYTLZN8I7oo8xjqw
*chrome://chrome still shows that “device policy not found” (Screenshot of Chrome policy above) 
https://drive.google.com/open?id=1VU-pj7ZwcTBVbZSkuJanXQIrAtohZivX


Please let me know if there is any updates I can provide to the customer and please also let me know if you have any additional questions. 

igorcov@
the customer has reported and commented "This issue was resolved by deprovisioning the old Chromebook which he purchased in January 2017 with a cancelled license."

I will be glad if you could let us know if the reported behavior is an expected behavior in this situation.
Any information I can update to the customer will be truly appreciated.

I don't understand what the situation is. ryutas@ can you clarify? They bought a chromebook in Jan 2017, but was it provisioned or not? If the license was "cancelled" what does it mean to deprovision it? I guess I don't 100% understand all of the states under which a license can be, but if you've "cancelled" a license such that the device is no longer managed, then of course you can't put it in device disabled mode - it's not managed!

Dennis, can you clarify what you think was going on here in eng-speak? But at this point I'm pretty sure this is WAI.

atwilson@
I would like to clarify the situation.

Customer has 3 Chromebooks (Chromebook A, Chromebook B, Chromebook C).

First, he bought Chromebook A and one license on January 2017 and cancelled the license without deprovisioning the device.

After that, customer bought Chromebook B and Chromebook C and provisioned them successfully.

However, when trying to disable Chromebook B, the configuration to disable the device was not pushed into the device. After moving Chromebook B to a different OU, the configuration was pushed into the device and it was successfully disabled. 

Lastly, this issue was resolved by deprovisioning the Chromebook A. Chromebook B can be disabled in any OU.

+mdrasner

Matt, what does it mean to "cancel the license without deprovisioning the device"?

At this point, this is either customer confusion, or a server-side issue - only Dennis can confirm what happened on the server, so reassigning to him.

Customer would like to know if the behavior is an expected behavior and the Admin console is working as intended.
Please let me know if there are any updates regarding this case.
Thank you for your help.

I'd suggest reaching out to dkalin@ directly via chat if you want an update - this probably isn't on his radar.

Resolving the old bug. It looks like the policy was not applying to the device so the disabled signal was not received. The SLA for policy is 24 hours.