ED said:
I've come accrose an online session with a title of
(Active Direcotry Branch Office Guide - Level 200) that
can be found in the following link:
http://www.microsoft.com/technet/community/events/ad/tnt02
.mspx
the presenter highlited a conepts of Disable AutoSite
Coverage (registration) of the Child domain with the
Parent domain. where and how this option can be done?
Hi Ed,
AutoSiteCoverage is enabled by default and allows a DC to register SRV
records for both its home site and also adjacent "DC-less" sites.
In a large branch office environment with hundreds of sites AutoSite
coverage can result in a huge amount of SRV records being registered in DNS
(and updated every hour by default). There is a formula for calculating the
amount of records but I won't bore you with the gory details
I'm jjust
pointing out that AutoSiteCoverage could result in a huge amount of SRV
records in DNS and increased network traffic in updating these records.
In the Branch Office deployment guide Microsoft recommends that
AutoSiteCoverage be disabled on all DCs (both hub and branch). If you wish
you can optimize Site Coverage by specifying which Sites particular DCs
should cover; I won't go into this (lest my reply becomes War and Peace) but
I have used it in my own deployment to optimize the authentication topology
in certain areas.
You disable AutoSiteCoverage by setting the following registry key: on W2K
DCs
HK:LM\CCS\Services\Netlogon\Parameters\AutoSiteCoverage (0 = disable, 1 =
enable)
If you have Windows 2003 DCs you can set this by a Group Policy:
Computer Configuration - Administration Templates - System - Netlogon -
AutositeCoverage (Enabled/Disabled)
In a typical Branch Office Deployment you would want to set up your
authentication topology such that users in remote sites authenticate via
local domain controllers, with a fall back to the domain controllers in the
hub site (usually a Data Centre) should the local DCs fail. With AD's
default authentication topology, clients in remote branches may well be
validated by DCs in other remote branches should the local DC(s) fail. This
is course would be inefficient as branch offiice network topologies are
typically hub and spoke, and a fallback to the hub (data centre) would be
desirable.
You achieve this by tailoring the registration of "generic" SRV records. AD
clients use "site specific" SRV records to locate DCs in their own site and
fall back to generic SRV records when they cannot find a DC in their own
site.
By default DCs register the full complement of SRV records (ie both site
specific and generic SRV records). You modify this default behaviour such
that DCs in spoke sites register only site specific SRV records, while DCs
in the hub site register the full complement (ie both site specfic and
generic). With this configuration AD clients in spoke sites will use their
local DC if available by way of its site specific SRV records. If the local
DC should become unavailable the clients will fall back to DCs in the hub as
these DCs will be the only ones in the forest advertising generic SRV
records. When the local DC is reinstated the clients will use it when they
are next rebooted.
You control the registration of SRV records by following registry key on W2K
domain controllers:
HKLM\CCS\Services\Netlogon\Parameters\DnsAvoidRegisterRecords = list of
mnemonics
With W2003 domain controllers you can use a Group Policy:
Computer Configuration - Administrative Templates - System - Netlogon - DNS
records not registered by the Domain Controllers = list of mnemonics
The exact list of mnemonics is given in the Branch Office Deployment guide.
If your branch office network is particularly complex with multiple hubs,
you can go further and combine the above with the use of explicit
SiteCoverage and SRV record priorities to implement multiple levels of
fallback eg local domain controllers -> domain controllers in HUB1 -> domain
controllers in HUB2. In practice you won't have to go to this far
another thing, i'm currently installing a new child
domain controller in a remote office where the link is
not reliable. I've already installed the Active directory
Physically at the parent domain. and then i moved the
server physically to the child domain location. i've
changed the needed configuration such an ip , dns and
gateway. i can ping and resolve all names in my parnet
domain. but when the link is down , my users in the child
domain cannot login any more even after i assigned the
server in my child domain to be a GC server. i need to
know if i've done the right configuration or not?! what
else i should do ?
Hmmm this is strange.Is there a local DNS server at your remote office? If
the DNS is centralised at your hub site I would expect you to have problems
if the link goes down as AD clients depend on DNS for the DC locator
process. Assuming there is a local DNS server and the DC is a GC I would
expect logins (to the child domain) to succeed if the link goes down. Are
there any error messages of note in the event viewer of the workstations?
Best Wishes,
