Welcome to an easy, go-to reference to help you manage single-user devices, multi-user devices, education devices, kiosks, billboards, factory machines, and more.
In my January 19th blog on why you shouldn't set these 25 Windows policies, I shared how the Windows update experience has evolved over the last few years, how that impacts the Windows update policies we recommend, and a list of which Windows update policies you should not set and why. Driven by your feedback, I now want to share a list of the policies you should be setting and offer insight on why those policies can be helpful when managing updates for a variety of use cases, specifically:
- Single-user or personal devices
- Multi-user devices
- Education devices
- Kiosks and billboards
- Factory machines, rollercoasters, and similar things
- Microsoft Teams Rooms devices
Leverage the defaults
Let's start with the basics. Our recommendation? The fewer policies, the better. Leverage the defaults! The default experience is often the best experience for ensuring that users remain productive and that their device(s) remain secure. By default, devices will scan daily, automatically download and install any applicable updates at a time optimized to reduce interference with usage, and then automatically try to restart when the end user is away. For most scenarios, this is the best experience. In fact, it is also what hundreds of millions of Windows users experience on their home or personal computers.
That said, below you will find some common use cases we see in various organizations with a list of additional supported controls you may want to leverage in order to meet that scenario's specific user experience requirements.
All policies discussed below can be found in the following paths:
- Group Policy path: …/Windows Components/Windows Updates/Manage end user experience
- CSP database: Policy CSP - Update
Policy settings for managing the end user experience as they appear under Windows Update settings in the Local Group Policy Editor
Managing single-user devices
Single-user devices are user-owned or corporate-owned devices used by a single person. In addition to personal computing tasks, these devices might also be used for hybrid work activities including meetings, presentations, and any number of other tasks. For any of these tasks, interruption would hinder productivity. Given that these devices are often connecting to corporate network(s) and accessing sensitive information, it is imperative they stay secure. Given that heightened need for security, there are some supported policies that should be considered.
This scenario may require:
- Fewer disruptions during the workday or when actively using the device.
- Device can't be taken down during meetings and/or presentations.
- All data must be saved.
- Want to have some level of control over their device.
- Devices must meet a specific compliance standard.
Note: All the requirements, outside of ensuring devices meet a specific compliance standard, are achieved by the default experience.
|
Policy |
Description |
When to set it and why |
|
GP name: GP setting names: For feature updates: ConfigureDeadlineForFeatureUpdates, |
This policy allows you to specify the number of days before an update is forced to install on the device during active hours, when the user may be present. |
This policy is always recommended for commercial or education environments where there is a compliance need or where it is pertinent that devices stay secure.
Note: Security is paramount from our point of view, and deadlines are a great way to ensure such. |
Specifying deadlines for automatic updates and restarts through policy
Multi-user devices
Multi-user devices are shared devices that are used by multiple people over a period of time. This is a common scenario especially for devices like a HoloLens or a PC that is being used in a laboratory or library setting. For these devices, there may be a set period when they are able to be used. For example, if they are plugged in overnight in a laboratory that doesn't allow access post 12AM, you could confidently update them at that time. Additionally, you likely don't want to have the end user schedule the update as they may inconveniently schedule it during a time another user is present, which would result in a poor experience.
This scenario may require:
- Few to no notifications during the period of use.
- No automatic reboots during the period of use.
- End user(s) shouldn't be able to schedule the reboot.
- Scheduling automatic wake and reboot for a specific time.
- Devices to stay secure and protected.
Note: Most of the above can be achieved through the default experience with no policies configured. That said, if the default experience is not meeting your needs, you can consider the following.
|
Policy |
Description |
When to set it and why |
|
GP name: GP setting name: |
This policy enables you to manage automatic update behavior.
Schedule install time (3) restricts the device to installing at that specified time until deadline is reached. |
If the policy is not configured, end-users get the default behavior (Auto install and restart). If no day and time are specified, the default is 3 AM daily.
This policy is only recommended if there is a regular specific window when the multi-user device will not be in use. |
|
GP name: GP setting name: |
This policy will remove the end user’s ability to scan, download, or install from the Windows Update settings page. |
This policy is only recommended if you have end users who are configuring update settings and causing update behaviors that are disrupting other users who share the device. |
|
GP name: GP setting name: |
This policy enables you to specify the hours during which a device should not restart.
This overrides the default intelligent active hours, calculated on the device based on user usage. |
We recommend that you simply leverage the default, built-in intelligent active hours that are calculated on the device.
That said, you can leverage this policy if you feel it necessary and if there is a set period of time during which the device is allowed to be used or during which reboots are unacceptable. For example, if this is a device in a library or a lab, and you are finding intelligent active hours not to be meeting your needs, you may want to set active hours to the working hours of that building to ensure the device doesn’t update until it is no longer in use. |
|
GP name: GP setting names: For feature updates: ConfigureDeadlineForFeatureUpdates, ConfigureDeadlineGracePeriodForFeatureUpdates |
This policy allows you to specify the number of days before an update is forced to install on the device during active hours, when the user may be present. |
This policy is always recommended for commercial or education environments where there is a compliance need or where it is pertinent that devices stay secure.
Note: Security is paramount from our point of view and deadlines are a great way to ensure such. |
Education devices
Education devices are single user or shared devices that are leveraged by students and teachers in a school setting. This encompasses both personal devices and those that may be stored in a computer cart in the classroom for shared use. For this scenario, any form of notification may be extremely disruptive in a classroom setting.
This scenario may require:
- No notifications during the school day.
- No automatic reboots during the school day.
- Devices to stay secure and protected.
Note: While not automatically rebooting during the school day can likely be achieved by the default settings, you may want to consider the following to ensure devices stay protected and to prevent notifications during the school day.
|
Policy |
Description |
When to set it and why |
|
GP name: GP setting name: |
This policy allows you to define what Windows Update notifications users see, including the ability to turn off all notifications, including restart warnings.
“Apply only during active hours” results in notifications only being turned off during active hours. |
The ability to “Apply only during active hours” is new and is currently only available to devices in the Windows Insider Program for Business leveraging the Dev or Beta channels. This policy enables you to turn off Windows update notifications during active hours only. Please try out the experience in the Beta Channel and provide feedback!
For those on Windows 10 or Windows 11, version 21H2 devices, we do not recommend configuring this and instead recommend leveraging the default experience. |
|
GP name: GP setting names: For feature updates: ConfigureDeadlineForFeatureUpdates, ConfigureDeadlineGracePeriodForFeatureUpdates |
This policy allows you to specify the number of days before an update is forced to install on the device during active hours, when the user may be present. |
This policy is always recommended for commercial or education environments where there is a compliance need or where it is pertinent that devices stay secure.
Note: Security is paramount from our point of view and deadlines are a great way to ensure such. |
|
GP name: GP setting name: |
This policy enables you to specify the hours during which a device should not restart.
This overrides the default intelligent active hours, calculated on the device based on user usage. |
We recommend that you simply leverage the default, built-in intelligent active hours that are calculated on the device.
That said, you can leverage this policy if you feel it necessary and if there is a set period of time during which the device is allowed to be used or during which reboots are unacceptable. For example, if this is a device in a library or a lab, and you are finding intelligent active hours not to be meeting your needs, you may want to set active hours to the working hours of that building to ensure the device doesn’t update until it is no longer in use. |
Display options for end user update notifications
Kiosks and billboards
Kiosks are simple user interfaces that can be used without training or documentation to accomplish a specific task or get information. An example would be an automated teller machine (ATM). These devices are often left unattended for long periods of time, meaning that there is no end user there to interact with or trigger a reboot. Similarly, billboards, which convey information, are often meant to display or get interaction from the end user, but do not have an end user who is interacting with the update(s). Nevertheless, these devices need to stay secure and up to date, although without end users walking or driving by seeing “Restart now” notifications across the screen.
This scenario may require:
- No notifications.
- No automatic reboots during certain periods.
- Scheduling the reboot for a specific time during low visibility/usage.
- No end user interaction.
Note: By default, the device will automatically restart outside of active hours, after installation is complete. However, to ensure there are no notification disruptions, we recommend the following be configured.
|
Policy |
Description |
When to set it and why |
|
GP name: GP setting name: |
This policy allows you to define what Windows Update notifications users see. This includes the ability to turn off all notifications, including restart warnings. |
This policy is recommended for devices that do not have active end users, where notifications can be disruptive and serve no purpose (such as kiosks and billboards). |
|
GP name: GP setting name: |
This policy enables you to manage automatic update behavior.
Schedule install time (3) restricts the device to installing at that specified time until deadline is reached. |
If the policy is not configured, the device will follow the default behavior (Auto install and restart). If no day and time are specified, the default is 3 AM daily.
This policy is available for use when there is a specific period when there is either low usage or visibility of the kiosk or billboard. That said, you can achieve a similar result through configuring Active Hours (see next line). |
|
GP name: GP setting name: |
This policy enables you to specify the hours during which a device should not restart.
This overrides the default intelligent active hours, calculated on the device based on usage. |
You can configure active hours to the window when the device is most likely in use or visible. This will ensure that reboots occur outside of that window when it is likely to cause less disruption. |
|
GP name: GP setting names: For feature updates: ConfigureDeadlineForFeatureUpdates, ConfigureDeadlineGracePeriodForFeatureUpdates |
This policy allows you to specify the number of days before an update is forced to install on the device during active hours, when the user may be present. |
This policy is always recommended for commercial or education environments where there is a compliance need or where it is pertinent that devices stay secure.
Note: Security is paramount from our point of view and deadlines are a great way to ensure such. |
Factory machines, rollercoasters, and similar things
There are some devices that we often don't even think of as needing to update, unless we are the ones managing them. Machines on the factory floor, rollercoasters at amusement parks, and other critical infrastructure can all require updates. Given the criticality of these devices, it is pivotal that they stay secure, stay functional, and are not interrupted in the middle of a task. Often these are some of the devices in the final wave when rolling out an update after everything else has been validated.
This scenario may require:
- End user initiating an update or updating at a specific time.
- No automatic reboots – ever.
Note: This is one of the only use cases where compliance deadlines are not recommended given automatic updates are never acceptable in this scenario.
|
Policy |
Description |
When to set it and why |
|
GP name: GP setting names: Notify to download / Notify to Install AllowAutoUpdate = 0 |
This policy enables you to manage automatic update behavior.
Schedule install time (3) restricts the device to installing at that specified time until the deadline is reached.
Notify to download (0) will require the end user to take action (via notifications or the settings page) to download the update. |
The schedule install policy is recommended for use when there is a specific period when the device is not in use.
Notify to download or Notify to install is only recommended in scenarios where any unexpected updates not triggered by an end user have negative consequences.
Note: If full control is needed, you can also disable automatic updates by disabling this policy the end user will have to manually kick off scans, downloads, installs, and restarts. This is only recommended in specific cases which require high touch management of updates. This puts the device at high risk of becoming insecure and missing updates. |
Microsoft Teams Rooms devices
Microsoft Teams Rooms are actively managed by Microsoft “out-of-box". This enables you to have a hands-off approach where no policies are needed for Microsoft Teams Rooms to successfully stay up to date with validated updates. By default, only updates that Microsoft has validated will be offered to the device and will be automatically installed. We recommend against configuring any policies on a Microsoft Teams Rooms device, especially any offering policies, as they are likely to conflict with what the Microsoft Teams Rooms management has already put in place. These conflicts can lead to a degradation of experience. Learn more about Microsoft Teams Rooms update management.
Conclusion
The above are just some of the common use cases we hear about from organizations like yours. For those of you interested in Windows update management recommendations for servers, stay tuned! And don't forget to leverage the defaults!
We are always learning and trying to improve. To that end, please let us know if there are gaps in the capabilities that we are providing. Additionally, if you have questions or see a use case missing that you want guidance on, please just drop a comment below, message me at @ariaupdated on Twitter, or ask us questions during the next Windows Office Hours!
Continue the conversation. Find best practices. Visit the Windows Tech Community.
Stay informed. For the latest updates on new releases, tools, and resources, stay tuned to this blog and follow us @MSWindowsITPro on Twitter.
Microsoft
