2. SRV record registration
Domain controllers advertise themselves by registering service (SRV)records with DNS servers so that clients can find DCs that offers services related to Active directory. When a client needs the services of a DC ( for example, to authenticate to the domain or join a domain), it queries a DNS server for the SRV records for all DCs. It also queries for SRV records for DCs in its own site and use these records first, if they exist, so that authentication and other procedures don’t travel across a WAN.
The Netlogon service on the DC handles registration of SRV records for the lightweight Directory Access Protocol(LDAP) and Kerberos services. These records are stored on the DNS server in folders in a subdomain named _msdcs located in the zone for the DC’s domain. A folder for each site is maintained so that determining which sites offers these services is easier.
For example, a DC in site12 for domain frankfu.com registers SRV records under forward lookup zones in _msdcs.frankfu.com\dc\_sites\site12\_tcp
and _msdcs.frankfu.com\dc\_tcp
If a DC fails to register its SRV records, you can force it to attempt to register the records by stopping and starting the Netlogon service in the Service MMC or with one of the following commands:
net stop netlogon
, then typenet start netlogon
.- At powershell,
restart-service -Name netlogon
Working with Automatic site coverage
When a site doesn’t have a DC, other DCs in other sites in the domain can provide the services clients need.
Automatic site coverage is a feature in which each DC advertises itself by registering SRV records in DNS in sites that don’t have a DC if the advertising DC has the lowest cost connection to the site.
Generally, you want automatic site coverage enabled for efficient domain operation. However, if you have a Windows Server 2003 DC in your domain and RODCs in any sites, you might want to disable this feature on Windows Server 2003 servers. The reason is that Read-only domain controllers (RODCs) are a new feature of Active Directory Domain Services (AD DS) in Windows Server 2008, therefore, a Windows Server 2003 DC doen’t recognize that an RODC is providing services for the site because Windows Server 2003 doesn’t consider RODCs when evaluating site coverage. There are a few solutions to the problem:
- Install the RODC copatibility pack on Windows server 2003 DCs. This is the preferred.
https://support.microsoft.com/en-au/kb/944043 - Make sure only windows 2008 or later DCs in the sites closest to any site with an RODC
- Disable automatic site coverage on Windows Server 2003 DCs:
Using a graphical user interface
-
Run regedit.exe from the command line or Start Run.
-
Expand HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Netlogon Parameters.
-
Right-click on Parameters and select New DWORD Value.
-
For the name, enter AutoSiteCoverage.
-
Double-click on the new value, enter 0 under Value data, and click OK.
Using a command-line interface
> reg add HKLM\System\CurrentControlSet\Services\Netlogon\Parameters /v[RETURN]
AutoSiteCoverage /t REG_DWORD /d 0
3. Moving DC between Sites
When a windows server is first promoted to a DC, it’s assigned to a site based on its IP address settings, or you can choose the site to install the DC during the promotion process.
If you change the DC’s IP subnet address or change the subnet for the sites, the DC are not moved to a different site automatically, you need to move it manually:
- verify that the target site is created and has the right subnets assigned to it.
- Change the DC’s IP address, subnet mask, and default gateway as needed for the target site.
- If the DC is used as a DNS forwarder, make the necessary changes in the forwarder configuration on other DNS servers
- If the DC hosts a delegated DNS zone, update the NS record in the parent domain’s DNS zone to the new IP address of the DC
- If the DC being moved is a preferred bridgehead server, you must make the necessary adjustments in both the current site and the target site. In most cases, it’s better to configure the DC so that it’s not a preferred bridgehead server and ensure that no DCs in the current and target site are configured as bridgehead servers. By doing so, the ISTG(inter-site topology generator) assigns bridgehead servers automatically as needed when the DC is moved. After the move, you can then assign the preferred bridgehead servers again.
- Move the server to the target site in AD sites and services. If necessary, physically move the server to the new site location.
- In DNS manager, verify that SRV records are created for the DC in the target site folder. It could take up to an hour for these records to be created.
4. Folders to support Active Directory:
• NTDS—By default, this folder is located in %systemroot% (usually C:\Windows). It contains the following files:
- ntds.dit: The main Active Directory database.
- edb.log: Holds a log of Active Directory transactions (changes). If Active Directory is shut down unexpectedly, changes that didn’t get fully written to the database can be redone by using the data in this file to commit the changes. This file can grow to a maxi- mum of 10 MB, and then new log files are created, named edb00001.log, edb00002. log, and so forth.
- edb.chk: Stores information about the last committed transaction; used with edb.log to determine which transactions still need to be written to the database.
- edbres00001.jrs: A placeholder file that simply takes up disk space. If the volume on which ntds.dit is stored fills up, this file and another named edbres00002.jrs are deleted to free up disk space so that pending transactions can be committed to the data- base. After the changes are made, the DC is shut down, and the administrator must make disk space available before Active Directory can operate again.
• SYSVOL—By default, this folder is located in %systemroot%. It contains group policy templates, logon/logoff scripts, and DFS synchronization data.
5. Related tools:
Active Directory Replication Status Tool: https://www.microsoft.com/en-us/download/confirmation.aspx?id=30005
Problems:
Problem: “AD Replication error 1722: The RPC server is unavailable”
Verify the startup value and service status for the is correct for the Remote Procedure Call (RPC), Remote Procedure Call (RPC) Locator and Kerberos Key Distribution Center.
https://support.microsoft.com/en-au/kb/2102154
<previous part(part1)>