Multiple Sites and Multiple DCs

[JJ]

I have 8 locations all around US - 2 of the sites have a DC and the other 6
have only 1. Link speed is T1 between all sites.

How many SITES in AD Sites and Services should I have for optimal design?
Can you guys give me some design tips or suggestions at least that would
clarify this for me?

Thank you!

 

[Cary Shultz [A.D. MVP]]

JJ,

This will probably turn out to be a long response from me do you might just
want to look at the first couple of paragraphs and then forget the rest! I
tend to babble on this topic!

Also, it might be nice to have an idea of the total number of
users/computers in each location as well as the OSes involved ( assuming
WIN2000 Server on the server-side, but what about on the client-side? Are
there any WIN9x or WINNT boxes? If so, you should consider installing the AD
Client on them ).

Also, what does your Exchange 2000 ( I know, I am assuming again ) look
like?

I would suggest that you have eight Sites. But this is still very early in
the information gathering stage for us. So far this is what I would
suggest. And I am sure that you mean that in two locations you have two DCs
and that in the six others have only one DC. I would also suggest that you
eventually place a second DC in each of the six locations where there is
currently only one. But, we do not have the number of users in those six
locations so one might be all that you can really justify! Example, if you
have 11 users in one of those locations you might be hard pressed to get the
funding for a second Domain Controller.

What do Sites allow us, the Admins, to do? Pretty much two things: control
Active Directory Replication and assist user logons. This is naturally a
bit oversimplified but pretty much sums it up.

There are two types of replication in Active Directory: Intrasite and
Intersite. In the locations where you have only one DC ( assuming that you
would create a Site for each of your eight locations ) you would not have
Intrasite Replication. There is only one DC in that Site so there is
obviously no other DCs with which to replicate. However, in the two Sites
where you do currently have the two DCs there is Intrasite Replication going
on!

Intersite Replication is the replication that happens between DCs in
different Sites. Now, how in the world does this happen? There is one DC
in each Site ( regardless of the number of DCs in that Site ) that acts as
the so-called Bridgehead Server ( or BHS ) that is the replication partner
with the BHSes from the other Sites. In Sites where there are multiple DCs
once the DC that acted as the BHS for that replication cycle gets the
updates from the other BHSes then Intrasite Replication happens ( as
scheduled ). So, eventually everyone is on the same page. The key word is
eventually. You might notice that if you were to create a user account
object in the Site where you are located that it takes awhile for that user
to be able to logon were that user in another Site. You are seeing the
effects of Intersite Replication. There is a very specific schedule for
this ( 180 minutes out-of-the-box, but you can play with this ).

Now, how does all of this stuff happen? What is going on under the hood?
There is a little gremlin called the KCC ( or Knowledge Consistency
Checker ) that is responsible for creating the Replication topology. Active
Directory replication is based on incoming connection objects. This is
important to know and to understand. If you have DC01 and DC02 there would
be two different connection objects needed to complete the ( as intended in
this example, anyway ) Intrasite Replication. There is a connection object
for DC01 - DC02 and there is a connection object for DC02 - DC01. The KCC
has a very powerful little buddy called the ISTG ( or Intersite Topology
Generator ) that does a lot of the dirty work for the KCC.

Now, and please excuse me if you know this already. There are three
partitions, or Naming Contexts, that comprise the Active Directory. These
are the Schema NC, the Configuration NC and the Domain NC. I might suggest
installing the Support Tools on all of your Domain Controllers and taking a
look at ADSIEdit. You will very clearly see these three NCs and what is
contained in each. The first two ( the Schema and the Configuration ) are
replicated to each and every Domain Controller throughout the entire Forest.
If you have only one Domain ( which it sounds like you have ) then this is
not as obvious to see when if you have multiple Domains / Trees. If you
were to add a child domain or if you were to add another Tree this would
become very obvious. The Domain NC is replicated to all of the DCs in each
respective Domain. Again, with only one Domain this is not as obvious. Say
that you added a child domain ( for whatever reason - so far we have not
heard anything that would lead us to suggest that....I mention this only
because a lot of people who have a lot of experience in WINNT 4.0 but not
too much with WIN2000 AD see multiple physical locations and go into 'find a
good name for each domain' mode ). You would see that the DCs in the parent
Domain would replicate that Domain NC while the DCs in the child Domain
would replicate that Domain NC. However, both Domains ( Parent and Child )
would replicated the Schema and Configurations NCs.

I would really suggest that you install the Support Tools on all of your
Domain Controllers. This is an awesome set of very useful tools. The
Support Tools can be found on the WIN2000 Service Pack CD or on the MS
Website ( they can also be found on the WIN2000 Server CD but those versions
have some known issues ). Take a look at the 'repadmin' tool. Use the
/showconn and the /showreps switch and you will see a whole lotta things.
These are the connection objects that I mentioned earlier. dcdiag and
netdiag as well as netdom and replmon and nltest will become your friend as
well. There are a lot of very nice tools included in this 'suite'.

Also, you might want to swing on over to Joe Richard's website (
http://www.joeware.net ) and take a look at some of the tools that he has
created. There are some really good ones in there.

I might also suggest that you take a look at ADModify. This is a nice
little utility that helps you to make the same change to multiple user
account objects. It is really helpful if you can not script. Here is the
link:

ftp://ftp.microsoft.com/PSS/Tools/Exchange%20Support%20Tools/ADModify/


One more finally suggestion would be for you to take a look at the
altools.exe set of utilities that will really help you out with account
lockouts. Here is the link for that:

http://www.microsoft.com/downloads/...9C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

HTH,

Cary

 

[JJ]

Cary, excellent summarization! Why can't books SIMPLIFY this subject in
this manner and just give us more meat as a reference! Do you have your own
BLOG on site with your "wordly" wisdoms and knowledge? =)

 

[Herb Martin]

Cary, excellent summarization! Why can't books SIMPLIFY this subject in
this manner and just give us more meat as a reference! Do you have your own
BLOG on site with your "wordly" wisdoms and knowledge? =)

Also you should make at least one (if not all) of the DCs
in each Site a GC.

A Global Catalog server is generally required to be available
in every site.

 

[Cary Shultz [A.D. MVP]]

Herb,

Thank you! I did forget the Global Catalog part in my response. I also
answered only part of the question in that I completely left off the second
part of what Sites do: assist users logon ( which, in part, is answered by
your response ).

Cary

 

[Cary Shultz [A.D. MVP]]

JJ,

Glad that I was able to help you. No, I do not have my own blog or web site
but I am working on that. Eventually I will.

Cary

 

[stuart]

Herb,

Thank you! I did forget the Global Catalog part in my response. I also
answered only part of the question in that I completely left off the second
part of what Sites do: assist users logon ( which, in part, is answered by
your response ).

Cary

Cary,

Would you create an AD site for each physical site, including the ones
that don't have domain controllers? I would normally only create an AD
site for a physical site if there is a domain controller present. I
would then link the subnets for the physical sites to the closest AD site.

I can't see the benefit of having an AD site if there is no domain
controller present??

Your thoughts..?

 

[Guest]

I can't see the benefit of having an AD site if there is no domain
controller present??

One of the benefits is that you can create multiple site-links with
differing costs, and the locator process will ensure that you access the
'closest' site with a DC.

One advantage of this, is that you can still somewhat control the DCs that
this machine uses in the event that the main site DC(s) cannot be accessed,
in that the locator will use the next lowest cost.

Obvisouly, a comms problem renders all of this redunant.

The alternative is to simply group the subnets into one site like you do.

I guess it's a matter of choice. But site-based service oriented
applications may prefer the DC-less site, e.g. SMS (2003) and possibly
Exchange...


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.

 

[Brian Desmond [MVP]]

I've foudn Inside Active Directory Second Edition to have a great discussion
of sites, replication, etc.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

 

[Brian Desmond [MVP]]

I''m not Cary but I'm going to chime in anyway:

Cary,

Would you create an AD site for each physical site, including the ones
that don't have domain controllers? I would normally only create an AD
site for a physical site if there is a domain controller present. I
would then link the subnets for the physical sites to the closest AD site.

I can't see the benefit of having an AD site if there is no domain
controller present??

Your thoughts..?

You may wish to create a site even if a DC is not present. Since you can
define site linsk between this site and other sites with difering costs,
clients in this site without a DC will attempt to find the least cost path
to a DC. If for example your network topology/routing allows clients at a
site with no DCs to only connect to another site, then putting the subnet in
the site which the remote site is connected to makes just as much sense.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

 

[stuartm]

Thanks Brian - that makes sense.

..

I''m not Cary but I'm going to chime in anyway:





You may wish to create a site even if a DC is not present. Since you can
define site linsk between this site and other sites with difering costs,
clients in this site without a DC will attempt to find the least cost path
to a DC. If for example your network topology/routing allows clients at a
site with no DCs to only connect to another site, then putting the subnet in
the site which the remote site is connected to makes just as much sense.

 

[Herb Martin]

Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

 

[ptwilliams]

Not just 2nd Ed. either. The first covers this in huge detail.


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


I've foudn Inside Active Directory Second Edition to have a great discussion
of sites, replication, etc.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

 

[ptwilliams]

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites, especially
if they have member servers that can be used for the 2003-equivalent of CAPs
and DPs.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

 

[Herb Martin]

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

Yes, that was one of the reason I indicated but you can also do this
by including the DC-less location in that nearest site (the one the
clients should use.)

I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites, especially
if they have member servers that can be used for the 2003-equivalent of CAPs
and DPs.

I too understand that SMS 2003 does (may?) include a feature/option
to use the AD sites so that would make a third service which respects
or uses sites: AD-DCs, DFS, and SMS.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.

One can hope.

My vote is for SMTP services that registers themself by site and a
change to Outlook and OE, etc, that would make the SMTP clients
SITE-AWARE of their nearest SMTP server.

Imagine how big a value this would be to both distributed
companies and those who frequently use a different ISP
while traveling....

--
Herb Martin

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

--
Herb Martin

.

at

a

 

[ptwilliams]

My vote is for SMTP services that registers themself by site and a change

to Outlook and OE, etc, that would make the SMTP clients SITE-AWARE of
their nearest SMTP server.

Imagine how big a value this would be to both distributed companies and
those who frequently use a different ISP
while traveling....

Yes, I can see the benefits and possibilities with this. It is a good idea,
and one that hopefully MS are working on...

I'm surprised as to how few actual apps use sites as of yet. I would have
thought more developers would have utilised this feature - as there could be
many benefits to gain from this...


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

Yes, that was one of the reason I indicated but you can also do this
by including the DC-less location in that nearest site (the one the
clients should use.)

I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites, especially
if they have member servers that can be used for the 2003-equivalent of CAPs
and DPs.

I too understand that SMS 2003 does (may?) include a feature/option
to use the AD sites so that would make a third service which respects
or uses sites: AD-DCs, DFS, and SMS.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.

One can hope.

My vote is for SMTP services that registers themself by site and a
change to Outlook and OE, etc, that would make the SMTP clients
SITE-AWARE of their nearest SMTP server.

Imagine how big a value this would be to both distributed
companies and those who frequently use a different ISP
while traveling....

--
Herb Martin

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

--
Herb Martin

.

at

a

 

[Herb Martin]

The problem with SMTP is that both clients and servers much
use the feature (servers register, clients resolve) so that only
someone like MS with leadership on both sides can initiate
this.

It's actually a pretty trivial change to both client and server.

--
Herb Martin

My vote is for SMTP services that registers themself by site and a change
to Outlook and OE, etc, that would make the SMTP clients SITE-AWARE of
their nearest SMTP server.

Imagine how big a value this would be to both distributed companies and
those who frequently use a different ISP
while traveling....

Yes, I can see the benefits and possibilities with this. It is a good idea,
and one that hopefully MS are working on...

I'm surprised as to how few actual apps use sites as of yet. I would have
thought more developers would have utilised this feature - as there could be
many benefits to gain from this...


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

Yes, that was one of the reason I indicated but you can also do this
by including the DC-less location in that nearest site (the one the
clients should use.)

I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites, especially
if they have member servers that can be used for the 2003-equivalent of CAPs
and DPs.

I too understand that SMS 2003 does (may?) include a feature/option
to use the AD sites so that would make a third service which respects
or uses sites: AD-DCs, DFS, and SMS.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.

One can hope.

My vote is for SMTP services that registers themself by site and a
change to Outlook and OE, etc, that would make the SMTP clients
SITE-AWARE of their nearest SMTP server.

Imagine how big a value this would be to both distributed
companies and those who frequently use a different ISP
while traveling....

--
Herb Martin

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

--
Herb Martin

.

Brian Desmond [MVP] wrote:
I''m not Cary but I'm going to chime in anyway:



Cary,

Would you create an AD site for each physical site, including the ones
that don't have domain controllers? I would normally only create an AD
site for a physical site if there is a domain controller present. I
would then link the subnets for the physical sites to the closest AD site.

I can't see the benefit of having an AD site if there is no domain
controller present??

Your thoughts..?


You may wish to create a site even if a DC is not present. Since you can
define site linsk between this site and other sites with difering costs,
clients in this site without a DC will attempt to find the least

cost
path

to a DC. If for example your network topology/routing allows clients

at

a
site with no DCs to only connect to another site, then putting the subnet in
the site which the remote site is connected to makes just as much sense.

 

[Brian Desmond [MVP]]

SMS is totally site aware supposedly. I've never actually used it but I hear
it works <g>.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

Yes, that was one of the reason I indicated but you can also do this
by including the DC-less location in that nearest site (the one the
clients should use.)

I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites, especially
if they have member servers that can be used for the 2003-equivalent of CAPs
and DPs.

I too understand that SMS 2003 does (may?) include a feature/option
to use the AD sites so that would make a third service which respects
or uses sites: AD-DCs, DFS, and SMS.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.

One can hope.

My vote is for SMTP services that registers themself by site and a
change to Outlook and OE, etc, that would make the SMTP clients
SITE-AWARE of their nearest SMTP server.

Imagine how big a value this would be to both distributed
companies and those who frequently use a different ISP
while traveling....

--
Herb Martin

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

--
Herb Martin

.

Brian Desmond [MVP] wrote:
I''m not Cary but I'm going to chime in anyway:



Cary,

Would you create an AD site for each physical site, including the ones
that don't have domain controllers? I would normally only create an AD
site for a physical site if there is a domain controller present. I
would then link the subnets for the physical sites to the closest AD site.

I can't see the benefit of having an AD site if there is no domain
controller present??

Your thoughts..?


You may wish to create a site even if a DC is not present. Since you can
define site linsk between this site and other sites with difering costs,
clients in this site without a DC will attempt to find the least

cost
path

to a DC. If for example your network topology/routing allows clients

at

a
site with no DCs to only connect to another site, then putting the subnet in
the site which the remote site is connected to makes just as much sense.

 

[Herb Martin]

SMS is totally site aware supposedly. I've never actually used it but I hear
it works <g>.

SMS sites have long been available and while similar in
concept and function to AD sites they have been completely
separate in past versions.

I understand that SMS 2003 amends this (at least as an option)
but I haven't checked it personally.

Older versions used distinct sites.

--
Herb Martin

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

Yes, that was one of the reason I indicated but you can also do this
by including the DC-less location in that nearest site (the one the
clients should use.)

I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites, especially
if they have member servers that can be used for the 2003-equivalent

of
CAPs

and DPs.

I too understand that SMS 2003 does (may?) include a feature/option
to use the AD sites so that would make a third service which respects
or uses sites: AD-DCs, DFS, and SMS.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.

One can hope.

My vote is for SMTP services that registers themself by site and a
change to Outlook and OE, etc, that would make the SMTP clients
SITE-AWARE of their nearest SMTP server.

Imagine how big a value this would be to both distributed
companies and those who frequently use a different ISP
while traveling....

--
Herb Martin

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net





Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

--
Herb Martin



.

Brian Desmond [MVP] wrote:
I''m not Cary but I'm going to chime in anyway:



Cary,

Would you create an AD site for each physical site, including the ones
that don't have domain controllers? I would normally only create

an

AD you
can clients
at

 

[Brian Desmond [MVP]]

Yeah. I was trying ot say that it's AD site aware in the 2003 version.

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

SMS is totally site aware supposedly. I've never actually used it but I hear
it works <g>.

SMS sites have long been available and while similar in
concept and function to AD sites they have been completely
separate in past versions.

I understand that SMS 2003 amends this (at least as an option)
but I haven't checked it personally.

Older versions used distinct sites.

--
Herb Martin

--
--
Brian Desmond
Windows Server MVP
(e-mail address removed)12.il.us

Http://www.briandesmond.com

Yes from a replication perspective it's irrelevant, but the DNS Locator
algorithm uses site link costs when ascertaining the closest site.
Therefore, in a scenario with a DC-less site with two site links the
lowest
cost link would be used for authentication. Thus, you can semi-force
clients at DC-less sites to use DCs at specific sites.

Yes, that was one of the reason I indicated but you can also do this
by including the DC-less location in that nearest site (the one the
clients should use.)


I would assume, although we've not upgraded yet so can't be sure, that
AD-Integrated SMS 2003 would make a lot of use of DC-less sites,
especially
if they have member servers that can be used for the 2003-equivalent of
CAPs
and DPs.

I too understand that SMS 2003 does (may?) include a feature/option
to use the AD sites so that would make a third service which respects
or uses sites: AD-DCs, DFS, and SMS.

I would also go as far to say that as more and more software becomes
AD-aware, we'll have more reasons for defining sites - for the publication
of directory services services, and thus traffic localisation, etc.

One can hope.

My vote is for SMTP services that registers themself by site and a
change to Outlook and OE, etc, that would make the SMTP clients
SITE-AWARE of their nearest SMTP server.

Imagine how big a value this would be to both distributed
companies and those who frequently use a different ISP
while traveling....

--
Herb Martin




--

Paul Williams

http://www.msresource.net
http://forums.msresource.net





Thanks Brian - that makes sense.

Actually the value of a DC-less site to define costs is pretty
doubtful -- since all the KCCs-DCs in the actual sites will
just use the lowest costs anyway and this site will be irrelevant
to replication except for the sum of the costs -- one might as
well just put in the direct Site Link with the sum.

[An exeption might exist for a central-hub site with no DCs
that is connected to many other sites, but that is a case where
it is very unlikely the location would be without DCs by
design.]

The main reason for creating Sites is to control DC replication.

(Or other servers that use sites -- right now, I think that is only
DFS in addition to AD.)

The seconary reason is to control which DCs (nearest) sites
will be preferred by the clients when connnecting to a DC
off site -- here the costs do matter, since the clients will prefer
the "closest" site DCs (least cost.)

An alternative if the network configuration is simple is to
just include the DC-location in the "nearest" site.

A third reason for creating such sites is if you intend to add the
DCs (sooner or later.)

There is nothing really wrong with creating such sites for SMALL
networks, but as the number of sites grows (dozens to hundreds)
you are causing more work for the KCC in most cases (there are
other ways to reduce this and it's not quite so bad in Win2003.)

Somewhere around 300 sites represents a practical maximum for
Win2000 domains/forests unless you take special care with
Site Link Bridging or some such trick.

FYI: A Site Link Bridge is somewhat misnamed and will better
be thought of as a "Site Link GROUP", since the practical effect of
these is to "Group siteslinks into a transitive group", and to separate
them -- i.e., non-transitive -- from other Sites not in the same
Site Link Bridge-Group.

--
Herb Martin



.

Brian Desmond [MVP] wrote:
I''m not Cary but I'm going to chime in anyway:



Cary,

Would you create an AD site for each physical site, including

the
ones

that don't have domain controllers? I would normally only create

an

AD
site for a physical site if there is a domain controller

present.

I

closest

AD