When a Chromebook gets an update it looses the Device Policy Problem

[Andrew Dreher]

Hello Everyone,

I'm curious to see how anyone who has deployed Chromebooks are handling the updates to the Chrome OS.  We are testing 60 Chromebooks (two carts of 30) before we deploy over 5000.  It hasn't been two full weeks and my Tech's are already starting to pull their hair out.  When a Chromebook gets an update it looses the Device Policy.

We have a few things configured under "Device Settings", plus under Networks / For Devices, we have the Wi-Fi connection setup.  The Chromebooks came with Chrome Version: 23.0.1271.93 (build 168710).  Last week, they were updating to Google Chrome: 25.0.1364.173 (Official Build 187606).  After this update was applied the Chromebook lost the Device Policy.  The Device Policy has the information on how to connect to our wireless network.  This is a Huge problem!  Now that Chromebook can't connect to the network and the Teacher can't use it.  

I think that if a student that has already logged into the device might still be able to login.  Our issue is that these devices are being used by various students in various classrooms throughout the day.  After a device has lost the Device Policy, we have to have a Tech reconnect that device to the wireless network before a student can login...per class peroid.  A one-to-one environment might not have such a headache over loosing the wireless network information.  In a Lab environment, which is how we are planning on deploying these devices, loosing the network connection is a Huge problem.

I've done some research and there doesn't seem to be a way to force a Chromebook to do a Device Policy re-sync.  If I go to chrome://policy, I can re-sync the user policy but not the device.  I've clicked on the "Reload policies" button on a device that hasn't re-synced in over two days.  The only way I have found to get the Chromebook to re-sync the Device Policy is to wipe the device by switching to developer mode and then switching back.  We went through this fight last week and now this week there getting the Google Chrome: 26.0.1410.57 (Official Build 191765) update.  This update is causing the same thing all over again.  Loosing the Device Policy on a weekly basis has our Administration thinking of pulling the plug on our Chromebook project.  

Has anyone else experienced this problem?  If so, how have you fixed it?  Do we just turn off updates?  How do we keep the Chromebooks from loosing the Device Policy?  When it does, how do we force it to re-sync?

Thank you for your help! :-)

Andrew Dreher

McHenry School District 15

O 815.385.7210

C 815.388.2065

[Mike Pullen]

We've seen a few Chromebooks "lose" device policies in the last few days (for example, start showing user icons at the login screen instead of just username and password fields), and my _hunch_ is that a quirk in the most recent update is causing this. Chrome://policy does show the policies getting to the machines, but they're not applying.

I haven't been able to gather enough evidence to file a bug report-- but perhaps among all of us there is enough! Have other seen things like this recently?

Andrew, fwiw, this is the first time in two years we've seen anything like this particular issue-- typically, ChromeOS updates are really seamless and add quietly functionality without breaking anything. My philosophy when things like this happen (as they do occasionally with any device/OS!) is to try to Keep Calm and Carry On, and to encourage our users to do the same. Google has consistently very quickly remedied any recurring issues we've ever seen with Chrome and ChromeOS!

Mike

--
--
You received this message because you are subscribed to the Google
Groups "Google Apps K12 Technical Forum" group.
To post to this group, send email to k12ap...@googlegroups.com
To unsubscribe from this group, send email to
k12appstech...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/k12appstech?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "Google Apps K12 Technical Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to k12appstech...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jaymon Lefebvre]

District of 5100 students.. we've rolled out just shy of 400 Chromebooks.  This is sort of our pilot.. but really, as we have been GAFE for 3 years we know the direction we are going.

Of the entire 400 we have rolled out since January, 1 unit has been returned to us for failing policy.  I dev'd it, and enrolled it and sent it back and have not heard anything since.  I suspect the initial enrollment was done incorrectly (if you use a two factor account to enroll it only goes half way through the enrollment process).

So Im just saying, that is a totally bizarre issue you are having.  Instead of having technicians pull their hair out, why not engage Google's free support system for Google Apps for Education customers?

I personally use my Chromebook more than any other device and I roam between schools, my home, work, hotels, and the delegated networks have been nothing short of perfectly reliable.

cheers,

Jaymon

--

[Jaymon Lefebvre]

Interesting enough Mike, the one unit we had troubles with happened last week.  I was told it did it 3 times in a row.. but I was on vacation.  When I returned, I did it myself and thus far, havent heard anything.

Jaymon

[Mike Pullen]

Jaymon--

We just deployed an additional ~200 units the beginning of the month, bringing our total to ~700 district-wide. I've seen the issue with just a couple of the older ones (Samsung 500s) the last few days, but with several of the newer ones (Samsung 303Cs). Wiping and reenrolling clears up the problem here too, but obviously we'd like to see the problem go away! : )

Thanks,

Mike

[Jaymon Lefebvre]

The cat came back.  Oh no!  Its actually happening to us now.

Im calling Google.

[Terry Korte]

Hi guys, 

We have roughly 3500 Chromebooks - mostly Samsung 5's and recently adding a few hundred 303's.  We haven't seen this issue yet, but there is something policy-related that I received help from Google with that may shed some light.

We have users separated into several sub-orgs.  Each of these sub-orgs have different policies for both "User" and "Device" settings.  When I changed the "Device settings" for the student sub-org, it didn't take effect because all of the Chromebooks are in the root organization.  You may or may not be moving devices into different sub-orgs, but it appears that the settings for the org that the devices belong to trump the settings for the org that the user belongs to. 

This may be obvious, but it wasn't to us.  

In our example, we wanted "erase all local data on sign out" for students only, so we applied this setting in our "students" sub-org.  The setting is under "Device Settings".  Result: no effect.

All Chromebooks are in our root organization.  We changed that same setting there.  Result: Changed setting for all Chromebooks in all orgs.   I know we could move chromebooks into different orgs, but with the number that we have, that's not so easy.

Anyway, maybe this sparks some ideas to troubleshoot this issue.

[Andrew Dreher]

We have a "Students" sub-org that has our wireless network settings setup under the "For Users" and "For Devices".  We then moved the Chromebooks into the sub-org.  With everything dropping off the network, we then added the wireless setting to the root organization too.  

To add to this, I've got two Chromebooks that I've been testing to see when the device will re-sync the Device Policy.  It's been over three days and they still haven't re-synced.  I'm beginning to think that they're no longer Enrolled to our organization.  On a working Chromebook, under chrome://policy I can see that the Device Policy is set to refresh every three hours.  It's been three days of use, not sitting off to the side.  I'm typing this email on one of them.  I'm hoping that if I'm connected to the network that it will eventually re-sync.  My hope is diminishing.  It looks like it's not only losing the Device Policy but it's also losing it's Enrollment.

This might not be an issue if this were a one-to-one.  When a student is logged in and they run the update.  It updates and reboots.  Now that student can log back in.  Everything is good until they log out.  As soon as they log out, the network drops.  The next student in the next class now can't log in.  The Device Policy is lost and the wireless network setting are lost.  We have to manually connect it to the wireless network to get the next person to be able to log in.  If the Chromebook is disconnected from the network, the student that did the update can connect to the wireless network because it's configured under the User Policy.  

Andrew Dreher

McHenry School District 15

O 815.385.7210

C 815.388.2065

[Jaymon Lefebvre]

This is what we found when we went to look today.  Im not saying this is the same issue.. As we instantly were able to resolve.  However, that being said all devices we touched today were updating to v26, which perhaps.. might have fixed the insanity.

We managed to find a cart of x303's and sure enough we located a few that were broken.  They were enrolled but they no longer had the default network (hidden SSID with secret PSK distributed from GAFE dashboard).

We noticed some strange behaviour recently in that many of our Chromebooks were showing on our guest network.  We have 2 networks, 1 is a guest network, requiring a click through splash page, visible SSID.  The other is a hidden SSID just for the Chromebooks that DOES NOT have a splash page.  On a few of the Chromebooks, no matter how many times we shut down and restarted, the Chromebook SSID was not visible.  Thus, if there was no other network available we would have been boned.  There would be no way to log the darn devices back onto a wireless network.

As we see on the forum posts, this is why many people are having to send technicians to the site to dev the unit and manually get them back on to retrieve device policy.  In our case, the kids figured out to use the guest network to keep on trucking.  Once we connected these Chromebooks missing the distributed wifi network to the guest network and checked chrome://policy, they had retrieved a device policy update.

Instantly, the Chromebook SSID was available.  At that point, if you shut the unit down, and restart, boom, its fixed and happy.

One thing we saw, was that if you change the wifi SSID at the logon area (instead of after you are logged on), then that SSID is retained until there is a subsequent shut down and restart (providing a device policy update has occurred)