• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 455
  • Last Modified:

Windows Server are rebooting after patching even with No Auto-restart GP settings enabled

Servers rebooting without user consent

We have a group of servers which are rebooting automatically after being patched. The servers are part of a group policy that has the "No auto-restart for scheduled Automatic Updates installations" set to enabled. They don't restart right away, but instead wait for someone to log into the server. Most of the time the servers begin the reboot right after the credentials are entered, but some analysts claim they also reboot several minutes after logging in.

Any ideas?

The group policy is enforced through active directory. There are no local policies set at all in regards to automatic updates.

We are patching using SMS2003 or Shavlik.
0
bbcac
Asked:
bbcac
  • 8
  • 7
1 Solution
 
jhyieslaCommented:
Have you had your analysts look to see if the parameters in the GPO are actually being applied to the servers?  Make sure that you have someone log in who has had this happen to them.
0
 
LauraEHunterMVPCommented:
This is a frequently misunderstood setting within GPO - "No auto-restart..." does -not- mean "Server will never reboot". It means "Server will not reboot automatically; rather, it will prompt the next interactively-logged-on user to reboot."

From http://support.microsoft.com/kb/328010: "This policy specifies that Automatic Updates will wait for the computer to be restarted by any user who is logged on to complete a scheduled installation. If this policy is not used, the computer restarts automatically."

If your goal is "no restart prompt ever, no way, no how", then you need to disable WSUS on your servers entirely and patch using only your managed SMS/Shavlik methods.
0
 
bbcacAuthor Commented:
There is no prompt. Often upon signing in, the server will reboot without any interaction at all.
There are some analyst (I haven't seen it happen) that claim while working, the server reboots citing "winlogon.exe" has initiated a reboot.

We are not clicking ok on any popups but rather the server simply reboots without notice
0
Granular recovery for Microsoft Exchange

With Veeam Explorer for Microsoft Exchange you can choose the Exchange Servers and restore points you’re interested in, and Veeam Explorer will present the contents of those mailbox stores for browsing, searching and exporting.

 
LauraEHunterMVPCommented:
I would check your other WSUS GPO settings then, ensure that it's configured to notify for install, etc.  If the analyst in question isn't a local admin on the box, there's another setting for "allow non-admins to see notifications" you probably want to double-check as well.
0
 
bbcacAuthor Commented:
The user is using a domain admin account which is setup as a local administrator.

Any ideas?
0
 
LauraEHunterMVPCommented:
If the RSoP on the server in question displays the settings that you expect, make a copy of the user account and try to repro the behavior (since you say you haven't actually seen it and are going by user report.)
0
 
bbcacAuthor Commented:
I have seen it happen where it reboots upon login, I have not seen it happen where it reboots while working on the server
0
 
bbcacAuthor Commented:
The RSOP shows that the "No auto-restart" option as enabled.
Any other ideas?
0
 
LauraEHunterMVPCommented:
Unless you can actually reproduce the behavior being reported, it's impossible to determine whether it's a misconfiguration in your GP or a user issue; at the moment you're attempting to troubleshoot hearsay, which is virtually impossible to do.  The AU reboot window steals focus when it prompts to reboot, so it's entirely possible that the user is being prompted to reboot while working in another window and presses 'Enter' at the wrong time.  A reported time delay could also be accounted for if the 'Reschedule Automatic Update scheduled installations' option is configured.
0
 
bbcacAuthor Commented:
This is something that I have personally seen happen on several occassions. I know that there is no user interaction when it happens. The reboot happens immediately after logging in without notice or input from the user. The login can be 1 day, or 1 week after patching. We can't reproduce the issue because it only happens on some servers
The RSOP is not showing a GP issue, then where could it be?
0
 
LauraEHunterMVPCommented:
> "There are some analyst (I haven't seen it happen)"

Your earlier comment indicated that you had not been able to repro the behavior.  

Without seeing your GP structure, it's difficult to offer additional advice.  Generally speaking, best to start from a clean slate - create a new OU with no GPOs linked to it (and none being inherited), move the servers to that OU and begin troubleshooting from there.
0
 
bbcacAuthor Commented:
Here's some logs that we found in the WindowsUpdate.log

2008-06-23      11:01:12:139      1448      d30      AU      AU setting pending client directive to 'Forced Reboot'

2008-06-23      11:01:27:775      1448      d30      AU      Launched new AU client for directive 'Forced Reboot', session id = 0x1

2008-06-23      11:01:28:652      5972      175c      CltUI      AU client got new directive = 'Forced Reboot', serviceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, return = 0x00000000
0
 
bbcacAuthor Commented:
We have found that the boxes that are not rebooting are part of a different active directory OU. They have no AU settings configured. The boxes that are rebooting are part of the wrong OU that has AU configured.
That being said, it still doesn't explain why these servers are rebooting. None of the RSOP settings indicate a that a reboot will be forced. In fact they indicate that auto reboots will be avoided.
0
 
LauraEHunterMVPCommented:
You're contradicting yourself here - if they have no AU settings configured, that is not the same as indicating that auto-reboots will be avoided.  If the "No auto-restart..." GP setting is not configured, and if AU is set to auto-download and auto-install, then any updates that require a reboot will automatically reboot the servers.

As I indicated before, if you are having difficulties determining which GP settings are being applied to these servers it's best to start with a clean slate and add in settings until you have them configured the way you desire.
0
 
bbcacAuthor Commented:
"We have found that the boxes that are not rebooting are part of a different active directory OU. They have no AU settings configured."
- this comment was suppose to convey that there are two OU's. One which is rebooting and one which is not. The servers that are not rebooting, do not have AU settings configured.

"The boxes that are rebooting are part of the wrong OU that has AU configured."
- this other group, which is rebooting, actually has the AU settings configured
0
 
LauraEHunterMVPCommented:
My previous advice holds - remove any configured AU settings and add them back in one at a time until you've unravelled the Gordian knot.  First rule of troubleshooting: simplify your configuration.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 8
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now