GPO's Not Replicating

[tbaze]

I'm having a great deal of trouble getting GPs to pull over the domain. I've beaten my head against the wall and just cannot resolve it.

So, currently -

• dcdiag turns up no errors on the pdc.
  ipv6 is turned off.
  domain authentication works perfectly.
  I cannot telnet to port 389 on the DC but I can telnet to 23 (after enabling telnet server). It shows that it is listening on 389 in netstat.
  SYSVOL properties are as they should be.
  DC2 replicates/pulls the GP fine. It's everything outside of those 2 that does not.
  The PDC/DNS server is using its own IP for DNS.
  GPResult reads:
  Group Policy Infrastructure failed due to the error listed below.
  
  The network is not present or not started.
  
  Note: Due to the GP Core failure, none of the other Group Policy components processed their policy. Consequently, status information for the other components is not available.

I've done a number of other things but cannot remember them all off the top of my head.

[tbaze]

GPResult from GPUpdate and Group Modeling Report found here - http://cid-acd77f58b67d0b4a.skydrive...e.aspx/.Public

Two quick things:

1) Windows Firewall turned on?
2) Most people will probably not go to the link that you provided.
Unfortunately, in today's world it is potentially too dangerous to go to a
link that is posted by an 'unknown' person.

What about doing this?

Post an unedited 'ipconfig /all" results
Post an unedited "dcdiag.exe /c /v" results from both Domain Controllers
(dcdiag is part of the Support Tools....you could also do dcdiag /c /e /v,
where the "/e" will do it for all Domain Controllers).
And, my favorite tool - what do you see in the Event Logs? Specifically, in
the Application and in the System?

[tbaze]

Windows Firewall Service is disabled.

IPConfig
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : M1CMS001
Primary Dns Suffix . . . . . . . : testadservs.net
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : testadservs.net

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) 82575EB Gigabit Network Connection
Physical Address. . . . . . . . . : 00-30-48-BC-83-5F
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 172.17.250.51(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.17.250.5
DNS Servers . . . . . . . . . . . : 172.17.250.51
NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{563CB7A9-906E-4C07-B724-0D66853F044B}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

DCDiag:

I was futzing around with FRS today a bit so is likely the cause of a couple of the event log errors.

Directory Server Diagnosis

Performing initial setup:
Trying to find home server...
* Verifying that the local machine M1CMS001, is a Directory Server.
Home Server = M1CMS001
* Connecting to directory service on server M1CMS001.
* Identified AD Forest.
Collecting AD specific global data
* Collecting site info.
Calling ldap_search_init_page(hld,CN=Sites,CN=Configuration,DC=testadservs,DC=net,LDAP_SCOPE_SUBTREE,(object Category=ntDS
SiteSettings),.......
The previous call succeeded
Iterating through the sites
Looking at base site object: CN=NTDS Site Settings,CN=testadservs,CN=Sites,CN=Configuration,DC=testadservs,DC=net
Getting ISTG and options for the site
* Identifying all servers.

Okay....so, you have two Domain Controllers. I ass/u/me that both are
running Windows Server 2008?

Looks like you do not have a multihomed DC...and that you have your internal
DNS Server IP Address in the DNS settings in the TCP/IP Configuration
settings. That is good.

What did you do with the File Replication Service? And, is it fixed again?
Here is a very simple test that I like to employ for basic FRS replication
testing:

On M1CMS001 in the shared sysvol folder create a simple .txt file (called
something like 'M1CMS001-test.txt') and put some text in it like the
following...."created on M1CMS001 on 2009 JAN 02 at 20:44. This should show
up on 'M1CMS002' shortly." Assuming that this completes successfully, do
the same thing on 'M1CMS002' (or whatever the other Domain Controller is
called). Do both .txt files show up on the 'other' Domain Controller?

Have you ever played with FRSDiag or with FRSUtil?

And, is all of the DCDIAG resultant file included? It seems like it kinda
got chopped off?

And - your account: is it a member of DA?

Let's look at a couple of things first......then let's come back to FRS.

So, we have two Domain Controllers - M1CMS001 and M1CMS002. Here come my
first set of questions:

1) Please verify that the File Replication Service is running on both at
this time (one of the errors in the FRSDiag log is that FRS is not running
on 002)

2) Are both Domain Controllers also DNS Servers? My guess is going to be
that 002 is *NOT* a DNS Server. How about Global Catalog Servers?

3) Please perform some very basic tests (I know, I know....this is all
really basic....but I am HUGE on the basics...lots of things are assumed to
be correct....when they are not):
from 001 ping the following - ping M1CMS002, ping M1CMS002.testadservs.net,
ping 172.17.250.52 (or whatever the IP Address of 002 is). What happens?
from 002 ping the following - ping M1CMS001, ping
M1CMS001.testadservs.net, ping 172.17.250.51. What happens?

4) Take a close look at DNS. Are all of the records that should be there
actually there? Run dcdiag /fix. This is a quick little utility (er, the
"/fix" switch) that might help to resolve some issues.

5)Are you familiar with dnscmd? Open up the Support Tools command prompt
and do a "dnscmd /zoneprint testadservs.net > c:\DNS-testadservs-net.txt".
This will make things easier to see. Somewhere near the very top of that
output file you should see the CNAME entry for each and every Domain
Controller (er, assuming that you have a single domain Forest - like most
people do). You should see - except for in the obvious spots - both 001 and
002. Where will you *NOT* see 002? In the "gc" areas - assuming that 002
is not a GC - and in the "pdc" area, assuming that 001 holds the FSMO Role
of PDC Emulator. DNSLint might also be your friend here.

6) Taking a super quick look at the output, I notice that there are two
other Domain Controller (LENAD01 and LENAD02)? Are these the 'real' names
of M1CMS001 and M1CMS002? Or, are there a total of four Domain Controllers
in your environment? Were the above mentioned two Domain Controllers - if
they no longer exist - possibly not properly removed from AD (read: simply
turned off and unplugged....or wiped and loaded.....or, turned off and stuck
in a closet somewhere)?

7) What do you see in the Event Logs - specifically in the Directory
Services and the File Replication Services?

8) And, for the most obvious of obvious - on each Domain Controller....open
up the command prompt and enter "net share". What do you see? What do you
*NOT* see?


Okay. I know that this is all really super basic.....but I like to
establish the basics before moving on to the fun stuff. Where I work I can
not tell you how many times these super simple basic questions point us to
the root cause...or at least eliminate lots of potential issues. I am not
smart enough to assume anything! ;-)

And, please pardon me if you have already done all of this. Again, I really
like to establish the basics before moving on to 'the hard stuff'!

Okay....since this is Windows Server 2008 (R2) - let's add one more thing to
the list of questions:

Please make sure that all Domain Controllers have the "AD Service" running
as well.

One more thing that I did not include - Sites and Services:

Q1) Have you properly configured AD Sites and Services?
Q2) Do you have only one Site and all Doman Controllers are in that Site or
do you have Multiple Sites? I ask because of AD Replication (intra-site
replication and inter-site replication work differently) and there might be
issues if your SYSVOL folder is large (I have seen 100MB and larger SYSVOL
folders...) and your WAN connections are slow....

Anyway, just to add to the questions....

The dcdiag output seems to have become one big text file with no breaks,
making it difficult read. It may be due to how techarena handles a
copy/paste or posts it. We usually recommend posting directly to the
newsgroups (which is where techarena pull/pushes ALL of their posts to and
from) instead of using techarena to avoid the shortcomings associated with
techarena. I suggest to use your OS built-in newsreader, Outlook Express
(XP) or Windows Mail (Vista or 7), servername: news.microsoft.com, newsgroup
name: microsoft.public.windows.server.active_directory. It's free, no
username required, no logging in, you can remain anonymous, etc.

Can you provide a brief history as to the installation of the two DCs,
please?

Was a DC removed, renamed, reinstalled, upgraded, was a previous DC the same
name, demoted or removed and reinstalled wiht the same name, or are you
using imaging software (Ghost, or any others)?

This whole thing could be based on resolution issues based on EventID 13508
showing up. The warning message that states, the Event ID 13508 errors
without trailing 13509, is what I am basing my assumption on. See the
following for more info:
http://eventid.net/display.asp?event...ce=FRS&phase=1

Does this record exist? Check both DCs' zones.
e2902334-be48-4463-a1be-c27934d7ecea._msdcs.testadservs.net

If this record does not exist, create the record (CNAME) providing LENAD02's
IP address, then run "dcdiag /v /fix" then re-run FRSDiag.

If you look in the “Frs-Staging” folder on the failed target machine, do you
see any duplicates or conflicting entries?

Try using portqry to insure that the necessary ports are listening. Telnet
is not the best tool to test DC communications..

Download details: PortQry Command Line Port Scanner Version 2.0Download
PortQryV2.exe, a command-line utility that you can use to help troubleshoot
TCP/IP connectivity issues. Portqry.exe runs on Windows 2000-based ...
http://www.microsoft.com/downloads/d...5-AC828BDC6983

Download details: PortQryUI - User Interface for the PortQry ...Aug 2, 2004
.... Download PortQryUI.exe, an add on User Interface utility for PortQry.
http://www.microsoft.com/downloads/d...displaylang=en

One more question, are both DCs GCs? If not, it is recommended in a single
domain forest, that all DCs are configured to be GCs.

You blew away the whole AD environment and created a whole new AD Forest and
domain? If so, did you disjoin then join the client to the new domain?

Clients locate DCs by DNS, specifically the SRV records. If you see a DC
that doesn't exist in the logs, it may be from DNS. Assuming you kept the
same DNS name, did you delete the old zones and allow dcpromo to create new
ones during promotion?

[tbaze]

Yes, that's precisely what I did. DCPromo'd the secondary, removed - DCPromo'd the primary, removed/deleted domain. I did not perform any manual deletion of DNS zones, etc. I subsequently re-installed Windows Server 2008 (Windows first instance was moved to Windows.old).

I thought maybe there was a caching issue on old servers so I stood up a new VM and tried a GPUpdate there which resulted in a domain name that we've never had, at all. I checked all the SRV records in DNS and saw no mention of either the old domain servers or the new "domain". Going to \\testadservs.net\sysvol works without issue... I'm *this* close to calling Microsoft. :(

On new server:

COMPUTER SETTINGS
------------------
CN=TMPENT2K8,CN=Computers,DC=testadservs,DC=net
Last time Group Policy was applied: 1/3/2010 at 11:16:33 PM
Group Policy was applied from: N/A
Group Policy slow link threshold: 500 kbps
Domain Name: 37L4247D25-07 (no idea where this is from)
Domain Type: WindowsNT 4

Caching issue on the old servers? I assume you mean member servers and not
the DCs? If you are referring to the member servers, that's not likely as
long as you've disjoined the member servers from the old domain, restarted,
then joined them to the new domain and restarted.

You renamed the Windows folder to windows.old then installed the new
instance? I thought you blew away the machine, reformatted from scratch,
which is really what's recommended in such scenarios. My feeling it may have
found the old sysvol installation during promotion, but I can't see why it
would have done that. Either way, whenever installing a new server for a DC,
always blow it away and reformat prior to reinstallation. That's a general
rule of thumb.

As for "37L4247D25-07," that appears to be an OEM generated NetBIOS name.
What NetBIOS name for the domain did you supply dcpromo? Does that name show
up in DNS anywhere? You are not using WINS, otherwise I would have suggested
to look in the WINS database, too.

Is there a hosts or lmhosts file configured?

According to the dcdiag, there's only one DC, M1CMS001. Is that correct?

Please provide an updated ipconfig /all and all Eventlog errors.

Read the following regarding FRS. Honestly if it was reinstalled from
scratch, I can't see why you would be getting any errors at all. It seems we
are missing something basic here.

Recovering missing FRS objects and FRS attributes in Active Directory
http://support.microsoft.com/kb/312862

[tbaze]

I meant member servers and I assumed as much but that doesn't seem to be the case if a brand new server had a OEM NetBIOS name and the old member servers still have old DC names. I suspect it means they're not actually pulling from SYSVOL or wherever they should come from.

That was my intent but Windows installation did not give me that option and I didn't have a great deal of time.

I provided dcpromo with testadservs.net. I am not using WINS.

Nope and nope.

That is correct.

Member server:

Windows IP Configuration

Host Name . . . . . . . . . . . . : M1CMS004
Primary Dns Suffix . . . . . . . : testadservs.net
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : testadservs.net

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
Physical Address. . . . . . . . . : 00-50-56-B7-40-4C
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 172.17.250.54(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.17.250.5
DNS Servers . . . . . . . . . . . : 172.17.250.51
NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{1E843648-B173-48C1-AA85-E78E9D35E425}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e50:24a5:2611:53ee:5c9(Preferred)
Link-local IPv6 Address . . . . . : fe80::24a5:2611:53ee:5c9%13(Preferred)
Default Gateway . . . . . . . . . : ::
NetBIOS over Tcpip. . . . . . . . : Disabled

So it appears to have cleaned itself up. That's good. As for the EventID
1129, it's a transient message, possibly appearing before FRS and everything
getting straightened out.
http://eventid.net/display.asp?event...Policy&phase=1

It may all have come down to patience. :-)

[tbaze]

So it'd have you believe. :(

Still fails, same Eventlog error.

Modeling from the GPMC succeeds, no errors.

GPResults still results in:

Group Policy Infrastructure failed due to the error listed below.

The network is not present or not started.

Note: Due to the GP Core failure, none of the other Group Policy components processed their policy. Consequently, status information for the other components is not available.

Additional information may have been logged. Review the Policy Events tab in the console or the application event log for events between 1/4/2010 5:51:14 PM and 1/4/2010 5:51:17 PM.

Note, it's had this error the entire time.

That's quite unfortunate. Was EventID 1129 the only error in any of the logs
on the DC?

Let's disable IPv6, as well as the RSS TCP Chimney feature. There are known
issues with both. The following should assist you in this task, as well as
explain what it is.

TCP Chimney and RSS Features May Cause Slow File Transfers or Cause
Connectivity Problems
http://msmvps.com/blogs/acefekay/arc...-problems.aspx

Paul Bergson : Disabling IPv6 on Windows 2008Mar 19, 2009 ... I have run
into nothing but trouble with IPv6. Not that there is anything in particular
that is wrong, but not all apps understand and can ...