RE: AD Sites and Services
- From: "JoeJ" <JoeJ@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 30 Jun 2005 13:31:02 -0700
In my environement with undefined IP subnetts and 1 site; what will happen
to remote site users who normally authnticate across the WAN although they
may have a local DC if their WAN link went down? Does local DNS know enough
to direct them to the local DC even though the subnets are not defined?
Would the clients eventualy do a broadcast to find a DC?
"Paul Williams [MVP]" wrote:
> Site's server two main purposes:
>
> -- Replication schedules
> -- Traffic localisation
>
>
> If you don't configure subnets and associate these subnets with sites, or if
> you do configure subnets but associate them all with one site, then you are
> basically saying to AD: "this is one big, fast, inter-connected LAN-type
> network, where we don't need to worry about WAN-link utilisation because our
> links are fast enough".
>
> In this case, any DC is good for an intrasite replication partner and any DC
> is good for an authenticating DC, etc.
>
> If you have, for example, high-speed links, then you don't need to segragate
> your AD up into sites. As it can act as one big site. Microsoft originally
> defined a site as 10MB or higher. This doesn't have to be the case. If you
> had, for example, three or four remote offices that connected to a WAN
> backbone of say 4MB that might well be fine. Logon traffic is small;
> replication traffic is usually pretty small (but that does vary on DC/ GC,
> size, number of domains, number of changes, etc.), SYSVOL traffic and policy
> traffic are all quite small. Therefore a small number of machines on a 2MB
> line could be expanded into one site.
>
> I'll give you a real example. A customer of ours has a couple of offices in
> a major city. The WAN backbone is faster than the LAN :-D. Therefore, the
> three sites (in different buildings around the city) are all part of the same
> site. The subnets have been defined however, and therefore linked to the
> same site (the renamed default-first-site-name), as otherwise there's loads
> of informational Netlogon events generated.
>
> As another example, I worked for a mining company a couple of years back
> where we had offices up the mountains at the mines. The only lines we had in
> this instance were 64K ISDN. In this instance we had clearly defined sites,
> with a GC at each site, and replication intervals that only allowed
> replication in between 0800-1800 on weekdays at 3 hour intervals, and we had
> site link objects for each site and the main office, we disabled automatic
> bridging and manually defined bridgehead servers. This coerced the KCCs into
> a true hub and spoke layout, and we minimised cross network traffic
> completely. This worked fine, but wouldn't have without the use of sites as
> a localisation mechanism for the clients when authenticating and processing
> policy, and performing DNS lookups, etc. Local AV and SUS servers that
> synchronised in the nights helped too ;-)
>
> What I'm saying then is that it is down to your environemnt. If you have
> very fast links, you don't need sites. However I think it is worth defining
> all of the sites and subnets even so. At the least, define all subnets and
> add to one site just to keep the info's out of the event logs...
>
> --
> Paul Williams
> Microsoft MVP - Windows Server - Directory Services
> http://www.msresource.net | http://forums.msresource.net
>
.
- References:
- AD Sites and Services
- From: JoeJ
- RE: AD Sites and Services
- From: Paul Williams [MVP]
- AD Sites and Services
- Prev by Date: AD Sites and Services
- Next by Date: Migration path
- Previous by thread: RE: AD Sites and Services
- Next by thread: AD Sites and Services
- Index(es):
Relevant Pages
|
