Group Policy Not Applied to DC's

[az...@pdclab.com]

Hello everyone,

I have some major Group Policy issues, but have not had any luck
resolving them. On 3 of my DC's I get the following messages logged in
the Application Log every 5 minutes.

Event ID 1058
Source Userenv
Type Error
User NT AUTHORITY\SYSTEM

Windows cannot access the file gpt.ini for GPO
CN={...HEX...},CN=Policies,CN=System,DC=DOMAIN,DC=lcl. The file must be
present at the location
<\\DOMAIN.lcl\sysvol\DOMAIN.lcl\Policies\{...HEX...}\gpt.ini>.
(Configuration information could not be read from the domain
controller, either because the machine is unavailable, or access has
been denied.). Group Policy processing aborted.

Event ID 1030
Source Userenv
Type Error
User NT AUTHORITY\SYSTEM

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.

This is happening on 3 of my 4 DC's. I got these messages on the other
DC before it started on the other 3, but it stopped about 2 weeks ago.
I have verified that the file gpt.ini is in the place it is supposed to
be. I am not getting any such messages on my Exchange Server, but it
does not seem to be getting Group Policy applied either. As far as I
know, all clients are getting group policy. On 14-April-2006 one of
our DC's died, and had to be replaced. I had to sieze the FSMO roles
from the dead DC. These events first appear in the event log on
14-April-2006.

All Servers mentioned above are Server 2003 with the latest
SP/hotfixes. The Exchange server is 2003 SP2.

Any help would be greatly appreciated - I am in desperate need of it!

Thanks
Andy

[Roger Abell [MVP]]

Begin by running netdiag and also dcdiag while logged into each DC
in order to get the assessment of domain health/connectivity as seen
by each DC

<az...@pdclab.com> wrote in message
news:1147293728.6...@j73g2000cwa.googlegroups.com...

[B_N_R]

Roger,

Thanks for your response.

DC1 (main office, the one that seems to be ok)
NETDIAG:
NetBT name test: Passed [WARNING] At least one of the <00> 'Workstation
Service' <03> 'Messenger Service', <20> 'WINS' names is missing
LDAP test: Passed, but [FATAL] Cannot do un-authenticated ldap_search
to 'REMOTEDC1': Unavailable. [Warning] Failed to query SPN registration
on DC 'REMOTEDC1'
Everything else passed or skipped
DCDIAG: All passed except systemlog test. An error event occurred
0xC0002719 (this was in there twice)

REMOTEDC1
NETDIAG:
NetBT name test: Passed, but [WARNING] At least one of the <00>
'Workstation Service' <03> 'Messenger Service', <20> 'WINS' names is
missing
[Warning] Failed to query SPN registration on DC 'REMOTEDC2' (These
sites are not able to access each other, so it is expected)
DCDIAG:
Test: Advertising [WARNING] 'REMOTEDC1' is not advertising as a time
server.
Test: frsevent There are warning or error events within the last 24
hours after the SYSVOL has been shared. Failing SYSVOL replication
problems may cause Group Policy problems.
Test:systemlog Event Error occurred 0xC0001B61, 0xC0001B58

REMOTEDC2
NETDIAG:
NetBT name test: Passed, but [WARNING] At least one of the <00>
'Workstation Service' <03> 'Messenger Service', <20> 'WINS' names is
missing
[Warning] Failed to query SPN registration on DC 'REMOTEDC1'
DCDIAG:
Test: Advertising [WARNING] REMOTEDC2 is not advertising as a time
server.
Test: KnowsOfRoleHolders [REMOTEDC1] DsBindWithSpnEx<> failed with
error 1722, the RPC server is unavailable. Warning: 'REMOTEDC1' is the
Infrastructure Update Owner, but is not responding to DS RPC Bind.
[REMOTEDC1] LDAP search failed with error 58. The specified server
cannot perform the requested operation. Warning: 'REMOTEDC1' is the
Infrastructure Update Owner but is not responding to LDAP Bind.
Test: kccevent A Warning Event occurred Event ID 0x80000785. The
attempt to establish a replication link for REMOTEDC2 failed test
kccevent.

When the DC died last month, I siezed all roles with DC1(main office)
except Infrastructure master (siezed by REMOTEDC1). Should I set up a
second DC at the main office, and transfer Infrastructure Master to
that DC so all remote sites can access? Any ideas would be greatly
appreciated.

Thanks!
Andy

[B_N_R]

I just re-ran DCDIAG on both DC and REMOTEDC1, and they both passed the
systemlog test. All other results were the same as the first run. Don't
know if that helps.

Andy

[Roger Abell [MVP]]

"B_N_R" <az...@pdclab.com> wrote in message
news:1147368033.1...@j33g2000cwa.googlegroups.com...

>I just re-ran DCDIAG on both DC and REMOTEDC1, and they both passed the
> systemlog test. All other results were the same as the first run. Don't
> know if that helps.
>

Hi Andy - back from a full day . . .

The Wins registration messages in your netdiags are common, and
no big deal for the Wins registrations mentioned.

Are your three (?) sites connected in a V right, and fully connected?
Where you should put the infrastructure FSMO depends on how you
are configured with GCs and whether there are other domains in the
forest for which this is the forestroot domain.
But if not a problem relative to IM FSMO placement requirements
then it should be at main site so that it is accessible to all sites

Can I assume DC1 did report that it is advertising as time server
but that this was removed for posting brevity ?

First you should focus on the RPC error that showed up for remote 2
and especially on the FRS issues reported for remote 1.

So DNS tests came out clean, which seems rules out the most
common cause under such issues. However, are you using AD
integrated DNS _and_ have each site using its own DNS service?
(notice impact of that if replication is not healthy) If so you might
want to temporarily point them all at the main DC1 DNS service
in their Tcp/Ip settings to make sure they are all on the same page.

Is there any network firewall/filtering between the sites?
I am a little confused about what are / where are the other DCs
named STLSERVER and SPFDSERVER

Right now I am trying to grop why you have SPN resolution issues
apparently on all of the DCs.

If you run replmon and add you DCs how many contexts are
showing failed replication? and for how long (I am particularly
after whether any have been failing since _before_ you have the
DC failure/siezing incident.

[B_N_R]

Roger,

We have our main office with a VPN to RemoteSite1 and a VPN to
RemoteSite2. RemoteSite1 and RemoteSite2 cannot communicate with each
other.(The VPN configuration is handled by an outside company - I know
this needs to be addressed). This is the only domain in the forest.

You are correct that DC1 is advertising as a time server.

Using AD integrated DNS, and each site does have a DNS server (all DC's
running AD-DNS). Each site does have a Cisco PIX firewall. STLSERVER
and SPFDSERVER are RemoteDC1 and RemoteDC2, respectivley, I was just
trying to keep their names off the post (must have accidentally left
them in somewhere). Sorry for any confusion.

Using Replmon
MAINDC1 Replicating with REMOTEDC1 and REMOTEDC2 all are successful
MAINDC2 Replicating with REMOTEDC1 and REMOTEDC2 all are successful
REMOTEDC1 Replicating with MAINDC1 and MAINDC2 all are successful
REMOTEDC2 Replicating with MAINDC1 and MAINDC2 all are successful

I'm not sure why each DC only replicates with 2 of the 3 others - maybe
that's natural??

MAINDC2 replaced the DC that died in April. I had demoted it a few days
ago to see if it was causing the problems. Yesterday I renamed it and
Promoted it. Made it the Infrastructure Master to see if having that
role at the main site made any difference (it did not).

My next guess was going to be deleting and recreating the GPO that is
failing. Its the only other idea that I could come up with. Again, I
really appreciate you taking the time to analyze this problem with me.

Andy

[Roger Abell [MVP]]

Thanks for the clarifications.
It is, given the V net architecture good you now have the infrastructure
master at the main site. In a single domain forest it really does not do
much except when upon domain creation/removal or dc promo/demote.

I think you are tracking right, with the GPO recreate to see what is
result. From all you have said/shown, thing are healthy except for
the SPN issues and the RPC (i.e. netbios ports at firewall?) failure.
GPMC use to copy the GPO, or backup and restore as new, might
speed the GPO recreate test.

If the SPN failures continue to show in the diags, take the issue over
to the server.active_directory newsgroup.

Roger

"B_N_R" <az...@pdclab.com> wrote in message

news:1147444444.3...@y43g2000cwc.googlegroups.com...

[B_N_R]

Roger,

I have been out of town for a few days. I have backed up and created a
new GPO (since the failing one was the Default Domain Policy, I could
not delete it - I just linked the new GPO to the domain and removed the
link to the Default Domain Policy). I am no longer getting the messages
on REMOTEDC2. I cannot reboot the other servers until later, but will
update with those too. I will also keep checking DCDIAG, and if I have
further issues with SPN and RPC failure will post in the other group as
you suggested. Thank you again for all your help. I could not have
worked through all this without your guidance!

Andy

[170b4@discussions.microsoft.com philips 170b4]