Will this be in R/O or in R/W VPD? How does Chrome distinguish the source and if it doesn't is R/W VPD a risk?

It is in RW_VPD and the flag is written when the policies are stored. But we never store zero value there yet. The only place where that flag is set, is when the device is enrolled:

https://cs.corp.google.com/chromeos_internal/src/platform2/login_manager/device_policy_service.cc?type=cs&q=kCheckEnrollment+package:%5Echromeos_internal$&l=581

Probably makes sense to have a CL that will set the value to zero for device owners.

Chrome doesn't distinguish the source (https://cs.corp.google.com/chromeos_public/src/platform/vpd/util/set_binary_flag_vpd?q=set_binary_flag_vpd&dr=C&l=24) but the flag is set every time the device is enrolled.

I don't think it's a risk because adding enrollment_check=0 is the functional equivalent of removing the ActivateDate entry.  We're not opening up something that doesn't exist already.

That's fine, your call. I just wanted to double-check because the original design intended FRE to work regardless of any R/W state present on the device. ActivateDate has caused various pain already, and wasn't intended to be there by the original design.

Imho getting rid of the FRE server ping fit consumer devices is a significant boon.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/d16272bee708daf7de4c2d00ee9ef35372936eab

commit d16272bee708daf7de4c2d00ee9ef35372936eab
Author: Igor <igorcov@chromium.org>
Date: Wed Dec 21 15:52:01 2016

login: The check_enrollment flag is always provided in vpd update

The "check_enrollment" flag should provide the information if FRE
check can be skipped. To achieve that, it needs to be always up to
date. This change updates the flag, if changed, every time the
device policy is stored.

BUG= chromium:645464 
TEST=None

Change-Id: Ie6f357a7a6e5e070a8f18987932f689b524c49cf
Reviewed-on: https://chromium-review.googlesource.com/422323
Commit-Ready: Igor <igorcov@chromium.org>
Tested-by: Igor <igorcov@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Reviewed-by: Thiemo Nagel <tnagel@chromium.org>

[modify] https://crrev.com/d16272bee708daf7de4c2d00ee9ef35372936eab/login_manager/device_policy_service.cc
[modify] https://crrev.com/d16272bee708daf7de4c2d00ee9ef35372936eab/login_manager/device_policy_service_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2e071f8aa1ccab5eb8467fb6f3cb6d2188fbbe81

commit 2e071f8aa1ccab5eb8467fb6f3cb6d2188fbbe81
Author: igorcov <igorcov@chromium.org>
Date: Tue Dec 27 11:38:30 2016

Fixed the timeout when state keys generation is late

The state keys are not generated as long as the time hasn't been
synchronized. These changes fix the case when the state keys generation
is late, possibly for the network missing reason, and the controller
hits the timeout.

The timeout can happen at establishing the ownership, or later at
state keys check. Without state keys check we cannot assume we can
skip FRE. If the ownership is established and FRE can be skipped
(OWNERSHIP_TAKEN or OWNERSHIP_UNKNOWN), the new state is set
immediately, so the timeout cannot trigger.

TEST=Manually tested on a falco chromebook.

BUG=673270,  645464 

Review-Url: https://codereview.chromium.org/2587033002
Cr-Commit-Position: refs/heads/master@{#440748}

[modify] https://crrev.com/2e071f8aa1ccab5eb8467fb6f3cb6d2188fbbe81/chrome/browser/chromeos/login/enrollment/auto_enrollment_controller.cc
[modify] https://crrev.com/2e071f8aa1ccab5eb8467fb6f3cb6d2188fbbe81/chrome/browser/chromeos/login/enrollment/auto_enrollment_controller.h

@tnagel,igorcov: any steps to make check_enrollment=0.How should we test this?

This has been rolled back. The plan is to make it available only in M-59

Sorry, previous comment was meant for other ticket.
This should be available in 57.
But you will need to set check_enrollment = 0 manually. Use:

vpd -i RW_VPD -s check_enrollment=0

Now, to check this implementation after that, one way is to
take an enrolled device, set the flag to zero with command
above and recover it. The effect - FRE should be skipped.

Do not see enrollment screen after check_enrollment=0 but device is forced to go to normal mode and when we actually try to enroll to some other domain,an error is displayed "Device cannot be enrolled to domain your account belongs to because the device is marked for management by a different domain"?

Is this as expected?

M	ChromeOS	Chrome	ARC	Type	Channel
57	9202.18.0	57.0.2987.32	3704776	release	beta

Steps followed comment #18:

Enrolled device
Added vpd -i RW_VPD -s check_enrollment=0
Force Enrollment enabled
Wiped again to recover

Actual Result:Normal mode enforced.Do not see enrollment screen, i.e looks like FRE skipped.

After this pressed ctrl+alt+e to enroll to different domain and could not enroll to that domain.

Could enroll successfully in same domain.Does this mean still it's forcing enrollment in the Background?

Re #18, that happened probably because FRE was active on server side. But the
device was acting correctly by skipping FRE. It didn't check the FRE on server
side because flag locally was set to zero, so the behavior is as expected.

As per comment#21 marking this Verified.