Tracing KCC activities besides using Ad diagnostic's

[Guest]

Dear MS,

We have a child domain consisting of 15 Win2000 DC's in a total of 5 sites.
We have setup manual links in site and services for some of the sites but on
MS advice we like to remove all manual configurations and have kcc create all
connections automatically. (network is fully routed)

Have have remove all manual configurations and let kcc do the job. We notice
that on some of the site (one for example that have 4 dc's) not all DC's
connections are created automatically by kcc. We have checked all dns issues
using net & dc diag and dnslint, check all sysvol shares and enable
diagnostic logging (set it to level 3 and 5).

We are not receiving any dns nor kcc errors in the eventlogs but still the
automatic connections are not created on some of the DC's.

So basically we no other error to troubleshoot and the kcc is not doing the
job properly and we don't like to create manual connections.

Is there a specific documented steps (or kcc tracing tool) that we can
follow to exactly see where the kcc is failing? Is there a place in AD where
some info must be available for kcc to add the automatic links between the
DC's.

We like to fix the issue for the local site first (intra) and then
troubleshoot the remote site links (inter)

Any help will be appreciated.

Waldemar

 

[Herb Martin]

Dear MS,

We have a child domain consisting of 15 Win2000 DC's in a total of 5
sites.
We have setup manual links in site and services for some of the sites but
on
MS advice we like to remove all manual configurations and have kcc create
all
connections automatically. (network is fully routed)

First: Site LINKS are always manual. You must create these,
as well as Subnets to define the sites.

Generally you should NOT be creating CONNECTIONS which
is the KCCs job 99.99% of the time.

Anyone who advised that without specific reasons is suspect.

Have have remove all manual configurations and let kcc do the job. We
notice
that on some of the site (one for example that have 4 dc's) not all DC's
connections are created automatically by kcc. We have checked all dns
issues
using net & dc diag and dnslint, check all sysvol shares and enable
diagnostic logging (set it to level 3 and 5).

Are you saying there are DCs with NO connection objects in
the same site (where other DCs appear)?

Generally each DC should have two (sometimes 3 if the site
has many DCs) inbound and 2 (or 3) outbound to other DCs.

If this doesn't happen the first thing is to check DNS (and other
IP/firewall issues.)

Then look to see if the DCs are really "in the correct site"
based on the Subnet definitions -- and the actual location
in the Sites containers.

After this, try Time Sync checks and recheck DCDiag again
to make sure you have both DNS and replication working.

We are not receiving any dns nor kcc errors in the eventlogs but still the
automatic connections are not created on some of the DC's.

Which? Give IP addresses and subnets for that Site.
State which have connections (in which direction) and
which do not.

So basically we no other error to troubleshoot and the kcc is not doing
the
job properly and we don't like to create manual connections.

You are correct to avoid this and fix the REAL problem.

Is there a specific documented steps (or kcc tracing tool) that we can
follow to exactly see where the kcc is failing? Is there a place in AD
where
some info must be available for kcc to add the automatic links between the
DC's.

Probably the KCC has the "wrong information" due to
either DNS, Sites, Subnet definitions, or one or more
DCs being located in the "wrong Site container."

We like to fix the issue for the local site first (intra) and then
troubleshoot the remote site links (inter)

If the problem is to other between different sites there
should generally be only ONE DC (the BridgeHead server)
making the connections outside the site, and you might
check Schedules on the Site Link if that doesn't happen.

 

[Guest]

Thx for the reply Martin.

We have 4 dc's (RET-DC1, RET-DC2, RET-DC3 & RET-DC4)
Each are in the same building on sepparte floors and each floor consist on
his own vlan. The servers ip are 10.135.11.2, 10.135.12.2, 10.135.13.2,
10.135.14.2 respectively. So we are have for subnets configure in the site
and services 10.135.11.x, 10.135.12.x ect. All systems can ping and see eacth
other. (we also tested the pinging of the GUID and all is ok) The main site
is called Alca and it connects to 2 other sites Alboa and Alni

- I meant server connections not site links. (these are the ones that should
be created automatically by kcc)
- For example RET-DC1 only have automatic connections to DC3, RET-DC3 only
have automatic connections to DC1 & DC2. Each DC should have at least 3
(intra) connectinos right?
- The servers in the other sites that this site is connected to does appear
in the connectins in some of the DC's but not all of them. For example DC1
only have one automicatic connection to one server of the Alboa site (that
site has 3 dc's). DC2 has mostly all the server connections. So basically why
one dc seems to have most of the automatic connections and others in the same
site does not?
- Since we know that DNS is the first issues to check we have perform all
the neccesary steps (in fact we had to because we just finish a Exch5.5 to a
clustered Ex2003 migration) and we resolved all encountered error.
- We also check all site naming and server locations and subnet definition
and still no dice. That is the reason I like to dig deeper into kcc
functioning, so find out exactly what he looks for step by step so see why
some servers get all the automatic connections and some don't.
- Maybe you know of a active directory realtime tracing tool that can show
all realtime changes in the AD once we select the "Check Topology" option.

I appreciate your input Martin. Thx in advance for any additional comments
you might have.

Waldemar

Dear MS,

We have a child domain consisting of 15 Win2000 DC's in a total of 5
sites.
We have setup manual links in site and services for some of the sites but
on
MS advice we like to remove all manual configurations and have kcc create
all
connections automatically. (network is fully routed)

First: Site LINKS are always manual. You must create these,
as well as Subnets to define the sites.

Generally you should NOT be creating CONNECTIONS which
is the KCCs job 99.99% of the time.

Anyone who advised that without specific reasons is suspect.

Have have remove all manual configurations and let kcc do the job. We
notice
that on some of the site (one for example that have 4 dc's) not all DC's
connections are created automatically by kcc. We have checked all dns
issues
using net & dc diag and dnslint, check all sysvol shares and enable
diagnostic logging (set it to level 3 and 5).

Are you saying there are DCs with NO connection objects in
the same site (where other DCs appear)?

Generally each DC should have two (sometimes 3 if the site
has many DCs) inbound and 2 (or 3) outbound to other DCs.

If this doesn't happen the first thing is to check DNS (and other
IP/firewall issues.)

Then look to see if the DCs are really "in the correct site"
based on the Subnet definitions -- and the actual location
in the Sites containers.

After this, try Time Sync checks and recheck DCDiag again
to make sure you have both DNS and replication working.

We are not receiving any dns nor kcc errors in the eventlogs but still the
automatic connections are not created on some of the DC's.

Which? Give IP addresses and subnets for that Site.
State which have connections (in which direction) and
which do not.

So basically we no other error to troubleshoot and the kcc is not doing
the
job properly and we don't like to create manual connections.

You are correct to avoid this and fix the REAL problem.

Is there a specific documented steps (or kcc tracing tool) that we can
follow to exactly see where the kcc is failing? Is there a place in AD
where
some info must be available for kcc to add the automatic links between the
DC's.

Probably the KCC has the "wrong information" due to
either DNS, Sites, Subnet definitions, or one or more
DCs being located in the "wrong Site container."

We like to fix the issue for the local site first (intra) and then
troubleshoot the remote site links (inter)

If the problem is to other between different sites there
should generally be only ONE DC (the BridgeHead server)
making the connections outside the site, and you might
check Schedules on the Site Link if that doesn't happen.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Any help will be appreciated.

Waldemar

 

[Herb Martin]

Thx for the reply Martin.

Call me Herb.

We have 4 dc's (RET-DC1, RET-DC2, RET-DC3 & RET-DC4)
Each are in the same building on sepparte floors and each floor consist on
his own vlan. The servers ip are 10.135.11.2, 10.135.12.2, 10.135.13.2,
10.135.14.2 respectively. So we are have for subnets configure in the site
and services 10.135.11.x, 10.135.12.x ect. All systems can ping and see
eacth
other. (we also tested the pinging of the GUID and all is ok) The main
site
is called Alca and it connects to 2 other sites Alboa and Alni

What is in those other sites if you only have four DCs and
they are in the same building? Although not an absolute rule,
there should generally be a DC in each site.

- I meant server connections not site links. (these are the ones that
should
be created automatically by kcc)

Yes, Connections is a technical term for the actual
pulls from DC to DC.

- For example RET-DC1 only have automatic connections to DC3, RET-DC3 only
have automatic connections to DC1 & DC2. Each DC should have at least 3
(intra) connectinos right?

No, each should have two Connections with 4 servers.
Every DC should be connected to two others in a logical
ring (1-2-3-4-backto1 or some such, as the numbers won't
necessarily match our human expectations of sequencing.)

If they do not then you likely have the site misdefined, some
DC in the wrong site, OR just plain old DNS problems which
accounts for most replication issues (but you do claim that
DCDiag passes with no replication or DNS errrors.)

- The servers in the other sites that this site is connected to does
appear
in the connectins in some of the DC's but not all of them.

That is likely correct behavior. DC in other site should be
connected to ONE of the DCs in this site in almost all cases.

If it is connected to more than one in this site then this implies
EITHER (or both) a Subnet-Site definition error or one or more
DCs in WRONG Site.

For instances if it looks like this: 1-2-OtherSiteDC-3-4-back to 1
this would imply that OtherSiteDC is in the wrong site for one
(or both of) those reasons (bad subnet defs, or just misplaced DC
because of prior bad subnet defs that have been corrected without
moving the DC to proper site, etc.)

Look in Sites and Services and show me you Subnets for EACH
site with Subnet masks. Also, check each DC and tell me which
site each DC shows itself in.

For example DC1
only have one automicatic connection to one server of the Alboa site (that
site has 3 dc's). DC2 has mostly all the server connections. So basically
why
one dc seems to have most of the automatic connections and others in the
same
site does not?

If you mean the connections to the OTHER site then this is as
designed. One DC gets picked as Bridgehead server (at any
one time) and ONLY that DC replicates to and from other sites.

- Since we know that DNS is the first issues to check we have perform all
the neccesary steps (in fact we had to because we just finish a Exch5.5 to
a
clustered Ex2003 migration) and we resolved all encountered error.

This does NOT mean you have it correct however.

Didn't you say that it passes DNS checks in DCDiag though?
(That is usually sufficient.)

- We also check all site naming and server locations and subnet definition
and still no dice. That is the reason I like to dig deeper into kcc
functioning, so find out exactly what he looks for step by step so see why
some servers get all the automatic connections and some don't.

Digging deeper into KCC is unlikely to fix the problem. Rechecking
the DNS, Sites, Subnets, Server to site assignments, firewall issues,
routing etc are likley to find and fix the problem (practically always
in fact.)

- Maybe you know of a active directory realtime tracing tool that can show
all realtime changes in the AD once we select the "Check Topology" option.

I find that tool to be near worthless and do my checks mentally
or with paper or graphics.

Detail your Sites and Services configuration if you need
more help.

I appreciate your input Martin. Thx in advance for any additional comments
you might have.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Waldemar

Dear MS,

We have a child domain consisting of 15 Win2000 DC's in a total of 5
sites.
We have setup manual links in site and services for some of the sites
but
on
MS advice we like to remove all manual configurations and have kcc
create
all
connections automatically. (network is fully routed)

First: Site LINKS are always manual. You must create these,
as well as Subnets to define the sites.

Generally you should NOT be creating CONNECTIONS which
is the KCCs job 99.99% of the time.

Anyone who advised that without specific reasons is suspect.

Have have remove all manual configurations and let kcc do the job. We
notice
that on some of the site (one for example that have 4 dc's) not all
DC's
connections are created automatically by kcc. We have checked all dns
issues
using net & dc diag and dnslint, check all sysvol shares and enable
diagnostic logging (set it to level 3 and 5).

Are you saying there are DCs with NO connection objects in
the same site (where other DCs appear)?

Generally each DC should have two (sometimes 3 if the site
has many DCs) inbound and 2 (or 3) outbound to other DCs.

If this doesn't happen the first thing is to check DNS (and other
IP/firewall issues.)

Then look to see if the DCs are really "in the correct site"
based on the Subnet definitions -- and the actual location
in the Sites containers.

After this, try Time Sync checks and recheck DCDiag again
to make sure you have both DNS and replication working.

We are not receiving any dns nor kcc errors in the eventlogs but still
the
automatic connections are not created on some of the DC's.

Which? Give IP addresses and subnets for that Site.
State which have connections (in which direction) and
which do not.

So basically we no other error to troubleshoot and the kcc is not doing
the
job properly and we don't like to create manual connections.

You are correct to avoid this and fix the REAL problem.

Is there a specific documented steps (or kcc tracing tool) that we can
follow to exactly see where the kcc is failing? Is there a place in AD
where
some info must be available for kcc to add the automatic links between
the
DC's.

Probably the KCC has the "wrong information" due to
either DNS, Sites, Subnet definitions, or one or more
DCs being located in the "wrong Site container."

We like to fix the issue for the local site first (intra) and then
troubleshoot the remote site links (inter)

If the problem is to other between different sites there
should generally be only ONE DC (the BridgeHead server)
making the connections outside the site, and you might
check Schedules on the Site Link if that doesn't happen.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Any help will be appreciated.

Waldemar

 

[Herb Martin]

thx for the reply herb,

- We have 4 DC's in site Alca, 3 in site Alboa and 2 in site Alni.
- We have a site link to from Alca to Alboa and a site link from Alca to
Alni.
- So due to the ring configuration you mean RET-DC's should have 2
connections to 2 dc's in the Alboa (intra) right?

- But should all the RET-DC's (in site Alca) should have additional 5
connections (2 with Alboa DC's,

NO. ONE of them should have a pair to ONE in Alboa

and 3 with the alni DC's). Or oly the
bridgehead server will have the 5 addtional connections?

NO, ONLY the Bridgehead will have a connection set with
ONE in each* other site (so two more sets for two more sites)
(Not five more.) ONLY bridgeheads specifically connect
to ONLY bridgeheads in other sites.

*Assuming each site is connected by a lower cost than the sum
of the costs through the remaining site. Otherwise the site
bridgehead servers will connect like this: 1BH<->2BH<->3BH
(Of course that could be 2-1-3 or 1-3-2 instead.)


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Thx in advance Herb.

Waldemar

Thx for the reply Martin.

Call me Herb.

We have 4 dc's (RET-DC1, RET-DC2, RET-DC3 & RET-DC4)
Each are in the same building on sepparte floors and each floor consist
on
his own vlan. The servers ip are 10.135.11.2, 10.135.12.2, 10.135.13.2,
10.135.14.2 respectively. So we are have for subnets configure in the
site
and services 10.135.11.x, 10.135.12.x ect. All systems can ping and see
eacth
other. (we also tested the pinging of the GUID and all is ok) The main
site
is called Alca and it connects to 2 other sites Alboa and Alni

What is in those other sites if you only have four DCs and
they are in the same building? Although not an absolute rule,
there should generally be a DC in each site.

- I meant server connections not site links. (these are the ones that
should
be created automatically by kcc)

Yes, Connections is a technical term for the actual
pulls from DC to DC.

- For example RET-DC1 only have automatic connections to DC3, RET-DC3
only
have automatic connections to DC1 & DC2. Each DC should have at least 3
(intra) connectinos right?

No, each should have two Connections with 4 servers.
Every DC should be connected to two others in a logical
ring (1-2-3-4-backto1 or some such, as the numbers won't
necessarily match our human expectations of sequencing.)

If they do not then you likely have the site misdefined, some
DC in the wrong site, OR just plain old DNS problems which
accounts for most replication issues (but you do claim that
DCDiag passes with no replication or DNS errrors.)

- The servers in the other sites that this site is connected to does
appear
in the connectins in some of the DC's but not all of them.

That is likely correct behavior. DC in other site should be
connected to ONE of the DCs in this site in almost all cases.

If it is connected to more than one in this site then this implies
EITHER (or both) a Subnet-Site definition error or one or more
DCs in WRONG Site.

For instances if it looks like this: 1-2-OtherSiteDC-3-4-back to 1
this would imply that OtherSiteDC is in the wrong site for one
(or both of) those reasons (bad subnet defs, or just misplaced DC
because of prior bad subnet defs that have been corrected without
moving the DC to proper site, etc.)

Look in Sites and Services and show me you Subnets for EACH
site with Subnet masks. Also, check each DC and tell me which
site each DC shows itself in.

For example DC1
only have one automicatic connection to one server of the Alboa site
(that
site has 3 dc's). DC2 has mostly all the server connections. So
basically
why
one dc seems to have most of the automatic connections and others in
the
same
site does not?

If you mean the connections to the OTHER site then this is as
designed. One DC gets picked as Bridgehead server (at any
one time) and ONLY that DC replicates to and from other sites.

- Since we know that DNS is the first issues to check we have perform
all
the neccesary steps (in fact we had to because we just finish a Exch5.5
to
a
clustered Ex2003 migration) and we resolved all encountered error.

This does NOT mean you have it correct however.

Didn't you say that it passes DNS checks in DCDiag though?
(That is usually sufficient.)

- We also check all site naming and server locations and subnet
definition
and still no dice. That is the reason I like to dig deeper into kcc
functioning, so find out exactly what he looks for step by step so see
why
some servers get all the automatic connections and some don't.

Digging deeper into KCC is unlikely to fix the problem. Rechecking
the DNS, Sites, Subnets, Server to site assignments, firewall issues,
routing etc are likley to find and fix the problem (practically always
in fact.)

- Maybe you know of a active directory realtime tracing tool that can
show
all realtime changes in the AD once we select the "Check Topology"
option.

I find that tool to be near worthless and do my checks mentally
or with paper or graphics.

Detail your Sites and Services configuration if you need
more help.

I appreciate your input Martin. Thx in advance for any additional
comments
you might have.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Waldemar

:

Dear MS,

We have a child domain consisting of 15 Win2000 DC's in a total of 5
sites.
We have setup manual links in site and services for some of the
sites
but
on
MS advice we like to remove all manual configurations and have kcc
create
all
connections automatically. (network is fully routed)

First: Site LINKS are always manual. You must create these,
as well as Subnets to define the sites.

Generally you should NOT be creating CONNECTIONS which
is the KCCs job 99.99% of the time.

Anyone who advised that without specific reasons is suspect.

Have have remove all manual configurations and let kcc do the job.
We
notice
that on some of the site (one for example that have 4 dc's) not all
DC's
connections are created automatically by kcc. We have checked all
dns
issues
using net & dc diag and dnslint, check all sysvol shares and enable
diagnostic logging (set it to level 3 and 5).

Are you saying there are DCs with NO connection objects in
the same site (where other DCs appear)?

Generally each DC should have two (sometimes 3 if the site
has many DCs) inbound and 2 (or 3) outbound to other DCs.

If this doesn't happen the first thing is to check DNS (and other
IP/firewall issues.)

Then look to see if the DCs are really "in the correct site"
based on the Subnet definitions -- and the actual location
in the Sites containers.

After this, try Time Sync checks and recheck DCDiag again
to make sure you have both DNS and replication working.

We are not receiving any dns nor kcc errors in the eventlogs but
still
the
automatic connections are not created on some of the DC's.

Which? Give IP addresses and subnets for that Site.
State which have connections (in which direction) and
which do not.

So basically we no other error to troubleshoot and the kcc is not
doing
the
job properly and we don't like to create manual connections.

You are correct to avoid this and fix the REAL problem.

Is there a specific documented steps (or kcc tracing tool) that we
can
follow to exactly see where the kcc is failing? Is there a place in
AD
where
some info must be available for kcc to add the automatic links
between
the
DC's.

Probably the KCC has the "wrong information" due to
either DNS, Sites, Subnet definitions, or one or more
DCs being located in the "wrong Site container."

We like to fix the issue for the local site first (intra) and then
troubleshoot the remote site links (inter)

If the problem is to other between different sites there
should generally be only ONE DC (the BridgeHead server)
making the connections outside the site, and you might
check Schedules on the Site Link if that doesn't happen.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


Any help will be appreciated.

Waldemar

 

[Guest]

Happy new year for you Herb. I wish you all the best for this year.

I have been off the last 2 weeks I wil let you know if I have more questions.

thx for the reply herb,

- We have 4 DC's in site Alca, 3 in site Alboa and 2 in site Alni.
- We have a site link to from Alca to Alboa and a site link from Alca to
Alni.
- So due to the ring configuration you mean RET-DC's should have 2
connections to 2 dc's in the Alboa (intra) right?

- But should all the RET-DC's (in site Alca) should have additional 5
connections (2 with Alboa DC's,

NO. ONE of them should have a pair to ONE in Alboa

and 3 with the alni DC's). Or oly the
bridgehead server will have the 5 addtional connections?

NO, ONLY the Bridgehead will have a connection set with
ONE in each* other site (so two more sets for two more sites)
(Not five more.) ONLY bridgeheads specifically connect
to ONLY bridgeheads in other sites.

*Assuming each site is connected by a lower cost than the sum
of the costs through the remaining site. Otherwise the site
bridgehead servers will connect like this: 1BH<->2BH<->3BH
(Of course that could be 2-1-3 or 1-3-2 instead.)


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Thx in advance Herb.

Waldemar

Thx for the reply Martin.

Call me Herb.

We have 4 dc's (RET-DC1, RET-DC2, RET-DC3 & RET-DC4)
Each are in the same building on sepparte floors and each floor consist
on
his own vlan. The servers ip are 10.135.11.2, 10.135.12.2, 10.135.13.2,
10.135.14.2 respectively. So we are have for subnets configure in the
site
and services 10.135.11.x, 10.135.12.x ect. All systems can ping and see
eacth
other. (we also tested the pinging of the GUID and all is ok) The main
site
is called Alca and it connects to 2 other sites Alboa and Alni

What is in those other sites if you only have four DCs and
they are in the same building? Although not an absolute rule,
there should generally be a DC in each site.


- I meant server connections not site links. (these are the ones that
should
be created automatically by kcc)

Yes, Connections is a technical term for the actual
pulls from DC to DC.

- For example RET-DC1 only have automatic connections to DC3, RET-DC3
only
have automatic connections to DC1 & DC2. Each DC should have at least 3
(intra) connectinos right?

No, each should have two Connections with 4 servers.
Every DC should be connected to two others in a logical
ring (1-2-3-4-backto1 or some such, as the numbers won't
necessarily match our human expectations of sequencing.)

If they do not then you likely have the site misdefined, some
DC in the wrong site, OR just plain old DNS problems which
accounts for most replication issues (but you do claim that
DCDiag passes with no replication or DNS errrors.)

- The servers in the other sites that this site is connected to does
appear
in the connectins in some of the DC's but not all of them.

That is likely correct behavior. DC in other site should be
connected to ONE of the DCs in this site in almost all cases.

If it is connected to more than one in this site then this implies
EITHER (or both) a Subnet-Site definition error or one or more
DCs in WRONG Site.

For instances if it looks like this: 1-2-OtherSiteDC-3-4-back to 1
this would imply that OtherSiteDC is in the wrong site for one
(or both of) those reasons (bad subnet defs, or just misplaced DC
because of prior bad subnet defs that have been corrected without
moving the DC to proper site, etc.)

Look in Sites and Services and show me you Subnets for EACH
site with Subnet masks. Also, check each DC and tell me which
site each DC shows itself in.

For example DC1
only have one automicatic connection to one server of the Alboa site
(that
site has 3 dc's). DC2 has mostly all the server connections. So
basically
why
one dc seems to have most of the automatic connections and others in
the
same
site does not?

If you mean the connections to the OTHER site then this is as
designed. One DC gets picked as Bridgehead server (at any
one time) and ONLY that DC replicates to and from other sites.

- Since we know that DNS is the first issues to check we have perform
all
the neccesary steps (in fact we had to because we just finish a Exch5.5
to
a
clustered Ex2003 migration) and we resolved all encountered error.

This does NOT mean you have it correct however.

Didn't you say that it passes DNS checks in DCDiag though?
(That is usually sufficient.)


- We also check all site naming and server locations and subnet
definition
and still no dice. That is the reason I like to dig deeper into kcc
functioning, so find out exactly what he looks for step by step so see
why
some servers get all the automatic connections and some don't.

Digging deeper into KCC is unlikely to fix the problem. Rechecking
the DNS, Sites, Subnets, Server to site assignments, firewall issues,
routing etc are likley to find and fix the problem (practically always
in fact.)

- Maybe you know of a active directory realtime tracing tool that can
show
all realtime changes in the AD once we select the "Check Topology"
option.

I find that tool to be near worthless and do my checks mentally
or with paper or graphics.

Detail your Sites and Services configuration if you need
more help.

I appreciate your input Martin. Thx in advance for any additional
comments
you might have.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]

Waldemar

:

Dear MS,

We have a child domain consisting of 15 Win2000 DC's in a total of 5
sites.
We have setup manual links in site and services for some of the
sites
but
on
MS advice we like to remove all manual configurations and have kcc
create
all
connections automatically. (network is fully routed)

First: Site LINKS are always manual. You must create these,
as well as Subnets to define the sites.

Generally you should NOT be creating CONNECTIONS which
is the KCCs job 99.99% of the time.

Anyone who advised that without specific reasons is suspect.

Have have remove all manual configurations and let kcc do the job.
We
notice
that on some of the site (one for example that have 4 dc's) not all
DC's
connections are created automatically by kcc. We have checked all
dns
issues
using net & dc diag and dnslint, check all sysvol shares and enable
diagnostic logging (set it to level 3 and 5).

Are you saying there are DCs with NO connection objects in
the same site (where other DCs appear)?

Generally each DC should have two (sometimes 3 if the site
has many DCs) inbound and 2 (or 3) outbound to other DCs.

If this doesn't happen the first thing is to check DNS (and other
IP/firewall issues.)

Then look to see if the DCs are really "in the correct site"
based on the Subnet definitions -- and the actual location
in the Sites containers.

After this, try Time Sync checks and recheck DCDiag again
to make sure you have both DNS and replication working.

We are not receiving any dns nor kcc errors in the eventlogs but
still
the
automatic connections are not created on some of the DC's.

Which? Give IP addresses and subnets for that Site.
State which have connections (in which direction) and
which do not.

So basically we no other error to troubleshoot and the kcc is not
doing
the
job properly and we don't like to create manual connections.

You are correct to avoid this and fix the REAL problem.

Is there a specific documented steps (or kcc tracing tool) that we
can
follow to exactly see where the kcc is failing? Is there a place in
AD
where
some info must be available for kcc to add the automatic links
between
the
DC's.

Probably the KCC has the "wrong information" due to
either DNS, Sites, Subnet definitions, or one or more
DCs being located in the "wrong Site container."

We like to fix the issue for the local site first (intra) and then
troubleshoot the remote site links (inter)

If the problem is to other between different sites there
should generally be only ONE DC (the BridgeHead server)
making the connections outside the site, and you might
check Schedules on the Site Link if that doesn't happen.


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]


Any help will be appreciated.

Waldemar

 

[Herb Martin]

Happy new year for you Herb. I wish you all the best for this year.

I have been off the last 2 weeks I wil let you know if I have more

questions.

Happy New Year to you too.

I haven't been around much either but do let us know if you
need more help.

 

[Joe Richards [MVP]]

I kind of poked and looked at the postings but didn't read in the entirety.

You define subnets and site links. Assuming this is done properly then
the KCC can define connections as needed. They may not be what you think
may be needed but usually the KCC knows more about it than admins. If it
is absolutely wrong, the fault is 99.99999% in the site link / subnet
definitions with the other .00001% being KCC bugs. Most of those bugs
though are for large large large deployments. 15 DCs in 5 sites is
really nothing to the KCC.

First off you define subnets for any specific subnets that you need to
identify machines on uniquely. For instance if you have two physical
subnets of 192.168.0.0/24 and 192.168.1.0/24 but there is no reason to
they need to be separated in AD, i.e. they both are assigned to the same
site, use 192.168.0.0/23. Collapse the number of subnets logically in AD
to as small a number as you must have.

Second off you define your sites. Sites are area of good connectivity.
This varies by companies by what that means and there is no hard and
fast definitions though there are no end of people trying to give hard
and fast definitions. If I have to give anything, I say an area where
you have resources you want all tied together. Could be a portion of a
subnet within a single room, could be a building, could be a campus of
several buildings, could be an entire set of buildings in a single city,
etc. If they are logically tied together and and have good connectivity
between them, tie them together.

Third off, you define your site links. This is where people tend to most
screw up their topologies. You need to make links that relate to the
physical network. You will set replication frequency and the metric for
the connection. There is, again, no hard and fast rule for the metrics,
it is all relative with the lower metric values meaning fastest/best
bandwidth and higher metric values meaning slower/worst bandwidth. A
common scenerio for large companies is called a multihub and spoke where
you have 2-4 large datacenters who all have serious high speed
connections between them and those connections will usually have a low
metric. If you build logical sites within a datacenter (say like for
Exchange or an SMTP backbone or other app logical site) that will have
the only metrics that are lower. Then the spokes from the hubs to WAN
sites will have metrics of various levels depending on the network
quality or if you want less admin overhead recommended) and everything
ties back to the hubs, they could all be defined to be the same
regardless of speed/quality.

For small companies, usually you have several sites roughly connected
together through some public internet cloud scheme. In that case, no one
site has better connectivity than another. The metrics may be identical
between the site links created for all of them or you may just say screw
it and create one single site link and throw them all into it. If you
aren't trying to route replication between the sites in any specific
way, this is perfectly fine.

Now when the KCC works. You will see a ring topology created in every
site. Since you have so few DCs you will likely see two change
notification connections for each DC. One to each of its direct partners
in the ring. One or more of the DCs in each site will be a bridge head
to connect to the other sites. In 2K, this was pretty much always a
single DC (unless you ran ADLB to load balance the connections), with K3
it load balances though I am not sure when the actual load balancing
kicks in, never really dug into it for small environments.





--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Guest]

I appreciate your detailed input Joe.

So basically if all connections are defined properly the bridgehead server
at the main site should have all (bridgehead) servers of the connected sites
listed in his connections right? This is one of the issues we are having
becuase the bridgehead server on the main site is missing some of the servers
of the remote sites in his connections list. I think it has to do with the
fact that even though we have connections to the remote sites the topology
(intersite) is not a star but also a ring right?

Let me know what you think.

thx in advance
Waldemar

 

[Herb Martin]

I appreciate your detailed input Joe.

So basically if all connections are defined properly

Connections and SiteLinks are technical terms -- Site links
give the KCC 'permission' or 'encouragement' to create the
connections so if you change your sentence about to replace
"connections" with "Site Lins" (i.e., defined properly then it
becomes correct.

... the bridgehead server
at the main site should have all (bridgehead) servers of the connected sites
listed in his connections right?

IF you have all of the Site Links directly to the
Main site (hub and spoke with Main site as hub).

This is one of the issues we are having
becuase the bridgehead server on the main site is missing some of the servers
of the remote sites in his connections list.

Are there direct SiteLinks between each of those Sites
and the main?

If not, create those. If so, then look to problems with
DCs in the "wrong" site or with Sites misdefined due to
mistakes in the (or just incomplete) Subnet definitions.

If it isn't one of these then likely it is a DNS problem (e.g.,
some DCs not registered or not registered in the proper
Site Containers of DNS), or anything else that causes DCs
to fail to replicate (e.g., routing, firewall, etc problems.)

I think it has to do with the
fact that even though we have connections to the remote sites the topology
(intersite) is not a star but also a ring right?

No. The KCC works for a fully connected "network" or
perhaps a "spanning tree". It doesn't do this by trying for
either a ring or a star (intersite), but by looking for the
"best" (i.e., lowest cost) connections along the Site Links you
provide.

If you create a star (hub and spoke) Site Link set then the KCC
will practically always follow that with it's own star of connections
(as long as the DCs in the hub/main site are up and properly
registered in DNS and available.)

If you create a ring then the KCC will try to follow that. The
KCC uses YOUR "SITE LINKS" to make it's actual
connection choices.

 

[Guest]

Got it Herb. I will re-check the configuration again and get back to you.

 

[Joe Richards [MVP]]

Sorry, I meant to mention that in the first post. The KCC creates a max
3-hop ring for intrasite DCs and uses a spanning tree algorithm for
intersite. It is absolutely not strange to not see a bridgehead in a
site NOT make connections to bridgeheads in every site. In fact, I have
seen environments where the spanning tree went 7-8 hops deep meaning an
item had to replicate through 7-8 sites to get end to end. Think of a
long line with 8 sites and site 1 is connected to 2 which is connected
to 3, so on and so on.

Any given site doesn't have to be connected to every other single site.
There just has to be an unbroken set of connections to get from one site
to every other site. If you set up and you don't get a replication
topology for your WAN sites that you like, i.e. say it isn't a star
which is one of the lowest latency configurations, it is due to the site
link configurations.

joe


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Herb Martin]

... If you set up and you don't get a replication

topology for your WAN sites that you like, i.e. say it isn't a star
which is one of the lowest latency configurations, it is due to the site
link configurations.

Or something else that interferes with the replication or
contact between DCs, e.g., DNS, firewalls, routing,
DC in wrong site, incorrect subnet definitions for site, etc..

 

[Guest]

Thx for the additional info Joe & Herb. I always thought we had problems
becuase of some of the missing connection links in some DC's. Though we have
detected some missing replication items on the remote DC's but missing DNS
records are the biggest problems. Sorry for off topic (maybe) but Dns entries
are partly replicated by Active directory right? We have setup forwarders and
allow zone transfers in each DC dns configuration. But the main issue we
notice is that since we are part of top level domain (we are a child domain)
many dns entries at a root DC (we have a root DC from top domain at our
site) don't get replicated to the other DC's and also the other way around.

Thx again for the support.

waldemar

:

 

[Herb Martin]

Thx for the additional info Joe & Herb.

You are welcome.

I always thought we had problems
becuase of some of the missing connection links in some DC's.

You were probably right in a sense, but didn't realize the (likely)
real cause of the missing connections were missing SiteLinks or
other problems with Sites, Subnets, DC to site assignment, or
routing & DNS issues.

The KCC will practically always do it right IF you give it the
full, correct information to work with, and the routing and DNS
are functioning correctly.

Though we have
detected some missing replication items on the remote DC's but missing DNS
records are the biggest problems. Sorry for off topic (maybe) but Dns entries
are partly replicated by Active directory right?

Yes (it's not off topic) and even before DNS may be replicated
by AD, AD is ALWAYS dependent on DNS (being right) for
replication to work.

We have setup forwarders and
allow zone transfers in each DC dns configuration.

For a single domain forwarders should be irrelevant to the
AD and its use of DNS. (Forwarders are important for
Internet replication and perhaps conditional forwarders for
multi-domain resolution.)

But the main issue we
notice is that since we are part of top level domain (we are a child domain)
many dns entries at a root DC (we have a root DC from top domain at our
site) don't get replicated to the other DC's and also the other way

around.

DNS is the primary reason that AD fails to either replicate or
authenticate clients.

Your problem could be due strictly to Site and Site Link definition
problems, or strictly to DNS, or even a mixture of the two.

 

[Joe Richards [MVP]]

DNS records _can_ be replicated in AD. Depends on if Windows is hosting
DNS and whether you are using AD Integrated DNS. Neither of which can be
assumed but are popular in smaller orgs. Even if it is ADI someone could
specifically be choosing what records are replicated where. You don't
have to have everything everywhere in order for things to work, you just
need name resolution. Have you seen issues where DC names aren't
resolving properly?



--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm