bbcac
asked on
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.
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.
jhyiesla
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.
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.
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.
ASKER
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
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
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.
ASKER
The user is using a domain admin account which is setup as a local administrator.
Any ideas?
Any ideas?
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.)
ASKER
I have seen it happen where it reboots upon login, I have not seen it happen where it reboots while working on the server
ASKER
The RSOP shows that the "No auto-restart" option as enabled.
Any other ideas?
Any other ideas?
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.
ASKER
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?
The RSOP is not showing a GP issue, then where could it be?
> "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.
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.
ASKER
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-B
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-B
ASKER
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.
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.
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.
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.
ASKER
"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
- 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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.