Understanding Automatic Operating system update behaviour
I'm hoping to get a better understanding of the SystemUpdateType policy available for COWP devices, we're currently moving from POWP to COWP for our devices (40K) and are looking to benefit from streamlining as much as possible for our end-users.
Looking at the documentation for the SystemUpdateType policy it isn't described as to whether the Automatic update option would force an Operating System update even if the device is in active use (User on a call, App open and in use etc).
Does anyone have detailed information as to how the Automatic update option works?
I'm hoping to get a reply from a google employee on this if possible.
Below is the link to the documentation for anyone interested.
Thanks for your help.
Not a Googler I'm afraid, but I can tell you that yes, automatic may interrupt ongoing activities on the device.
It is designed to update as soon as possible.
Windowed is a generally better approach to avoid disruption as you can set a time relative to local device time and just ask device users to have it on during this period
Great to meet you.
Good question. As Jason mentions, if you apply an 'Automatic' policy on updates then this policy will automatically install updates as soon as they are available and will trigger a reboot if required. I know if this is not always a viable option depending on the business type and set up.
There are a number of different options you could explore though, I wonder have you come across this recent Help Center article which gives an overview of the different options: Google system updates on device enrolled on Android Enterprise
Is there anything else on the automatic policy you are keen to explore? Do you think the 'Windowed' option may work for you?
Thanks for your responses Jason and Lizzie.
I hadn't found that article so thank you for providing it.
I'd like to see an Automatic update policy where it updates when the device isn't in active use for 30 minutes etc, unfortunately our devices are used worldwide 24/7 so we wouldn't be able to deploy a Windowed option for a specific time frame.
Also, what's the best method to request new features for COWP? We have a few in mind that we are losing going from POWP and would like to understand alternatives or if they will ever be implemented.
Thanks for your help.
Thanks so much for the follow up information @GMenzies. Glad the article is useful. I'll ask internally about your use case and see what we would suggest here. I'll get back to you.
Regarding your feature requests, are these things you are happy to share publicly here in the Community? If so, it would be great to hear if these requests are things that would help others and understand the use cases. It make it easier for me to report back to our product team. If you'd prefer not to share here, just let me know and I can follow up via direct message.
Thanks so much,
Honestly most of this is small requests and some perhaps need to be managed through Microsoft (Our EMM is Intune) or are just how we manage things today and probably need to change.
- We're unable to provide our internal Google Workspace users with the ability to add their domain accounts to the devices, we work alongside Google for Chromebook development so having this option for COPE would be beneficial to improve their workflows and the customer experience we provide to these users so they can use their Android Mobile Devices and Chromebooks side by side, I know this is available for POWP (BYOD) devices in Intune today and we've created a DCR with Microsoft for this. Whether it's a requirement from Microsoft or Google is the next question.
- Our users like to add Work Profile app Widgets to their Home screen, this doesn't seem to be available as a setting for COPE devices (We're working with Microsoft on this to determine if it's available or not for COPE devices, again not sure on who the requirement falls on).
- We deploy a compliance policy with Intune to block devices that have been rooted for our POWP (BYOD) devices, this setting doesn't seem to be available for COPE devices in Intune today (We were told by Microsoft this would be a requirement for Google to make available), the best we can do is use our Device Security solution and a combination of ensuring Device Integrity with Google Play Protect, if you can confirm if Device Integrity is a suitable to detect rooted devices that would be great - https://developer.android.com/google/play/integrity/verdicts#kotlin:~:text=The%20app%20is%20running%....
As I've said these are just a few that we've seen so far and perhaps most fall on Microsoft but I'd love to be able to provide this feedback to Microsoft that they are available and require actions on their end.
Thanks for your help, I've found this forum to be very valuable.
BYOD devices enrol using Intune Company Portal and COPE devices are enrolled using KME. We aren't using compliance to block enrolment, it's an enforcement for Conditional access after enrolment.
So, you use Samsung devices using Knox mobile enrollment (KME).
But in KME you can set per IMEI where devices should go (which enrollment config they should get) even via bulk import. I would recommend to give the different enrollments different targets (with different enrollment ID's) so you have a clean setup and only care about the IMEI's routed via KME to the right config instead of taking care of that somehow in the MDM.
Interesting to what @jasonbayton and @Lizzie wrote is, that I have no option (using our current MDM) to enroll an os update policy to a device using "work profile", only if i enroll it as an fully managed (work managed) device or COPE (Corporate Personall) and then i have the options mentioned by them.
I think BYOD (work profile on private device) is also the correct name for what you are coming from and COPE (company device with work profile) where you are aming for, right?
Even i don't see the difference for the work profile because if the device is company owned (COWP) or private owned (POWP) shouldn't make a difference for the work profile in general or did i miss anything @all?
Or are you talking about COPE @GMenzies?
If yes, then there's no chance to wait until a device is inactive as @jasonbayton already wrote with the slightly difference that even on windowed mode there shouldn't be a prompt (as far as i know). But i think (not tested yet) if you don't configure an update policy the user itself should be able to trigger the update if available.
But you could ask for those functionalitys you loose maybe someone here can help you to find a different solution for work profile or tell you why this is expected not being able to be done on a work.
You're 100% right, we use COWP and POWP internally as we manage more than just Android and it provides an easy way for everyone to understand what's being discussed but your right that BYOD and COPE are the names used by Android.
We use Microsoft Intune so we have some extra settings available for COPE compared to BYOD.
I hope you are doing well.
Thanks so much for sharing the feature ideas, I wonder if you would be willing to start a new post sharing them, or alternatively I can move that specific post and make it into a new topic. There have been a few similar mentions of a couple of the things you mentioned and so I think it would make it easier to focus on them in a dedicated discussion.
Let me know what you would prefer and I'm happy to help.
Thanks so much, looking forward to discussing the more.
It probably makes sense for you to make the topic and users can add to the feature requests as it's coming from a Google Community Manager then, possibly adding an update at the top of the page for collated issues so users can see what has already been added as a request etc.