- Send emails in Exchange Online using an alias address: Configuration with PowerShell and admin center - Tue, Jun 29 2021
- Deactivate update notifications on Windows Server - Wed, Jun 3 2020
- Remove unneeded settings from Group Policy Objects - Thu, Apr 23 2020
Depending on the configuration, even standard users can install updates and thus prompt the server to restart. This is especially true for RD Session Hosts, where an unplanned reboot may affect several users with data loss.
Update notification on Windows Server 2019
The notifications are intrusive and cannot be closed by clicking on the X in the upper right corner. Therefore, the remaining options are to hit the ESC key or to click on the corresponding button to view the updates. This will open the Windows Update section in the Settings app. If the current user is authorized to initiate the installation of the updates, then this process will take its usual course and will usually result in a restart.
Clicking the notification leads to the Settings app, where users can start the update installation
To prevent this, there is a Group Policy setting under Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update > Allow non-administrators to receive update notifications. However, it only applies up to Windows 8.1 and Server 2012 R2. The following sections explain what to do with higher versions.
The GPO setting to hide the update notification doesn't affect newer versions of Windows Server
Turning off notifications with the task scheduler ^
Notifications of available updates are triggered by scheduled tasks. If you disable or delete these tasks, you will also get rid of the notifications.
Scheduled tasks that are responsible for displaying the update notification
You can find them in the task scheduler under Microsoft > Windows > UpdateOrchestrator. These are:
- MusUx_UpdateInterval
- USO_UxBroker_Display
- USO_UxBroker_ReadyToReboot
Disable notifications using a batch script ^
Instead of scheduling the tasks interactively, you can deactivate them with a batch file. To do this, execute the following commands in an administrative command prompt:
schtasks /End /TN "\Microsoft\Windows\UpdateOrchestrator\MusUx_UpdateInterval" schtasks /End /TN "\Microsoft\Windows\UpdateOrchestrator\USO_UxBroker_Display" schtasks /End /TN "\Microsoft\Windows\UpdateOrchestrator\USO_UxBroker_ReadyToReboot" schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\Reboot" /DISABLE schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\USO_UxBroker_Display" /DISABLE schtasks /Change /TN "\Microsoft\Windows\UpdateOrchestrator\USO_UxBroker_ReadyToReboot" /DISABLE
The problem with this solution is that even within the same version of Windows Server, Microsoft uses different names for the tasks. If not all the scheduled tasks are on a system, the above script will display an error message. On the other hand, it ignores tasks with a different name.
Disabling notifications via PowerShell ^
Another approach is to identify the tasks in question regardless of their name. Their common feature seems to be that they execute MusNotification.exe with different parameters. This can be used in PowerShell to delete the tasks.
Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\"|
where {$_.Actions.execute -like "*MusNotification*" -and $_.state -eq "Ready"} |
Unregister-ScheduledTask
Removing scheduled tasks for update notification using PowerShell
If you want to safeguard yourself against this relatively radical measure, you can save the tasks as an administrator in a file beforehand with Export-ScheduledTask:
Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\" |
where { $_.Actions.execute -like "*MusNotification*" -and $_.state -eq "Ready"} |
foreach {Export-ScheduledTask -TaskPath $_.TaskPath -TaskName $_.TaskName > `
($_.TaskName + ".xml")}If necessary, the tasks could then be restored using Register-ScheduledTask and the parameter XML.
Another alternative would be to delete the scheduled tasks via Group Policy Preferences. However, this requires that you know the exact names of the tasks.
Conclusion ^
Basically, you should make use of the possibilities offered by Group Policies to implement your own concept of update distribution and the timing of the restart. This can be a classic regular maintenance window, which the administrator supervises.
Subscribe to 4sysops newsletter!
The server can also update itself and restart outside office hours. However, this is not recommended for critical systems. Microsoft offers further information in this article.
