Sites question

[Alex Anderson]

Hello everyone,

I have created the new site under AD sites and services and associated
the subnet to that site. I then dcpromo'd the windows 2000 server at the
new site to be added to the existing domain. It placed the server in it's
proper site however I'm not sure what to do next. I am getting these event
IDs on the main DC of my org: 1265,1307,1566,1311.
I need some hand holding on this, because I've read those event ID's on
Technet but I have no idea what they are talking about.

Thanks a bunch.

Alex Anderson

 

[ptwilliams]

Can you give the event source as well as the error; this will help us assist
you?

KCC 1311 means that either there are no connection objects or the ones that
are there aren't working.

How are the two sites connected? Is there a firewall or switch with an ACL
on it in between the two sites? Where is the second DC pointing for DNS?


Paul.
__________________________

 

[Alex Anderson]

Williams,

The two sites are connected by a VPN (T1) and the second DC is pointing
to the same DNS server as my primary DC. I have DNS set up as a secondary
setup on that DC. Here are the errors I'm receiving:

Event ID 1566:
All servers in site
CN=Police,CN=Sites,CN=Configuration,DC=CityHall,DC=Murrieta,DC=org that can
replicate partition CN=Configuration,DC=CityHall,DC=Murrieta,DC=org over
transport CN=IP,CN=Inter-Site
Transports,CN=Sites,CN=Configuration,DC=CityHall,DC=Murrieta,DC=org are
currently unavailable.

Event ID 1265:

The attempt to establish a replication link with parameters


Partition: CN=Configuration,DC=CityHall,DC=Murrieta,DC=org

Source DSA DN: CN=NTDS
Settings,CN=COMPDDC,CN=Servers,CN=Police,CN=Sites,CN=Configuration,DC=CityHa
ll,DC=Murrieta,DC=org

Source DSA Address:
dc3ad667-8e6b-4971-a2a9-fdf5cbe292e5._msdcs.CityHall.Murrieta.org

Inter-site Transport (if any): CN=IP,CN=Inter-Site
Transports,CN=Sites,CN=Configuration,DC=CityHall,DC=Murrieta,DC=org


failed with the following status:


The DSA operation is unable to proceed because of a DNS lookup failure.


The record data is the status code. This operation will be retried.

Thank you for your help on this,

Alex Anderson

 

[ptwilliams]

OK, a couple of things to try:

ipconfig /flushdns
ipconfig /registerdns
net stop netlogon
net start netlogon

Force replication. I'd install the support tools and have a look at what's
going on with Replication Monitor (you can use this to force replication).

Wait a couple of mins, and refresh replmon.

If that doesn't work try this (you may also want to run the following even
if the above does work) and see if there's any issues there:

netdiag /test:dns
dcdiag /v /c /e

Also, this isn't strictly necessary but because this is a DC at another
site, ensure the DC is a GC.


Paul.
_____________________________

 

[Alex Anderson]

Paul,

I tried running the command you indicated, but I wasn't sure which
server to run them on so I choose all my DC including my new site DC. I
think I'm missing something in AD sites and services, because I didn't
create any site links after I dcpromo'd the DC at the new site into the
existing domain. It looks like it put the new DC in the right subnet but
under Inter-Site Transports, the DEFAULTIPSITELINK is the only link listed
in there. If I do properties I can see that my Police site is listed under
Sites in this site link along with CityHall. Are you sure I don't need to
create a new site link for Police? Here's the log I obtain by running
dcdiag /v /c /e:

Testing server: Police\COMPDDC
Skipping all tests, because server COMPDDC is
not responding to directory service requests

Running enterprise tests on : CityHall.Murrieta.org
Starting test: Intersite
Doing intersite inbound replication test on site CityHall:
Locating & Contacting Intersite Topology Generator (ISTG) ...
The ISTG for site CityHall is: COMMAIN.
Checking for down bridgeheads ...
*Warning: Remote bridgehead Police\COMPDDC is not eligible as a
bridgehead due to too many failures. Replication may be
disrupted into the local site CityHall.
Remote bridgehead Police\COMPDDC also couldn't be contacted by
dcdiag. Check this server.
Bridghead CityHall\COMMAIN is up and replicating fine.
Doing in depth site analysis ...
Remote site Police is replicating to the local site CityHall the
writeable NC Schema correctly.
Remote site Police is replicating to the local site CityHall the
writeable NC Configuration correctly.
Remote site Police is replicating to the local site CityHall the
writeable NC CityHall correctly.
Doing intersite inbound replication test on site Police:
Locating & Contacting Intersite Topology Generator (ISTG) ...
***ERROR: There is an inconsistency in the DS, suggest you run
dcdiag in a few moments, perhaps on a different DC.
......................... CityHall.Murrieta.org failed test Intersite

 

[Alex Anderson]

Paul,

Another thing, when I dcpromo'd the new site server to become a DC it
was a member server prior of dcpromo. From the documentation from
Microsoft, it recommends it being just part of a workgroup. Could that be
part of my problem?

Thank you
Alex Anderson

 

[ptwilliams]

No, I can't see this being a problem...it certainly hasn't been one for me.


Paul.
___________________________

 

[Alex Anderson]

Paul,

Okay, I wasn't sure. Am I suppose to create the link or is the
DEFAULTIPSITELINK good enough? Prior of adding the new site, I did not have
any subnets defined. Since I added a subnet for my new site, should I
define my existing site with a subnet and other subnets that attach to this
domain but are not necessarily sites?

Thank you
Alex Anderson

 

[ptwilliams]

It's fine to leave it in the default site link. The ISTG will create
connection objects based on site links and DCs in site links.

However, your test results are...bad.

It looks like either the machines cannot physically talk or bad DNS. When
you performed the aforementioned commands, was the troublesome (remote) DC
pointing to the primary DNS server? If not, point it at the PDNS. If it
was, can you ensure that there is physical connectivity, and that there
isn't a firewall or advanced switch blocking certain ports.

90% of AD problems stem from DNS problems. Also run netdiag /test:dns on
the faulty, and a working DC. The /registerdns, etc. should be run on the
troublesome DC; netdiag needs to be run on the faulty DC and a working one.
Then you can trawl through the errors and compare the differences ;-)


Paul.
_______________________

 

[Alex Anderson]

Paul,

I have the DC at the new site pointing to itself, because I have DNS set
up on that server as a secondary zone. Should I not be doing that? At the
new site am I creating a new PDNS? I'm under the assumption I'm not.

Thank you
Alex Anderson

 

[Alex Anderson]

Paul,

Okay, I think I know what the problem is after reading what you have
told me. There are discrepancies with the DNS server on the new DC at the
new site. I guess it's a bad idea to dcpromo a DC when it's primary DNS is
itself. I pointed the DC to the primary DNS server at the existing site and
forced replication. I guess it's doing it's thing not sure if it's
correcting itself. Once that is done, is it wise to which the primary DNS
back to itself or leave the DNS pointing the PDNS?

Thank you
Alex Anderson

 

[Guest]

You got it! When you do the dcpromo you want to be pointing at another DNS server (when in AD Integrated) and at the Primary DNS server when not in AD Integrated mode. Once the promotion has been successful, you can then switch to any DNS server you want. Personally, I *always* use AD Integrated zones. With AD Integrated they're all primary zones, and as soon as you install DNS on a DC (well after replication) it gets a copy of the DNS

If your DNS server is a secondary and you point to that, the DC cannot write its SRV records (the records that enable machines to find it's DC bits) to the zone file

So, to summarise, now that you've pointed to the PDNS and allowed for replication you can switch back to pointing to yourself for DNS. I will add here, that were I in your position I would reconfigure the remote DC to point to itself and upgrade the zones to AD integrated (do this on the PDNS server first)

Hope this helps,

 

[Guest]

Alex

You do need to define your subnets and associate them with a site. Also, the DEFAULTSITELINK is fine -you don't need to create a new one. However, if you're going to have several site links it's probably best to rename it to something a little more descriptive

As an example of sites and subnets, think of this

For the following network boundaries
Main site - 172.16.1.0/2
Remote 1 - 172.16.2.0/2
Remote 2 - 172.16.3.0/2

You define three subnets and name them appropriately, i.e. HQ, London and L

You then associate each subnet with the appropriate site (pull up the subnet properties and choose the appropriate site)

If your DC falls into one of these subnets, it will be moved to the appropriate site; alternatively, you can right-click on a server and move it to the appropriate site. The clients will assign themselves to sites based on the subnet allocation

Here's another reason for using AD Integrated DNS zones: when clients in London need to register in (Dynamic) DNS, and the PDNS server is in LA -that's some nasty, unneeded WAN traffic. By using AD Integrated zones, the clients will update their DNS records on the local (through site allocation) server which will replicate that info. to the other DNS servers at the next predetermined replication interval

Sites localise network traffic - DNS registrations, authentication requests, GPO processing, etc

Ensure that at least one DC in any given site is a GC. If you've only one domain, make all DCs GCs

Hope this helps

Paul
____________________________________

----- Alex Anderson wrote: ----

Paul

Okay, I wasn't sure. Am I suppose to create the link or is th
DEFAULTIPSITELINK good enough? Prior of adding the new site, I did not hav
any subnets defined. Since I added a subnet for my new site, should
define my existing site with a subnet and other subnets that attach to thi
domain but are not necessarily sites

Thank yo
Alex Anderso