How Domain controllers are located in windows

2

How do servers locate a domain controller in a Network?

One of the first major tasks a domain member computer has to do when it starts is to locate a domain controller. Generally, this task requires the use of a Domain Name System (DNS) server, which contains records for each domain controller in the domain, and the Locator, a remote procedure call to the computer’s local Netlogon service.

Starting Up

When the computer starts, its Netlogon service starts automatically (in the default configuration). Th is service implements the DsGetDcName application programming interface (API), which is used to locate a domain controller.

The computer  begins  by collecting  a number  of pieces of information that  will be used  to  locate a domain controller. This information includes the client’s local IP address, which is used to determine the client’s Active Directory site membership, the desired domain name, and a DNS server address.

Finding the Domain Controllers

Netlogon then queries the configured DNS server. Netlogon retrieves the service resource (SRV) records and host (A) records from DNS that correspond to the domain controllers for the desired domain. The general form for the queried SRV records is _service._protocol.domainname, where service is the domain service, protocol is the TCP/IP protocol, and domainname is the desired Active Directory fully qualified domain name (FQDN). For example, because Active Directory is a Lightweight Directory Access Protocol (LDAP)-compliant directory service,  clients query for  _ldap._tcp.domainname  (or  _ldap._tcp.dc._msdcs.domainname when  locating  the nearest domain controller).

Each domain controller in a domain will register its host name with the SRV record, so the client’s query results will be a list of domain controller host names. The client also retrieves the associated A records, providing the client with the IP address of every domain controller in the domain. The client then sends an LDAP search query,  via  the  User  Datagram  Protocol  (UDP),  to  each  domain  controller.  Each  domain  controller  then responds, indicating that it is operational. The Netlogon service caches all of this information so that finding a domain controller in the future won’t require a repeat of this initial process. Instead, the service can simply refer to its cache to find another domain controller.

Selecting a Domain Controller

After the client locates a domain controller, the client uses LDAP to access Active Directory on a domain controller, preferably one in the client’s own subnet. The domain contro ller uses the client’s IP address to identify the client’s Active Directory site. If the domain controller is not in the closest site, then the domain controller returns the name of the client’s site, and the client tries to find a domain controller in tha t site by querying DNS. If the client has already attempted to find a domain controller in that site, then the client will continue using the current, nonoptima domain controller. Once the client finds a domain controller it likes, it caches that domain controller’s information, and the client will continue to use that domain controller for future contacts (unless the domain controller becomes unavailable).

For more details on troubleshooting please refer below KB article

http://support.microsoft.com/kb/247811

 

For more article updates, videos and posters join our official page in Facebook

Facebook Page: https://www.facebook.com/ServerGeeks

Web Site: https://servergeeks.wordpress.com/

Video Channel: https://www.youtube.com/user/Habibmvp

 

Tools to Troubleshoot DC issues

2


Tools to Troubleshoot DC issues

DCDIAG

DCDIAG analyzes the state of domain controllers in a forest or enterprise and reports any problems to help in troubleshooting.

  1. Preparing to install or migrate to Exchange new version
  2. Checking FSMO roles.
  3. Troubleshooting Group Policy.
  4. Investigating Active Directory not replicating frssysvol error.
  5. Running down Kerberos authentication problems.
  6. Resetting the Directory Service Administrator’s password.
  7. Fixing servers Service Principle Name (SPN) error.
  8. Other DC issues

Example: dcdiag.exe /V /D /C /E > c:\dcdiag.log

DCDIAG tool article http://technet.microsoft.com/en-us/library/cc731968(v=ws.10).aspx

REPADMIN

Repadmin.exe is a Microsoft Windows 2000 Resource Kit tool that is available in the Support Tools folder on the Windows 2000 CD-ROM. It is a command-line interface to Active Directory replication. This tool provides a powerful interface into the inner workings of Active Directory replication, and is useful for troubleshooting Active Directory replication problems.

Example: repadmin.exe /showrepl dc* /verbose /all /intersite > c:\repl.txt

RepAdmin tool article http://technet.microsoft.com/en-us/library/cc770963(v=ws.10).aspx

NETDIAG

This command-line diagnostic tool helps to isolate networking and connectivity problems by performing a series of tests to determine the state of your network client. These tests and the key network status information they expose give network administrators and support personnel a more direct means of identifying and isolating network problems. Moreover, because this tool does not require parameters or switches to be specified, support personnel and network administrators can focus on analyzing the output rather than on training users how to use the tool.

  1. Installing Exchange and you wish to check that you can connect to other servers.
  2. Checking VPN network tunnels on the WAN.
  3. DNS problems.  Computers cannot ‘see’ their domain controller on the LAN.
  4. A quick check on hotfixes.
  5. Check the Network Card Bindings from the command prompt.
  6. You are having problems with IPSEC.
  7. Winsock corruption, wrong version incompatibilities.
  8. NetDiag checks that Domain Controllers are all able to ‘speak’ LDAP.

 

Example: netdiag.exe /v > c:\netdiag.log

Note: This command need to be run on each DC of the domain.

NetDiag tool article http://technet.microsoft.com/en-us/library/cc731434(v=ws.10).aspx

Active Directory Database and Log Files

3



Active Directory files and their functions




Ntds.dit

Ntds.dit is the main AD database file. NTDS stands for NT Directory Services. The DIT stands for Directory Information Tree. The Ntds.dit file on a particular domain controller contains all naming contexts hosted by that domain controller, including the Configuration and Schema naming contexts. A Global Catalog server stores the partial naming context replicas in the Ntds.dit right along with the full Domain naming context for its domain.


Edb.log

Edb.log is a transaction log. Any changes made to objects in Active Directory are first saved to a transaction log. During non-peak times in CPU activity, the database engine commits the transactions into the main Ntds.dit database. This ensures that the database can be recovered in the event of a system crash. Entries that have not been committed to Ntds.dit are kept in memory to improve performance. Transaction log files used by the ESE (Extensible Storage Engine is an Indexed Sequential Access Method (ISAM) data storage technology from Microsoft. ESE is the core of Microsoft Exchange Server and Active Directory.) engine are always 10MB.


Edbxxxxx.log

These are auxiliary transaction logs used to store changes if the main Edb.log file gets full before it can be flushed to Ntds.dit. The xxxxx stands for a sequential number in hex. When the Edb.log file fills up, an Edbtemp.log file is opened. The original Edb.log file is renamed to Edb00001.log, and Edbtemp.log is renamed to Edb.log file, and the process starts over again. Excess log files are deleted after they have been committed. You may see more than one Edbxxxxx.log file if a busy domain controller has many updates pending.


Edb.chk

Edb.chk is a checkpoint file. It is used by the transaction logging system to mark the point at which updates are transferred from the log files to Ntds.dit. As transactions are committed, the checkpoint moves forward in the Edb.chk file. If the system terminates abnormally, the pointer tells the system how far along a given set of commits had progressed before the termination.


Res1.log and Res2.log

Res1.log and Res2.log are reserve log files. If the hard drive fills to capacity just as the system is attempting to create an Edbxxxxx.log file, the space reserved by the Res log files is used. The system then puts a dire warning on the screen prompting you to take action to free up disk space quickly before Active Directory gets corrupted. You should never let a volume containing Active Directory files get even close to being full. File fragmentation is a big performance thief, and fragmentation increases exponentially as free space diminishes. Also, you may run into problems as you run out of drive space with online database defragmentation (compaction). This can cause Active Directory to stop working if the indexes cannot be rebuilt.


Temp.edb

This is a scratch pad used to store information about in-progress transactions and to hold pages pulled out of Ntds.dit during compaction.


Schema.ini

This file is used to initialize the Ntds.dit during the initial promotion of a domain controller. It is not used after that has been accomplished