Hi, we normally try to run on latest Android Versions including SP's, only blocking them when we know a major update (A13->A14 etc.) will come so we can test before.
BUT it would be way better to get more control of it, means if an Update is available i would more likely to get notified and "allow" it (that specific OEM version) before it takes place and won't be executed in general.
Also that freeze period can't be longer than 30 days is not so nice, a company should be able to take care as they want/need how long they need to freeze until they enable updates especially if you need to test a lot 30 days can be too short.
Right you are, what you're referring to @Moombas is postpone, which tops off at 30 days. Freeze goes up to 90 with a mandatory cooldown. The cooldown isn't so useful for the use case of frequent update testing, but it's better than postpone.
I normally set deployments to windowed.
A common misconception is windowed is whatever time set by the admin, on the admin timezone, when in fact the time set applies locally to the device, so a window of 2-4am in EST is 2-4am in GMT also.
We also use "Windowed" during night time.
Hmm, ok i think i just remembered wrong and it's 90 days 😉
Sortry for that.
But still it would be way better to enable specific OEM updates instead of freeze, especially if you don'T get informed about an upcoming release (we had an issue inm the past where in a SP the change of Google was implemented that a domain needed to be entered when using certified wifi authentication which was not implemented in the MDM at that point).
