+Matt +Thiemo +Bin

Sounds like a very valid point. Any idea if this is working by design?

Sounds like a server issue to me.  I don't think there's anything on the client that distinguishes first from subsequent enrollment.

This is by design. Anyone in the domain can wipe the device and then enroll the device. If we do OU auto placement for subsequent enrollment after the first one, it means the device can just randomly move without admins know about it.

I would like to understand the use case a bit better. Why do you need to wipe the device? Why not just move the devices in CPanel to the correct OU? It should be faster than wipe and enrolling.

We want to give chromebooks to users without manually entering them in
their OU and keeping manual records of what user has what CB. It is a very
work intensive situation right now everywhere in schools with chromebooks.
A typical school start 1000 devices change hands and 4000 users/devices
change OU. We have almost one full time admin doing this right now.

Would also help greatly on our large rollouts as we could just hand out CBs
to the teachers and have them in the right OU and knowing what user have
what CB. Today the only way is manual work and being there in person.

What we desperately need is some way of minimizing manual management, and
having the enrollment stay but the user and OU getting updated would make
that possible.

CBs changing OUs are not an issue as long as they follow the enrolled user.
Every single CB we have is strictly personal.

We ran Linux LTSP before so we dont have a large it group.

Den 11 sep. 2016 3:08 fm skrev "binz… via monorail" <
monorail+v2.3539765608@chromium.org>:

Most of our setting are user settings. So as long as the users logs in, no matter which device they use, they will get exact settings.

Why do you want a device to move to a different OU depending on which user owns that device? Do you have different device settings for different OUs? Can you give me one example the different device settings for different OU?

We have our users divided by school form/School/grade/class. Its just a
very convinient way to find what chromebooks belongs to what class.

When we put CBs of a class in kiosk mode for tests, this usually dont
happen all at the same time so we want to be able to do this class by class.

The inactive device report is by OU so having the devices in other OUs than
their users are not optimal imho.

The message displayed for stolen or lost CBs are on device level. Our
municipality covers a huge area so having it set school by school is a
great help.

Its also nice to have the real user in the user field since its trickier to
find a users CB on Last User.

I understand the reasoning behind current behaviour, but back then you
could get the devices prepped from mfg.

Den 11 sep. 2016 8:15 fm skrev "binz… via monorail" <monorail+v2.3539765608@
chromium.org>:

Thanks for sharing the use cases.

I think now your existing flow is to wipe the device, hand over to the students to let them enroll and want the devices to be placed under student's OU. I am wondering why not just move the device under student's OU then hand it over. This way, you don't have to wipe the devices, which takes longer than moving in CPanel. Is there any particular reason you prefer wiping than moving?

The reason it is hard to pre-populate OU and user is that there are so many
CBs changing owners every year.

We technicians have to be in place to deliver each and every chromebook.
What i strife for is to be able to let teachers themselves give them out to
the students.

If a student quit, It would be great if a teacher just wipe It and give it
to another student.

Since It is schools, we have a 10% repair rate and keeping track does take
effort.

We do like you suggest right now tracking each CB manually. It is a
workload that can be reduced significantly if the re-enroll behaviour would
be like first enrollment. It does not have to be the default, just
something you could choose.

Den 12 sep. 2016 5:44 fm skrev "binz… via monorail" <
monorail+v2.3539765608@chromium.org>:

I think the key advantage of the scenario Daniel describes is that the association between user and device is only established at the time of enrollment.  This allows to have a stack of wiped devices and then just hand them out to users as they come without having to track which user received which device.

Maybe we could add a CPanel configuration to disable OU stickiness?

Adding an option to disable ou stickiness and registered user info would
solve this for us in.a very good way.

Could also be partly solved by making last user easier to see in cpanel,
preferably as a list column.

Den 12 sep. 2016 7:05 em skrev "tna… via monorail" <
monorail+v2.699316784@chromium.org>:

Daniel, I think you make a good case for how you use it.

Matt, what do you think?

Taking ownership for now while I consider a solution that could solve the use case here without negatively impacting other customers who are used to allowing re-enrollment to not make any management changes.

Will update once possible solutions are determined.

Sounds great, appreciate it :)

Den 12 sep. 2016 9:45 em skrev "mdras… via monorail" <
monorail+v2.1891593566@chromium.org>:

Why has nobody commented that there is such a setting already? Not even a reference to it being broken. 

The default setting is to "keep device in current OU". But it can be altered to "move to OU of enrolling user". 

Because this setting only applies on first enrollment. What i can decipher is that current location refers to the root/ at first enrollment. So you can choose to have the CB moved to user OU at first enrollment or stay in root. 

In any successive re-enrollment it will not move at all unless you totally deprovision it and start the enrollment from scratch again.

Google has documented this pretty well here:
https://support.google.com/chrome/a/answer/2657289#enrollmentcontrols

"Note: This policy will only take effect if the device is being enrolled into the domain for the first time or the device was previously deprovisioned."