Windows successfully installed the following update: Look at registry settings and the GUI interface before and after the upgrade of the server. What differences are there? Before and after screen shots were taken and can be seen in U: On all clients except , the updates icon that appears in the system tray has changed from a globe to a golden shield.
When clicking on the icon, all clients show the new interface that lets you choose Express or Custom install. There are new entries: I will have to investigate the new options and see how they work.
Uninstalled for , which does not require a restart for either uninstall or reinstall. The bad news is, it appears the registry no longer reflects what is going on regarding the state of updating AUState values no longer shown, and LastWaitTimeout no longer used. DetectionStartTime was set to a value of 5 days ago when I started the test, and never changed throughout the test - I'm not sure what this value is supposed to represent.
NextDetectionTime did change during the test, to show the NEXT time that updates would be automatically detected it never reflects the current detection. Also, the value DownloadExpirationTime briefly appears while the detection is occuring, but disappears quickly. The good news is, detection did happen immediately when running this command. Our faadmin account has been denied access, while fa-updater is allowed access. Fa-updater can successfully run the command, and new updates appear within 30 seconds.
When faadmin runs the command though, and then fa-updater logs in, the updates notifications do not appear. If this policy is Not Configured or Disabled, then when selecting Shut Down from the Start menu, if there are updates waiting to be installed, the user will see an option "Install Updates and Shut Down", in addition to the normal options of Log Off, Restart, and Shut Down.
This option appears even for users who have been denied access to updates features such as our faadmin account. This feature could be useful for users who turn their computers off overnight, and are bothered by an immediate reboot after turning on their computers the next morning. This would give them the option to install as they are shutting down, instead. If this policy is Enabled, the new option simply doesn't appear in the list of shut down options. This option does not work on clients, they will never see the "Install Updates and Shut Down" option.
This option works in conjunction with the previous option. It only has an effect if the previous option is not Enabled. Whatever option was previously used most recently will be the default option in the Shut Down dialog box.
Although this is more normal behavior for the Shut Down box, a user might not notice that "Install Updates and Shut Down" is an available option, unless it is the default option. Configure Automatic Updates new option within this dialog box - 5-Allow local admin to choose setting. This option works on all clients. A local administrator account is given the option of whether they want autodownload with scheduled install, autodownload with notify for install, or notify for download and notify for install.
This option does NOT override the option to deny access to update features. For example, it worked as described for the fa-updater account.
However, our faadmin account, which is a local admin account that has been denied access to updates features, still had the GUI control panel all grayed out. It was set to autodownload and notify for install - I'm not sure if that's the default choice it picks if access is disabled, or if it simply shows the last choice that was made by an administrator.
TargetGroup, which contains the name I entered, and TargetGroupEnabled, which is set to a value of 1. When connecting to the SUS console, the home page shows that nonexistent groups have been requested, and the names of the groups.
When I go to the computers page and click on the affected client, it shows that it has requested a nonexistent group, and that it still belongs to the group "Unassigned Computers". However, I do not see a way to search for a list of computers that have been assigned to nonexistent groups. On next contact with the server, the computer ended up in its proper group. I then changed the group to a different one. I will do more testing of groups later on, for now I was just checking on the basic functioning of the policy.
Automatic Updates detection frequency. Clients are set to check for new updates every 22 hours by default. This can be set to anywhere from 1 hour to 22 hours.
I recommend choosing a value between hours to ensure the clients will check at least twice during a business day. With the higher frequency of checks, we can ensure a hour turnaround of updates installs on all clients.
Allow Automatic Updates immediate installation. Theoretically, this option will allow updates to install silently in the background upon detection if they will not disrupt services or cause the machine to reboot. However, I believe that Microsoft has to give the update a special marker indicating that it is available for immediate install, and I don't believe they have released any such updates to date. I believe this option won't work until we see an update come in that shows something like "Does not require restart".
There is no way to test this option until such an update is available. No auto-restart for scheduled Automatic Updates installations. This is not a new option, but I wanted to see if the dialog box presented to users was new. With SUS, we have problems with the restart dialog box always remaining in the foreground, with no way for the user to get rid of it except by clicking Yes, and making it difficult for them to shut down other open applications before forcing a restart.
I wanted to see if the WSUS version had some improvements. However, the first update that I tried to test with was one that does not require a restart.
It installed silently in the background without alerting the user at all. The event log showed that it installed at the scheduled time. I then repeated the test with an update that I knew would need a reboot. Unfortunately, although some of the wording in the dialog box has changed, the same basic problems as described above still exist. It is only useful if you are using scheduled installations and do NOT enable "No auto-restart for scheduled Automatic Updates installations".
If No auto-restart is enabled, it overrides the Delay restart policy. After the scheduled install occurs, a dialog box pops up for the user, telling them that the machine will restart in x minutes available range is This dialog box has the same problems as described for the last group policy option - it can't be minimized and stays stubbornly in the foreground, making it annoying to access other open applications.
For testing I set it to 7 minutes, and when the box came up it actually said 6: The user does have the option to click "Restart Now". If the user has been denied access to updates features, the "Restart Later" button is greyed out. If the user is a local administrator and has not been denied access, they have the option to click Restart Later. Re-prompt for restart with scheduled installations.
This policy works in conjunction with the previous policy. If you don't like the default option of being reminded to reboot every 10 minutes, you can change it using this policy. You can select to be reminded every minutes. In testing, I discovered that the reminder actually comes up a couple of minutes late.
Allow non-administrators to receive update notifications. This policy works on all clients. It is possible that it does not appear in the group policy editor until the machine you are editing policy from has received the new WSUS client.
This policy does just what it says - if you enable it, people who are not local admins on their PCs will receive the update notifications and be able to interact with the notification dialog boxes as if they are an administrator. If you have set the policy that removes access to update features, that policy overrides this one. Throughout the group policy testing, I also noticed something new - it appears that clients now check for new updates every time they reboot, not just at their scheduled detection time.
Approving updates for removal cannot be tested at this time. All updates at this time have a status of No. We will not be able to test this feature until Microsoft begins releasing updates that are removable.
This is an example of how this new approval option could be used. Once it is approved for detection, you can go to the reports page, look at the reports for individual updates, and see a list of the computers underneath the update, that need the update. However, the computers themselves are not changed in any way. The updates do not install, and there is nothing in the Event Viewer to show that it needs the update. I tested some updates using an installation deadline of yesterday.
This worked the same on all clients. For an update that does not require a reboot, it simply installed immediately and silently in the background, without showing any notifications to the user, and placed entries in the Event Viewer. For an update that does require a reboot, it behaved the same way and then popped up a forced reboot box with a 5-minute warning. There was no way to cancel out of this box, even for an administrator with full access to update features.
I then tried using the "Delay Restart for scheduled installations" group policy option to change the time displayed in the reboot box. It worked, even though I was not using a scheduled installation during the test - I set it to 30 minutes and the user was given that much warning before needing to reboot.
There is a statement in the Microsoft documentation, saying that if there is a conflict between the approval rules between the All Computers group and a created group to which a computer has been assigned, that the rule of "Install" will always override. The rule set in the created group overrides the rule set for the All Computers group, even if the created group says Detect Only and All Computers says Install. Even if uninstalled updates are waiting in the queue, all clients will detect new updates and add them to the list the next time they check in with the WSUS server.
This is a great improvement! The problems that I experienced with superseded updates in SUS appear to be fixed. None of the test clients that I built are repeatedly detecting that they need certain updates.