Group Policy processing aborted.

From: Shawn <Shawn@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 Dec 2006 10:15:00 -0800

Hello,

Im not sure if this a problem or not. I've done some research, and have been
able to reduce the frequency of this error, but it still happens about every
10 minutes now. (Used to be every 5.) This is what I get from the log on a
failure:

USERENV(360.17c4) 13:07:28:437 ProcessGPOs:
USERENV(360.17c4) 13:07:28:437 ProcessGPOs:
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: Starting computer Group Policy
(Background) processing...
USERENV(360.17c4) 13:07:28:437 ProcessGPOs:
USERENV(360.17c4) 13:07:28:437 ProcessGPOs:
USERENV(360.17c4) 13:07:28:437 EnterCriticalPolicySectionEx: Entering with
timeout 600000 and flags 0x0
USERENV(360.17c4) 13:07:28:437 EnterCriticalPolicySectionEx: Machine
critical section has been claimed. Handle = 0xa28
USERENV(360.17c4) 13:07:28:437 EnterCriticalPolicySectionEx: Leaving
successfully.
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: Machine role is 3.
USERENV(360.17c4) 13:07:28:437 PingComputer: PingBufferSize set as 2048
USERENV(360.17c4) 13:07:28:437 PingComputer: Adapter speed 10000000 bps
USERENV(360.17c4) 13:07:28:437 PingComputer: First time: 85
USERENV(360.17c4) 13:07:28:437 PingComputer: Second time: 85
USERENV(360.17c4) 13:07:28:437 PingComputer: First and second times match.
USERENV(360.17c4) 13:07:28:437 PingComputer: First time: 85
USERENV(360.17c4) 13:07:28:437 PingComputer: Second time: 85
USERENV(360.17c4) 13:07:28:437 PingComputer: First and second times match.
USERENV(360.17c4) 13:07:28:437 PingComputer: First time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: Second time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: First and second times match.
USERENV(360.17c4) 13:07:28:437 PingComputer: No data available
USERENV(360.17c4) 13:07:28:437 PingComputer: PingBufferSize set as 2048
USERENV(360.17c4) 13:07:28:437 PingComputer: Adapter speed 10000000 bps
USERENV(360.17c4) 13:07:28:437 PingComputer: First time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: Second time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: First and second times match.
USERENV(360.17c4) 13:07:28:437 PingComputer: First time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: Second time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: First and second times match.
USERENV(360.17c4) 13:07:28:437 PingComputer: First time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: Second time: -84
USERENV(360.17c4) 13:07:28:437 PingComputer: First and second times match.
USERENV(360.17c4) 13:07:28:437 PingComputer: No data available
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: DSGetDCName failed with 59.
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: No WMI logging done in this
policy cycle.
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: Processing failed with error 59.
USERENV(360.17c4) 13:07:28:437 LeaveCriticalPolicySection: Critical section
0xa28 has been released.
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: Computer Group Policy has been
applied.
USERENV(360.17c4) 13:07:28:437 ProcessGPOs: Leaving with 0.
USERENV(360.17c4) 13:07:28:437 EnterCriticalPolicySectionEx: Entering with
timeout 600000 and flags 0x0
USERENV(360.17c4) 13:07:28:437 EnterCriticalPolicySectionEx: Machine
critical section has been claimed. Handle = 0xa28
USERENV(360.17c4) 13:07:28:437 EnterCriticalPolicySectionEx: Leaving
successfully.
USERENV(360.17c4) 13:07:28:453 LeaveCriticalPolicySection: Critical section
0xa28 has been released.
USERENV(360.17c4) 13:07:28:453 GPOThread: Next refresh will happen in 5
minutes

Is this an actual problem? Everything seems to be working, this has been
going on since we moved to 2003 and no compaints. I should note that it does
not always fail, it is about every other GP update now.

--
Shawn
Helpdesk Support
.

Follow-Ups:
- RE: Group Policy processing aborted.
  - From: "Inn Jin [MSFT]"

Prev by Date: Outlook Return E-Mail Address
Next by Date: 3Com firewall with DMZ
Previous by thread: Outlook Return E-Mail Address
Next by thread: RE: Group Policy processing aborted.
Index(es):
- Date
- Thread

Relevant Pages

VIA SATA Raid needs a long time to recover from suspend
... Then if there was an IO request made immediately after resuming, ... Changing the timeout resolved this. ... finally did clear) it would timeout and fail. ... It seemed the kernel ...
(Linux-Kernel)
Re: Repost: Bug with select?
... On Jul 25, Marco Roeland wrote: ... > A select with no timeout, ... > with errno set to EAGAIN, meaning you should try again, which is the ... int flags, fd, len; fd_set writefds; ...
(Linux-Kernel)
Re: Hibernation Redesign
... this is, suspend is pretty fast, but could possibly be even faster. ... Freezing of tasks normally takes next to no time. ... The 20s timeout is again a sign of brokenness. ... We know that it can fail, so we use the timeout to detect failures. ...
(Linux-Kernel)
Re: Hibernation Redesign
... Freezing of tasks normally takes next to no time. ... The 20s timeout is again a sign of brokenness. ... If we expect something to fail, it should fail immediately, without ...
(Linux-Kernel)
Re: Hibernation Redesign
... this is, suspend is pretty fast, but could possibly be even faster. ... Freezing of tasks normally takes next to no time. ... The 20s timeout is again a sign of brokenness. ... We know that it can fail, so we use the timeout to detect failures. ...
(Linux-Kernel)