Zero-Touch Rollout with Enrollment OU Drift
A retail chain is deploying 650 Lenovo Chromebooks to 130 stores. The first 120 devices were pre-registered for zero-touch enrollment by a reseller, but the pre-provisioning records were left in the root OU because the reseller's template omitted an enrollment OU. The remaining 530 devices are being enrolled manually by store technicians using a shared Google Workspace account that has the device enrollment privilege. After the first week, helpdesk reports that devices appear under the root OU, where policies allow personal Google accounts, consumer extensions, and no forced re-enrollment. Technicians have responded by powerwashing affected devices, but they re-enroll into the same permissive location. Store managers also report that two devices were enrolled with a technician's personal account after the shared account was locked. The project deadline is four weeks, and stores cannot ship devices back to a central depot.
1. Why does powerwashing fail to place these devices in the intended retail OU, and what should be done for the devices already in stores?
Read the worked answer
Powerwashing is not a policy-selection tool. A wiped device either uses its zero-touch pre-provisioning record or falls back to manual enrollment; if the zero-touch record has no enrollment OU, the device lands in the root OU, and manual enrollment follows the enrollment permissions and placement associated with the enrolling account. Repeating the wipe therefore repeats the same result.
For devices already in stores, first move the enrolled devices from the root OU to the Retail OU in the Admin console. That changes the device policy target immediately, but it does not automatically fix user policy placement, so verify that store users are also in the correct user OU. Do not deprovision working devices just to change OU; deprovisioning removes management and can create a bigger security gap. For any device that must be re-enrolled, correct the zero-touch record or the manual enrollment account placement first. Then enable forced re-enrollment in the target OU so a future powerwash does not return the device to an unmanaged or permissive state.
2. Recommend an enrollment credential and process for the 530 manual devices that preserves accountability and supports forced re-enrollment.
Read the worked answer
Do not continue with a shared, broadly known enrollment account, and never use a technician's personal account. Create a dedicated enrollment identity in the Retail OU with only the privilege needed to enroll ChromeOS devices, enforce MFA, and store its credential in a controlled vault with checkout logging. Restrict enrollment permissions so that this identity can enroll only into the Retail OU, not into the root or other sensitive OUs. Require technicians to record serial number, store, asset tag, and enrollment time against the enrollment session.
If the reseller can pre-register the remaining serials, use zero-touch for as many of the 530 as possible and reserve manual enrollment for exceptions. Enable forced re-enrollment only after the device is in the correct OU, because forced re-enrollment is a control that assumes enrollment will return to a trusted configuration. Test the full cycle on one device: enroll, confirm OU placement, powerwash, confirm automatic return to the Retail OU, and verify that the device cannot enroll through the old shared account. Finally, rotate the shared account credential and review audit logs for the two personal-account enrollments.
3. Which policies belong at the root OU versus the Retail OU to reduce blast radius?
Read the worked answer
The root OU should carry only controls that must never be absent: forced re-enrollment, developer-mode blocking, a restrictive sign-in policy, safe browsing at an appropriate level, and baseline extension controls that do not depend on store operations. Root should not carry store-specific kiosk settings, printer configurations, or permissive extension allowlists. Keeping root minimal reduces the chance that a misplacement grants broad capability.
The Retail OU should carry the operational policies: the approved extension allowlist, URL blocking for consumer file-sharing, managed network and printer settings, power and update rules, and sign-in restrictions appropriate to shared store devices. If some stores need a different printer or app, create a child OU for that exception rather than loosening Retail. Also verify that user OUs mirror the device OUs; ChromeOS device policies and user policies can come from different places, so a correctly placed device can still inherit permissive user settings. Document the inheritance path and test with chrome://policy on a sample device before scaling.