1

At my company, we have a Windows Server 2003 R2 server which is our primary AD server with just about everything Windows-based running on it (AD, filesharing, print sharing, etc). The Domain functional level is Windows Server 2003, but the Forest functional level is Windows 2000 (the domain used to be primarily hosted on a Windows 2000 Server machine).

A couple of weeks ago, a co-worker and I removed the Windows 2000 Server from the domain, moving all FSMO roles to the Windows Server 2003 machine, making it the primary and only domain controller. Unfortunately, we forgot to move a couple of things, such as GPOs and login scripts. The majority of the login scripts have been recreated, as well as the GPOs, but we still have a couple of small remaining issues. One of which is this little error we get roughly every 5 minutes:

Windows cannot access the file gpt.ini for GPO CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=OURDOMAIN,DC=com. The file must be present at the location <\OURDOMAIN.com\sysvol\OURDOMAIN.com\Policies{6AC1786C-016F-11D2-945F-00C04fB984F9}\gpt.ini>. (The system cannot find the path specified. ). Group Policy processing aborted.

Shortly after receiving this error, we receive the following error:

Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.

Now, things that I've recreated such as Folder Redirection are currently working just fine, so as far as I can tell, the GPOs that exist are being found by the client workstations, and are being applied, so we're good on that part. However, I would like to get these errors to go away because it's rather annoying. (I receive copies of all errors in my inbox every morning).

I have attempted to run dcgpofix, however this only gives me the following error message:

Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp.

U:>dcgpofix

Microsoft(R) Windows(R) Operating System Default Group Policy Restore Utility v5 .1

Copyright (C) Microsoft Corporation. 1981-2003

Description: Recreates the Default Group Policy Objects (GPOs) for a domain

Syntax: DcGPOFix [/ignoreschema] [/Target: Domain | DC | BOTH]

This utility can restore either or both the Default Domain Policy or the Default Domain Controllers Policy to the state that exists immediately after a clean install. You must be a domain administrator to perform this operation.

WARNING: YOU WILL LOSE ANY CHANGES YOU HAVE MADE TO THESE GPOs. THIS UTILITY IS INTENDED ONLY FOR DISASTER RECOVERY PURPOSES.

The Active Directory schema version for this domain, and the version supported b y this tool do not match. The GPO can be restored using the /ignoreschema comman d line parameter. However, it is recommended that you try and obtain an updated version of this tool that may have an updated version of the Active Directory sc hema. Restoring a GPO with an incorrect schema may result in unpredictable behav ior. The restore failed. See previous messages for more details

As usual, if there's something important that I've left out and need to tell you in order to help fix this problem, comment and I'll include it.

More information since comments are limited to 600 characters:

I'm totally able to browse to \ourdomain\sysvol and \ourdomain.com\sysvol from both clients and the server. The real problem we're having is that on C:\WINDOWS\SYSVOL\sysvol\ourdomain.com\Policies directory on the primary AD server, there is no {6AC17...} directory in there. Period. It did not replicate at all. I don't think anything replicated to be honest, since we had to completely rebuild the login scripts and the GPOs by hand.

I wasn't the one who retired the old Win2k server, but from watching, the guy that did it ran into a problem and actually had to seize the FSMO roles on the new system. Sysvol had to be manually rebuilt if I recall correctly, and NETLOGON isn't set up exactly the way it should, although it DOES work, as do our current GPOs minus this one that seems to be referenced somewhere yet not exist.

Here's the list of steps I've taken to try to resolve this issue:

  • Searched in C:\WINDOWS\SYSVOL\sosvol\ourdomain.com\Policies directory for the files, they do not exist
  • Searched \ourdomain.com\sysvol and \ourdomain\sysvol for the files, which again, do not exist. These two right here tell me that the GPO straight up does not exist anywhere on our system.
  • I have searched the server's entire filesystem for anything matching 6AC1786C and found nothing except an old backup from 6 years ago from the Windows 2000 Server.
  • I have attempted to run dcgpofix, only to have it fail citing the fact that the schema type of the domain does not match the schema type for the tool.
  • I have ran dfsutil /PurgeMupCache which effectively did nothing.
Improve this question

3 Answers 3

Reset to default
1

When you talk about "moving" logon scripts and GPO's, that makes me think that you didn't let the SYSVOL replicate properly. The file-based portions of Group Policy would have replicated automatically into the new server computer's SYSVOL. You may have made a serious mess of things, depending on what did or did not replicate and what steps you took, exactly.

That having been said, I highly doubt the "Default Domain Policy" is "corrupt" or missing if you're not getting errors on all your client computers. (Errors on clients would occur much less frequently than every 5 minutes. They would be one every 90 minutes.)

It looks to me like you're having a name resolution, DFS, or file and print sharing protocol problem on the server computer itself.

Some questions:

  • What does the output of DCDIAG on the server computer look like?
  • Is the server using itself (and only itself) as its DNS server?
  • Can you browse to the GPO's path (in the error message) from Windows Explorer on the server computer?
Improve this answer
2
  • DCDiag passes all test. Yes, the server is using itself as the only DNS server. No, the GPO path is not browsable.
    – phuzion
    Jul 9, 2009 at 14:35
  • 1
    Okay-- so you can't browse that path from the server. Just to double-check can you browse the path alright from clients? (You should be able to.) It sounds like your DFS client on the server isn't properly getting a referral to the SYSVOL. (W/o trying to sound critical, I'd love to know what happened during your promotion / role transfer / demotion / retirement. There's nothing you have to do "by hand" for the SYSVOL and Group Policy to replicate. It "just works".) Let me know on the client browsing, and I'll do a little digging re: the DFS client on the server computer acting crazy.
    – Evan Anderson
    Jul 9, 2009 at 14:43
1

I had a similar problem, and searching my notes I fixed it using "dfsutil /PurgeMupCache". I think dfsutil is from the support tools on the 2k3 install CD. This must have come from a Knowledge Base article, but my notes don't say which. Worth a Google though.

JR

Improve this answer
1
  • Tried it, still happening. :(
    – phuzion
    Jul 9, 2009 at 16:24
1

Apparently my co-worker fixed the problem by rebuilding the GPO and removing traces to the old one. I don't know exactly how he did it, but if I can find more information on it, I'll update this post with what I find out.

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .