Automatic site link bridging

[Andrew Story]

Hello NG,

I have some sites connected to our main MPLS platform (fully routed network)
via VPN. Not all the VPN sites have physical connectivity to all the other
sites, due to the amount of tunnels allowed due to the spec of the firewalls
we are using.

On the some of the VPN sites I have alot of errors in event viewer (Event
ID:1331 and 1556) advising that some other sites cannot be contacted. I
appreciate that some of the VPN sites cannot contact all the other sites
directly due to the firewall specs, and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the entire
domain. My question is, will these errors disappear in time, e.g. will AD
simply 'give up' trying to contact these other sites? and if so, will it
cause any issues?

Cheers.

 

[Herb Martin]

Hello NG,

I have some sites connected to our main MPLS platform (fully routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event viewer (Event
ID:1331 and 1556) advising that some other sites cannot be contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the entire
domain. My question is, will these errors disappear in time, e.g. will AD
simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.

 

[Andrew Story]

Hi Herb,

Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these sites
DC, depending on spec of firewall installed, regarding amount of support VPN
tunnels). Some of the VPN sites that are connected to the MPLS network via
the VPN Tunnels have low spec firewalls that do not have the ability to have
more than a few tunnels setup.

These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these sites)
to every DC in the organisation, due to the spec of the firewalls, which
means in turn that we cannot have many VPN IPSec tunnels.

In ADS&S these VPN sites with DC's are defined, and have a site link back to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD site is
defined in ADS&S, every AD site has the relevent site DC associated with it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So, the
sites that are connected via VPN have only a site link back to the Hub sites
DC. Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging, and as far
as I am aware the VPN sites AD servers event log errors are telling me that
there would be no replication possible to some AD sites, due to there being
no direct route to these AD sites (please correct me if I'm wrong), but will
these errors go away in time, will they cause any harm (you answered that
already), can they be stopped? I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in ADS&S.

If I'm making no sense please let me know. Thanks for your response

Hello NG,

I have some sites connected to our main MPLS platform (fully routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event viewer (Event
ID:1331 and 1556) advising that some other sites cannot be contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the entire
domain. My question is, will these errors disappear in time, e.g. will AD
simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.



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

 

[Herb Martin]

Hi Herb,

Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these
sites
DC, depending on spec of firewall installed, regarding amount of support
VPN
tunnels). Some of the VPN sites that are connected to the MPLS network
via
the VPN Tunnels have low spec firewalls that do not have the ability to
have
more than a few tunnels setup.

These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these
sites)
to every DC in the organisation, due to the spec of the firewalls, which
means in turn that we cannot have many VPN IPSec tunnels.

These limitations cause me to consider the network not fully
routed since the DCs cannot route between each other across
all possible (physical or logical) paths.

This is one of the main purposes for custom Site Link Bridge-grouping:
You put only those SitesLinks that would actually be usuable into the
same transitive SiteLinkBridge-group(s).

This means that each sites DCs can (IF necessary) use those double,
triple, etc., 'virtual SiteLinks' to bypass any intermediate sites with
down DC while still preferring those direct and lower cost explicit
links.

In ADS&S these VPN sites with DC's are defined, and have a site link back
to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD site is
defined in ADS&S, every AD site has the relevent site DC associated with
it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So,
the
sites that are connected via VPN have only a site link back to the Hub
sites
DC.

It seems to be just a simple Hub architecture with site links
back to, and only back to, the hub from each remote location.

Perfectly normal and usually reasonable.

Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging,

I didn't find it particularly difficult to understand your
description so don't worry about it. On the other hand,
I do make a practice of correcting misstatements or places
where the terminology or wording is not helping to solve
the problem someone is not facing.

As you explain below, that lack of routing is likely causing the
errors you see....

and as far
as I am aware the VPN sites AD servers event log errors are telling me
that
there would be no replication possible to some AD sites, due to there
being
no direct route to these AD sites (please correct me if I'm wrong), but
will
these errors go away in time,

Probably not. Even if they do go away, they will return from
time to time as the situation (current status of your DCs and
networks) changes.

will they cause any harm (you answered that
already), can they be stopped?

(To recap: No serious harm from the errrors except to possibly
mask 'real' problems by filling up or cluttering your event logs
and by causing you to get in the habit of ignoring them -- this latter
is a separate psychological issue that we ALL suffer from when
we leave error messages for innocuous problems.)

I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in ADS&S.

If you wanted to "fix it" you would turn off the default
full SiteLikeBridge-grouping, and only include those
SiteLinks (in each custom group) which are full routable
(for DC purposes).

IF you have simply that central-Hub and unconnected spoke
topology you would do LITTLE harm by just turning off the
SiteLink Bridging.

The downside would be that were the central (hub) DCs to
all go down WHILE the network and routing continued to function
then you would not replicate remote-to-remote without being
able to stage the replications through the hub.

For times when the network is non-functional (likely if ALL of the
DCs in the hub are down AND the routers live in the same physical
networks) then nothing would be lost since it would be all or nothing
anyway.

For networks where there are SOME paths "across" the hub (or
around, which you don't seem to have) then NEW "site link bridge-
groups" would allow those pairs of sites to replicate without involving
the central hub DCs.

You could also (while disabling the bridge-grouping) just put in
additional SiteLinks with higher costs and control it that way.
(This becomes complicated as the number of SiteLinks grows and
the KCC is usually better at calculating this dynamically for you,
but you are also free to just set your own links and turn off that
transitivity.)

If I'm making no sense please let me know. Thanks for your response

No, you are doing fine -- just ask anything specific that doesn't
make sense to you yet, or that you think of as you continue to
work your design.

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

Hello NG,

I have some sites connected to our main MPLS platform (fully routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event viewer (Event
ID:1331 and 1556) advising that some other sites cannot be contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other
sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the
entire
domain. My question is, will these errors disappear in time, e.g. will AD
simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.



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

 

[Andrew Story]

Good morning Herb,

Thanks for yet another detailed reply (I think I must owe you a few beers at
least by now).

What you've advised makes total sense to me and confirms my original
thoughts. I had thought of disabling auto site link bridging, but the AD
domain is constantly expanding as our rollout continues, and I wouldn't want
to have to manage site link bridges. The more I can let AD manage itself,
the better. I may advise that the spec of firewall's we have on some sites
be upgraded, to allow a greater amount of tunnels, so we can more or less
make the network fully routed, and leave auto site link bridging enabled.

Just out of interest, do you know of any good documentation that describes
how to correclty implement manual site link bridges?

Thanks for your time (again), it really is much appreciated.

Andrew

Hi Herb,

Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these
sites
DC, depending on spec of firewall installed, regarding amount of support
VPN
tunnels). Some of the VPN sites that are connected to the MPLS network
via
the VPN Tunnels have low spec firewalls that do not have the ability to
have
more than a few tunnels setup.

These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these
sites)
to every DC in the organisation, due to the spec of the firewalls, which
means in turn that we cannot have many VPN IPSec tunnels.

These limitations cause me to consider the network not fully
routed since the DCs cannot route between each other across
all possible (physical or logical) paths.

This is one of the main purposes for custom Site Link Bridge-grouping:
You put only those SitesLinks that would actually be usuable into the
same transitive SiteLinkBridge-group(s).

This means that each sites DCs can (IF necessary) use those double,
triple, etc., 'virtual SiteLinks' to bypass any intermediate sites with
down DC while still preferring those direct and lower cost explicit
links.

In ADS&S these VPN sites with DC's are defined, and have a site link back
to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD site is
defined in ADS&S, every AD site has the relevent site DC associated with
it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So,
the
sites that are connected via VPN have only a site link back to the Hub
sites
DC.

It seems to be just a simple Hub architecture with site links
back to, and only back to, the hub from each remote location.

Perfectly normal and usually reasonable.

Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging,

I didn't find it particularly difficult to understand your
description so don't worry about it. On the other hand,
I do make a practice of correcting misstatements or places
where the terminology or wording is not helping to solve
the problem someone is not facing.

As you explain below, that lack of routing is likely causing the
errors you see....

and as far
as I am aware the VPN sites AD servers event log errors are telling me
that
there would be no replication possible to some AD sites, due to there
being
no direct route to these AD sites (please correct me if I'm wrong), but
will
these errors go away in time,

Probably not. Even if they do go away, they will return from
time to time as the situation (current status of your DCs and
networks) changes.

will they cause any harm (you answered that
already), can they be stopped?

(To recap: No serious harm from the errrors except to possibly
mask 'real' problems by filling up or cluttering your event logs
and by causing you to get in the habit of ignoring them -- this latter
is a separate psychological issue that we ALL suffer from when
we leave error messages for innocuous problems.)

I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in

ADS&S.

If you wanted to "fix it" you would turn off the default
full SiteLikeBridge-grouping, and only include those
SiteLinks (in each custom group) which are full routable
(for DC purposes).

IF you have simply that central-Hub and unconnected spoke
topology you would do LITTLE harm by just turning off the
SiteLink Bridging.

The downside would be that were the central (hub) DCs to
all go down WHILE the network and routing continued to function
then you would not replicate remote-to-remote without being
able to stage the replications through the hub.

For times when the network is non-functional (likely if ALL of the
DCs in the hub are down AND the routers live in the same physical
networks) then nothing would be lost since it would be all or nothing
anyway.

For networks where there are SOME paths "across" the hub (or
around, which you don't seem to have) then NEW "site link bridge-
groups" would allow those pairs of sites to replicate without involving
the central hub DCs.

You could also (while disabling the bridge-grouping) just put in
additional SiteLinks with higher costs and control it that way.
(This becomes complicated as the number of SiteLinks grows and
the KCC is usually better at calculating this dynamically for you,
but you are also free to just set your own links and turn off that
transitivity.)

If I'm making no sense please let me know. Thanks for your response

No, you are doing fine -- just ask anything specific that doesn't
make sense to you yet, or that you think of as you continue to
work your design.

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

"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hello NG,

I have some sites connected to our main MPLS platform (fully routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event viewer (Event
ID:1331 and 1556) advising that some other sites cannot be contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other
sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the
entire
domain. My question is, will these errors disappear in time, e.g.

will
AD

simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.



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

 

[Andrew Story]

Slightly off topic Herb, but do you know much about 'morphed direcories' at
all?

I have just ran ultrasound and it has found 5 policies that have been
'morphed'. The five 'normal' policies exist, but there is an addition
policy showing for each one it as morphed, and with a _NTFRS_xxxxxxx after
them.

Have you came across this before? If you have, and have any pointers, it
would be much appreciated.

Good morning Herb,

Thanks for yet another detailed reply (I think I must owe you a few beers at
least by now).

What you've advised makes total sense to me and confirms my original
thoughts. I had thought of disabling auto site link bridging, but the AD
domain is constantly expanding as our rollout continues, and I wouldn't want
to have to manage site link bridges. The more I can let AD manage itself,
the better. I may advise that the spec of firewall's we have on some sites
be upgraded, to allow a greater amount of tunnels, so we can more or less
make the network fully routed, and leave auto site link bridging enabled.

Just out of interest, do you know of any good documentation that describes
how to correclty implement manual site link bridges?

Thanks for your time (again), it really is much appreciated.

Andrew

Hi Herb,

Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these
sites
DC, depending on spec of firewall installed, regarding amount of support
VPN
tunnels). Some of the VPN sites that are connected to the MPLS network
via
the VPN Tunnels have low spec firewalls that do not have the ability to
have
more than a few tunnels setup.

These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these
sites)
to every DC in the organisation, due to the spec of the firewalls, which
means in turn that we cannot have many VPN IPSec tunnels.

These limitations cause me to consider the network not fully
routed since the DCs cannot route between each other across
all possible (physical or logical) paths.

This is one of the main purposes for custom Site Link Bridge-grouping:
You put only those SitesLinks that would actually be usuable into the
same transitive SiteLinkBridge-group(s).

This means that each sites DCs can (IF necessary) use those double,
triple, etc., 'virtual SiteLinks' to bypass any intermediate sites with
down DC while still preferring those direct and lower cost explicit
links.

In ADS&S these VPN sites with DC's are defined, and have a site link back
to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD site is
defined in ADS&S, every AD site has the relevent site DC associated with
it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So,
the
sites that are connected via VPN have only a site link back to the Hub
sites
DC.

It seems to be just a simple Hub architecture with site links
back to, and only back to, the hub from each remote location.

Perfectly normal and usually reasonable.

Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging,

I didn't find it particularly difficult to understand your
description so don't worry about it. On the other hand,
I do make a practice of correcting misstatements or places
where the terminology or wording is not helping to solve
the problem someone is not facing.

As you explain below, that lack of routing is likely causing the
errors you see....

and as far
as I am aware the VPN sites AD servers event log errors are telling me
that
there would be no replication possible to some AD sites, due to there
being
no direct route to these AD sites (please correct me if I'm wrong), but
will
these errors go away in time,

Probably not. Even if they do go away, they will return from
time to time as the situation (current status of your DCs and
networks) changes.

will they cause any harm (you answered that
already), can they be stopped?

(To recap: No serious harm from the errrors except to possibly
mask 'real' problems by filling up or cluttering your event logs
and by causing you to get in the habit of ignoring them -- this latter
is a separate psychological issue that we ALL suffer from when
we leave error messages for innocuous problems.)

I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in

ADS&S.

If you wanted to "fix it" you would turn off the default
full SiteLikeBridge-grouping, and only include those
SiteLinks (in each custom group) which are full routable
(for DC purposes).

IF you have simply that central-Hub and unconnected spoke
topology you would do LITTLE harm by just turning off the
SiteLink Bridging.

The downside would be that were the central (hub) DCs to
all go down WHILE the network and routing continued to function
then you would not replicate remote-to-remote without being
able to stage the replications through the hub.

For times when the network is non-functional (likely if ALL of the
DCs in the hub are down AND the routers live in the same physical
networks) then nothing would be lost since it would be all or nothing
anyway.

For networks where there are SOME paths "across" the hub (or
around, which you don't seem to have) then NEW "site link bridge-
groups" would allow those pairs of sites to replicate without involving
the central hub DCs.

You could also (while disabling the bridge-grouping) just put in
additional SiteLinks with higher costs and control it that way.
(This becomes complicated as the number of SiteLinks grows and
the KCC is usually better at calculating this dynamically for you,
but you are also free to just set your own links and turn off that
transitivity.)

If I'm making no sense please let me know. Thanks for your response

No, you are doing fine -- just ask anything specific that doesn't
make sense to you yet, or that you think of as you continue to
work your design.

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

"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hello NG,

I have some sites connected to our main MPLS platform (fully routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event viewer
(Event
ID:1331 and 1556) advising that some other sites cannot be contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other
sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the
entire
domain. My question is, will these errors disappear in time, e.g. will
AD
simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.



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

 

[Herb Martin]

Good morning Herb,

Thanks for yet another detailed reply (I think I must owe you a few beers
at
least by now).

What you've advised makes total sense to me and confirms my original
thoughts. I had thought of disabling auto site link bridging, but the AD
domain is constantly expanding as our rollout continues, and I wouldn't
want
to have to manage site link bridges. The more I can let AD manage itself,
the better. I may advise that the spec of firewall's we have on some
sites
be upgraded, to allow a greater amount of tunnels, so we can more or less
make the network fully routed, and leave auto site link bridging enabled.

Just out of interest, do you know of any good documentation that describes
how to correclty implement manual site link bridges?

No. They are practically never even explained well in any of the books.

Few companies have need of such complexity and few people understand
it (even to the level you obviously do at this point.)

You are way ahead of the game from what you have written here.

My students get this because I teach it correctly from the beginning,
but the hardest thing about that is giving them a real world example.

The reason for this is such examples are by their very nature complicated
if they are going to be realistic. Making such simple (enough to
understand)
and real is very tricky.

SiteLinkBridging ONLY matters if you have to "skip"
over Sites where the DCs are down (i.e., exect the KCC
to use transitive SiteLinks.)

Turning it off is NOT a big deal if you have the actual
situation -- turning it back on later is not a big deal either.


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

Thanks for your time (again), it really is much appreciated.

Andrew

Hi Herb,

Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these
sites
DC, depending on spec of firewall installed, regarding amount of
support
VPN
tunnels). Some of the VPN sites that are connected to the MPLS network
via
the VPN Tunnels have low spec firewalls that do not have the ability to
have
more than a few tunnels setup.

These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these
sites)
to every DC in the organisation, due to the spec of the firewalls,
which
means in turn that we cannot have many VPN IPSec tunnels.

These limitations cause me to consider the network not fully
routed since the DCs cannot route between each other across
all possible (physical or logical) paths.

This is one of the main purposes for custom Site Link Bridge-grouping:
You put only those SitesLinks that would actually be usuable into the
same transitive SiteLinkBridge-group(s).

This means that each sites DCs can (IF necessary) use those double,
triple, etc., 'virtual SiteLinks' to bypass any intermediate sites with
down DC while still preferring those direct and lower cost explicit
links.

In ADS&S these VPN sites with DC's are defined, and have a site link back
to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD site is
defined in ADS&S, every AD site has the relevent site DC associated
with
it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So,
the
sites that are connected via VPN have only a site link back to the Hub
sites
DC.

It seems to be just a simple Hub architecture with site links
back to, and only back to, the hub from each remote location.

Perfectly normal and usually reasonable.

Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging,

I didn't find it particularly difficult to understand your
description so don't worry about it. On the other hand,
I do make a practice of correcting misstatements or places
where the terminology or wording is not helping to solve
the problem someone is not facing.

As you explain below, that lack of routing is likely causing the
errors you see....

and as far
as I am aware the VPN sites AD servers event log errors are telling me
that
there would be no replication possible to some AD sites, due to there
being
no direct route to these AD sites (please correct me if I'm wrong), but
will
these errors go away in time,

Probably not. Even if they do go away, they will return from
time to time as the situation (current status of your DCs and
networks) changes.

will they cause any harm (you answered that
already), can they be stopped?

(To recap: No serious harm from the errrors except to possibly
mask 'real' problems by filling up or cluttering your event logs
and by causing you to get in the habit of ignoring them -- this latter
is a separate psychological issue that we ALL suffer from when
we leave error messages for innocuous problems.)

I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in

ADS&S.

If you wanted to "fix it" you would turn off the default
full SiteLikeBridge-grouping, and only include those
SiteLinks (in each custom group) which are full routable
(for DC purposes).

IF you have simply that central-Hub and unconnected spoke
topology you would do LITTLE harm by just turning off the
SiteLink Bridging.

The downside would be that were the central (hub) DCs to
all go down WHILE the network and routing continued to function
then you would not replicate remote-to-remote without being
able to stage the replications through the hub.

For times when the network is non-functional (likely if ALL of the
DCs in the hub are down AND the routers live in the same physical
networks) then nothing would be lost since it would be all or nothing
anyway.

For networks where there are SOME paths "across" the hub (or
around, which you don't seem to have) then NEW "site link bridge-
groups" would allow those pairs of sites to replicate without involving
the central hub DCs.

You could also (while disabling the bridge-grouping) just put in
additional SiteLinks with higher costs and control it that way.
(This becomes complicated as the number of SiteLinks grows and
the KCC is usually better at calculating this dynamically for you,
but you are also free to just set your own links and turn off that
transitivity.)

If I'm making no sense please let me know. Thanks for your response

No, you are doing fine -- just ask anything specific that doesn't
make sense to you yet, or that you think of as you continue to
work your design.

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

"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hello NG,

I have some sites connected to our main MPLS platform (fully routed
network)
via VPN. Not all the VPN sites have physical connectivity to all
the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event viewer
(Event
ID:1331 and 1556) advising that some other sites cannot be
contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other
sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the
entire
domain. My question is, will these errors disappear in time, e.g. will
AD
simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.



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

 

[Herb Martin]

Slightly off topic Herb, but do you know much about 'morphed direcories'
at
all?

I have just ran ultrasound and it has found 5 policies that have been
'morphed'. The five 'normal' policies exist, but there is an addition
policy showing for each one it as morphed, and with a _NTFRS_xxxxxxx after
them.

No, as far as I know this term is due to "ultrasound" (whatever
that is.)

Have you came across this before? If you have, and have any pointers, it
would be much appreciated.

I would Google something like:

[ microsoft: morphed directory | ultrasound ]

Or:

[ site:microsoft.com morphed directory | ultrasound ]

The first looks for "microsoft:" stuff everywhere on the net,
while the latter is restricted to the MS site.


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

Good morning Herb,

Thanks for yet another detailed reply (I think I must owe you a few beers at
least by now).

What you've advised makes total sense to me and confirms my original
thoughts. I had thought of disabling auto site link bridging, but the AD
domain is constantly expanding as our rollout continues, and I wouldn't want
to have to manage site link bridges. The more I can let AD manage
itself,
the better. I may advise that the spec of firewall's we have on some sites
be upgraded, to allow a greater amount of tunnels, so we can more or less
make the network fully routed, and leave auto site link bridging enabled.

Just out of interest, do you know of any good documentation that
describes
how to correclty implement manual site link bridges?

Thanks for your time (again), it really is much appreciated.

Andrew

"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hi Herb,

Some sites are fully routed on an MPLS platform (no errors on these sites
DC's), some are connected via IPSec VPN Tunnels (some errors on these
sites
DC, depending on spec of firewall installed, regarding amount of support
VPN
tunnels). Some of the VPN sites that are connected to the MPLS network
via
the VPN Tunnels have low spec firewalls that do not have the ability to
have
more than a few tunnels setup.

These particular sites have a DC installed on each, but the DC's on these
sites have no direct route (e.g. not every DC is pingable from these
sites)
to every DC in the organisation, due to the spec of the firewalls, which
means in turn that we cannot have many VPN IPSec tunnels.

These limitations cause me to consider the network not fully
routed since the DCs cannot route between each other across
all possible (physical or logical) paths.

This is one of the main purposes for custom Site Link Bridge-grouping:
You put only those SitesLinks that would actually be usuable into the
same transitive SiteLinkBridge-group(s).

This means that each sites DCs can (IF necessary) use those double,
triple, etc., 'virtual SiteLinks' to bypass any intermediate sites with
down DC while still preferring those direct and lower cost explicit
links.

In ADS&S these VPN sites with DC's are defined, and have a site link back
to
the main 'Hub' AD site, where all AD replication goes through, and is
defined in ADS&S via site links back to every site (e.g. every AD
site is
defined in ADS&S, every AD site has the relevent site DC associated with
it,
and every AD site has a site link back to the 'Hub' AD site ONLY). So,
the
sites that are connected via VPN have only a site link back to the
Hub
sites
DC.

It seems to be just a simple Hub architecture with site links
back to, and only back to, the hub from each remote location.

Perfectly normal and usually reasonable.

Sorry if I worded the original question badly (had a long day), I
understand and appreciate the purpose of Auto site link bridging,

I didn't find it particularly difficult to understand your
description so don't worry about it. On the other hand,
I do make a practice of correcting misstatements or places
where the terminology or wording is not helping to solve
the problem someone is not facing.

As you explain below, that lack of routing is likely causing the
errors you see....

and as far
as I am aware the VPN sites AD servers event log errors are telling
me
that
there would be no replication possible to some AD sites, due to there
being
no direct route to these AD sites (please correct me if I'm wrong), but
will
these errors go away in time,

Probably not. Even if they do go away, they will return from
time to time as the situation (current status of your DCs and
networks) changes.

will they cause any harm (you answered that
already), can they be stopped?

(To recap: No serious harm from the errrors except to possibly
mask 'real' problems by filling up or cluttering your event logs
and by causing you to get in the habit of ignoring them -- this latter
is a separate psychological issue that we ALL suffer from when
we leave error messages for innocuous problems.)

I know not all sites can be contacted
directly by the VPN sites, and as such no such links are defined in ADS&S.

If you wanted to "fix it" you would turn off the default
full SiteLikeBridge-grouping, and only include those
SiteLinks (in each custom group) which are full routable
(for DC purposes).

IF you have simply that central-Hub and unconnected spoke
topology you would do LITTLE harm by just turning off the
SiteLink Bridging.

The downside would be that were the central (hub) DCs to
all go down WHILE the network and routing continued to function
then you would not replicate remote-to-remote without being
able to stage the replications through the hub.

For times when the network is non-functional (likely if ALL of the
DCs in the hub are down AND the routers live in the same physical
networks) then nothing would be lost since it would be all or nothing
anyway.

For networks where there are SOME paths "across" the hub (or
around, which you don't seem to have) then NEW "site link bridge-
groups" would allow those pairs of sites to replicate without involving
the central hub DCs.

You could also (while disabling the bridge-grouping) just put in
additional SiteLinks with higher costs and control it that way.
(This becomes complicated as the number of SiteLinks grows and
the KCC is usually better at calculating this dynamically for you,
but you are also free to just set your own links and turn off that
transitivity.)

If I'm making no sense please let me know. Thanks for your response

No, you are doing fine -- just ask anything specific that doesn't
make sense to you yet, or that you think of as you continue to
work your design.

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


"Andrew Story" <andrewDOTstoryATjameswalkerDOTbiz> wrote in message
Hello NG,

I have some sites connected to our main MPLS platform (fully
routed
network)
via VPN. Not all the VPN sites have physical connectivity to all the
other
sites, due to the amount of tunnels allowed due to the spec of the
firewalls
we are using.

Then presumably your Site Link follow ONLY the
Physical WAN links. (Other designes are technically
legal but seldom make sense.)

[Actually after reading your whole message below, you do NOT
have a fully "routable" network from the point of view of the DCs
-- those VPN firewalls which prevent the DCs from communcating
with each other make their traffic unroutable across such links.]

On the some of the VPN sites I have alot of errors in event
viewer
(Event
ID:1331 and 1556) advising that some other sites cannot be contacted.

We don't know your Site Links.

I
appreciate that some of the VPN sites cannot contact all the other
sites
directly due to the firewall specs,

Then they should have no direct Site Links, nor in general
are you going to remove this error COMPLETELY if you
allow for the default SiteLink Bridging (grouping of SiteLinks)
but most of the time those transitive "virtual SiteLinks" will
never be attempted.

and I don't want to have to remove auto
site link bridging and manually specify site link bridges for the
entire
domain. My question is, will these errors disappear in time, e.g. will
AD
simply 'give up' trying to contact these other sites?

No, but they are largely unimportant except for that fact
that such 'irrelevant' errors tend to mask real problems if
you get in the habit of just 'ignoring' them.

and if so, will it cause any issues?

Just the tendency to ignore real errors.

But you haven't explained WHY the DCs in unreachable sites
are making an attempt to actually CONTACT those other DCs.

In general, they should be using the "closest" site DCs until
(all of) the DCs in that site are down.

My suspicion is that you have either/both too many Site Links
(across non-existent, unroutable links) OR some of your DCs
are not properly placed within the correct site (in Sites and
Services) or similar DCs problems.



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