Global Catalog

No it doesnt have to be a GC but it will cut down on WAN traffic if it is, just make sure you create a new "site" in the sites and services snap in for it to live in :)

Explain how it will cut down on WAN traffic for me.. seems like it would increase it with the replication.

Also why is the new site needed?

Thanks
KAH

When a user at the remote site log on to his computer, the logon goes to the nearest DC based on the site topology. However, for security reasons, if the DC is not a GC it will relay the logon request to the nearest DC. If you want to restrict WAN traffic for logon processes, you need to either have a local GC, or with W2003 configure the remote DC to use Universal Group Membership Caching. If your WAN link is slow and/or your remote site has a lot of users, or you're using an application that uses GC heavily such as Exchange, configure the remote DC as a GC.

http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/gc_togc.asp
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/gc_when.asp

Also what is the purpose of the subnets container? I have 45 subnets in my network but I do not have any defined in the site..... what will this accomplish?

The subnets define your site.  You should lump all LAN connected subnets together....and make these part of the same site.

New York Site
New York Subnets
10.10.2.0
10.10.3.0
10.10.4.0
New York DC

California Site
California Subnets
20.20.2.0
20.20.3.0
20.20.4.0
California DC

late

Step-by-Step Guide to Active Directory Sites and Services
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/adsrv.mspx

Well I have subnets around the country... but all DC is in one site right now.... I am setting up the alternate site for disaster scenario.
So..

Primary Site is Nashville, TN
10.1.1.0/24 and 10.102.0.0/23

There are 45 others around the country... and the DR site will be in Cleveland, TN
subnet 10.5.1.0/24

So all the other subnets where do I define them?  Does my question make sense?

Covering DC-less Sites
One of the best ways to reduce the complexity and increase the manageability of your AD deployment is to reduce the number of DCs. Each DC you add to your forest increases your hardware, software, and operating costs, not to mention replication latency and troubleshooting time. Satellite offices with good network connectivity and only a few users are great candidates to be DC-less sites.

You might ask, "Why not just add satellite office subnets to the main office site?" This question makes a lot of sense from an AD perspective: Clients would authenticate to DCs in the main office and, because no DC exists at the remote office, you'd have no replication-topology problems to deal with. But AD isn't the only application that relies on the proper definition of sites. For example, Microsoft Dfs, the technology upon which File Replication Service (FRS) is based, locates nearby servers according to AD site definitions. If the satellite office has a Dfs server, you wouldn't want to collapse a satellite site into the main office site.

Suppose you have a small branch office with 30 employees and a reliable T1 connection to the main office. You have no reason to put a DC in the branch location because the network can easily support the authentication and lookup traffic that 30 workstations generate. But which DC will the branch-office clients use to authenticate? The answer lies in the notion of site coverage. DCs publish both generic and site-specific SRV records so that clients can find a DC anywhere in the domain or in a specific site. But by default, DCs also publish site-specific SRV records for nearby sites that have no DCs. This way, a client can use a site-specific DNS query to locate a DC even when no DCs exist in the client's site.

The rules for determining which DC will cover a DC-less site are fairly straightforward. When each DC starts up, it looks in its copy of AD for any DC-less sites. For each DC-less site, the DC determines whether its own site is closest to the DC-less site, which the site-link cost information in AD determines. If the DC's site is closest, the DC publishes site-specific SRV records for that DC-less site. If the DC determines that more than one site shares the lowest site-link cost value, the DC compares the number of DCs in its site with the number of DCs in the other sites. If the DC's site has the most DCs, the DC publishes site-specific SRV records for the DC-less site. Having the site with the most DCs cover the DC-less site provides more DCs to share the load of the DC-less site. If the sites have the same number of DCs, the site that comes first alphabetically covers the DC-less site.





Having all the DCs in a covering site cover the DC-less site has a downside. Each DC in the covering site publishes SRV records for the DC-less site, so a covering site with 5 DCs and 2 GCs will generate an additional 32 SRV records (4 site-specific SRV records per DC and an additional 2 records for each DC that's also a GC). If you have a hub-and-spoke topology with 25 DC-less satellite sites connected to one hub, and you have 25 DCs and 7 GCs in the hub, you'll get a whopping 3550 additional SRV records per domain.

Now consider that each DC is busy republishing its SRV records every hour. (This schedule is the default in Win2K; DCs republish their SRV records every 15 minutes in Windows Server 2003.) You can imagine the kind of network traffic these site-coverage SRV records will generate. And if you have AD-integrated DNS zones, you'll be faced with a significant amount of additional replication traffic going to each DC in the domain. Furthermore, AD stores SRV records with the same name in a multivalued attribute of one AD object. Because of attribute size limitations, AD-integrated zones can handle only about 800 SRV records with the same name. A large branch office could easily exceed this limit.

Thankfully, Win2K Service Pack 2 (SP2) and later provide a way to control site coverage through registry settings. First, you can disable automatic site coverage on the DC. To do so, set the system's HKEY_LOCAL_MACHINE\SYSTEM\CurrentCon-trolSet\Services\Netlogon\Parameters registry subkey's AutoSiteCoverage value to 0. Second, you can explicitly name the sites that a DC will cover. To do so, set the system's HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters subkey's SiteCoverage value to the list of sites to cover (use the sites' relative distinguished names—RDNs—separated by spaces). Setting this value forces the DC to publish SRV records for the named sites, whether or not those sites already contain DCs. You can set the subkey's GcSiteCoverage value in the same way to control the publication of site-specific GC locator records. You can use these registry settings to assign specific DCs in a hub site to service authentications from DC-less satellite sites. This process reduces the number of SRV records added to DNS and makes the system more manageable.

You have one other option to reduce the number of DNS records in your environment. Each DC that hosts an AD-integrated DNS zone publishes a Name Server (NS) record for the domain. DNS uses this record to find authoritative name servers for the zone. If you have many DCs in your domain, you'll get many NS records. To prevent the DNS service from publishing its NS record, set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters registry subkey's DisableNSRecordsAutoCreation value to 1.

The effect of disabling the publication of NS records is subtle. When a server receives a direct query (e.g., from a client that lists the server as the primary resolver), its DNS service properly resolves names in the zone. But because no NS record exists for the server, other DNS servers, processing recursive queries, won't identify the server as a name server for the domain and won't pass queries to it. For more information about this process, see the Microsoft article "Problems with Many Domain Controllers with Active Directory Integrated DNS Zones" (http://support.microsoft.com/?kbid=267855).

http://www.winnetmag.com/Articles/Print.cfm?ArticleID=37935

Thank you for this information... it is very thorough... but I dont think it addresses where the subnets will go.

I have three DCs.. two in Nashville and one that will be in Cleveland.  There are 45 other subnets.... no dcs for them... they are autheniticating to the DCs in Nashville right now... but I need the Cleveland one setup as DR..... perhaps I am missing something.

If your non-server sites are using the main site, then associate the non-server site subnet range to the main site.  In this instance, the Site and Subnet information will only get used for logon DC, there is nothing to replicate with.

Got it...

but in the event that the primary site went down the other can still be used right?

Also
"there is nothing to replicate with."

Dont follow that statement... can you clarify?

Thanks again

Every site that you define should have a DC.  If you have LAN subnets that don't have a local DC, you do not need to create a site or a subnet.

"Every site should have a domain controller, and most sites should aslo have a GC server.  This means that if you are trying to decide whether to create a site for a company location with a small number of users and a slow network connection to other compnay locations....the question is really whether you want to put a domain controller into that site."

Leave subnets that don't have local DC's, undefined.  Only define sites that have DC's.

Thanks NJ*

Your thoughts conflict with Netman66... Netman can you clarify for me?
 
Comment from Netman66  
"If your non-server sites are using the main site, then associate the non-server site subnet range to the main site."

Of course...you could also use Site Links and/or Site Link Bridging:

Here is a design article to help you understand Sites:

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbd_topo_overview.asp

Oops..didn't mean to confuse you - and I seem to have done just that.

You can associate subnets to a Site - any subnet - regardless if the subnets are remote or not.  I suppose this is where I wasn't very clear.  These "physical" sites
have no DC, but they belong to an AD Site that does - so, that being said, there is no replication to these non-server sites because there is no DC.


If you leave "physical" sites undefined in terms of subnets, then they belong to the Default-First-Site-Name (or whatever you renamed it to) by default.  If this happens to be the main office that has a DC, great.  If not, then you will need to somehow associate them with an AD site that has a DC.

Geez, all the "site" terms is enough to confuse anyone! :o)

Ok... well here is my next question.  If I do not define the subnets.... for the locations with no DCs.. then they use the first site.. but if the first site say burns to the ground in a fire... CAN they use the second site?  Provided of course there is a physical and logical connection there?

I am basically trying to figure out if I need to define the subnets for all these sites that have no dcs... and if so and the site they are defined in the DC goes down then are they up a creek?

Thanks

They're supposed to - yes.  Either the client will request another GC or it should use existing site links.

Try it without.  Then remove connectivity to the first site.  Attempt to login to a client PC.  You'll know quick enough.

The clients will use DNS SVR records to find the available DC's.  Your clients will be able to find additional ways to authenticate even if the main site crashes.  

It is my opinion that you do not have to create sites in locations where DC's do not exist.  Only define your sites if DC's exist in them.

For you disaster recovery site, I would install a DC and also make this server a global catalog server.  In addition, I would make this server a working DNS server (all clients should use this one as an alternate...just in case the main site dies).  I would also install any other services (WINS/Print/DHCP/etc) to make your environment more redundant.

I never said create a site where there is no server.....I said create a subnet for the physical site.....

Thank you both for your input.
I am going to test with two sites.  The only subnets I am going to define are the subnets that are physically located at those sites... those that have local DCs.

Thank you again for your help on this issue.

point change for even spilt