Posts Tagged ‘Server 2008’

Introduction

A global catalog server is a domain controller that stores two forest-wide partitions, schema and configuration, a read/write copy of the partition from its own domain, and also a partial replica of all other domain partitions in the forest. These partial replicas contain a read-only subset of the information in each domain partition.

 

How does replication affect the global catalog server?

When a new domain is added to a forest, the information about the new domain is stored in the configuration partition, which is replicated to all domain controllers, including global catalog servers, through normal forest-wide replication. Then each global catalog server becomes a partial replica of the new domain by contacting a domain controller for that domain and obtaining the partial replica information. The configuration partition also contains a list of all global catalog servers in the forest and provides this information to the domain controllers. Global catalog servers register special DNS records in the DNS zone that correspond to the Forest Root domain. These records, which are registered only in the Forest Root DNS zone, help clients and servers locate global catalog servers throughout the forest.

Advertisement

Introduction

When you add domain controllers to a site, Active Directory uses the Knowledge Consistency Checker (KCC) to establish a replication path between domain controllers.

 

What is Knowledge Consistency Checker?

The KCC is a built-in process that runs on each domain controller and generates the replication topology for all directory partitions contained on that domain controller. The KCC runs at specified intervals (every 15 minutes by default) and designates replication routes between domain controllers that are the most favorable connections available at the time.

 

How KCC works?

To automatically generate a replication topology, the KCC evaluates information in the configuration partition on sites, the cost of sending data between these sites, any existing connection objects, and the replication protocols that can be used between the sites. Next, the KCC calculates the best connections for a domain controller’s directory partitions to other domain controllers. Additionally, if replication within a site becomes impossible or has a single point of failure, the KCC automatically establishes new connection objects between domain controllers to maintain Active Directory replication.

Partitions:-

Introductions

The Active Directory database is logically separated into directory partitions, a schema partition, a configuration partition, domain partitions, and application partitions. Each partition is a unit of replication, and each partition has its own replication topology. Replication is performed between directory partition replicas. All domain controllers in the same forest have at least two directory partitions in common: the schema and configuration partitions. All domain controllers in the same domain, in addition, share a common domain partition.

 

Schema Partition:

There is only one schema partition per forest. The schema partition is stored on all domain controllers in a forest. The schema partition contains definitions of all objects and attributes that can be created in the directory, and the rules for creating and manipulating them. Schema information is replicated to all domain controllers in the forest, so all objects must comply with the schema object and attribute definitions.

 

Configuration Partition:

There is only one configuration partition per forest. The configuration partition is stored on all domain controllers in a forest. The configuration partition contains information about the forest-wide Active Directory structure, including what domains and sites exist, which domain controllers exist in each, and which services are available. Configuration information is replicated to all domain controllers in a forest.

 

Domain Partition:

There can be many domain partitions per forest. The domain partitions are stored on all of the domain controllers of the given domain. A domain partition holds information about all domain-specific objects created in that domain, including users, groups, computers, and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the Global Catalog with only a subset of its attribute values.

 

REPLICATIONS:

The replication process occurs between two domain controllers at a time. Over time, replication synchronizes information in Active Directory for an entire forest of domain controllers. To create a replication topology, Active Directory must determine which domain controllers replicate data with other domain controllers.

 

Classless Inter-Domain Routing (CIDR) is a method for allocating IP addresses and routing Internet Protocol packets. It is a way to allocate and specify the Internet addresses used in inter-domain routing more flexibly than with the original system of Internet Protocol (IP) address classes. As a result, the number of available Internet addresses has been greatly increased. CIDR is now the routing system used by virtually all gateway hosts on the Internet’s backbone network.

IP addresses are described as consisting of two groups of bits in the address: the more significant part is the network address, which identifies a whole network or subnet, and the less significant portion is the host identifier, which specifies a particular interface of a host on that network. This division is used as the basis of traffic routing between IP networks and for address allocation policies. Classful network design for IPv4 sized the network address as one or more 8-bit groups, resulting in the blocks of Class A, B, or C addresses. Classless Inter-Domain Routing allocates address space to Internet service providers and end users on any address bit boundary, instead of on 8-bit segments. In IPv6, however, the interface identifier has a fixed size of 64 bits by convention, and smaller subnets are never allocated to end users.

CIDR notation is a syntax of specifying IP addresses and their associated routing prefix. It appends to the address a slash character and the decimal number of leading bits of the routing prefix, e.g., 192.0.2.0/24 for IPv4, and 2001:db8::/32 for IPv6.

If a DNS Server does not have an entry in its database for the remote host specified in a client request, it can respond to the client with the address of a DNS Server more likely to have that information, or it can query the other DNS server itself. This process can take place recursively until either the client computer receives the IP address or the DNS server establishes that the queried name cannot be resolved. DNS Servers to which other DNS Servers forward requests are known as Forwarders.

The Windows 2008 DNS Server service extends the standard forwarder configuration by using conditional forwarders. A Conditional Forwarder is a DNS Server that forwards DNS Query according to the DNS domain name in the query. For example, you can configure a DNS server to forward all the queries that it receives for names ending with Ignitedsoul.com to the IP address of one or more specified DNS Servers. This feature is particularly useful on extranets, where several organizations and domains access the same private internetwork.

Other Posts Related to DNS:

https://ignitedsoul.com/2012/01/25/dns-record-keeping/

 

Here is a quick reference you can use to determine which tools to use to help locate and resolve problems with your AD network.

Q: User unable to access network resources?

Is the network functioning at all? Can you view a list of networked systems or even access resources on other computers? If not, you have network connectivity problems. The troubleshooting tools you should start with include: Event Viewer, Ping, IPCONFIG, NLTEST, NetDiag and Network Monitor.

Q: User unable to locate resources by name?

Is name resolution functioning? Can you resolve NetBIOS or domain names into IP addresses using Windows Explorer or PING? If not, you have name resolution service problems. The troubleshooting tools you should start with include: Event Viewer, NSLOOKUP, NBTSTAT and DNSCMD.

Q: User unable to log in and obtain its roaming profile?

If not, your DC is having problems. The troubleshooting tools you should start with include: Event Viewer, DCDiag, DSASTAT and NTDSUTIL.

Q: User is unable to authenticate?

Can any client log on locally or remotely? If not, your DC is not authenticating properly. The troubleshooting tools you should start with include: Event Viewer and NetSetup.

Q: User unable to access resources as expected?

Can you access objects that you should be granted access to, and are you restricted from objects that you should not have access to? If not, then either the ACLs or DC is not functioning properly. The troubleshooting tools you should start with include: Event Viewer, DSACLS, NETDOM and SDCHECK.

Other Posts related to Active Directory:

https://ignitedsoul.com/2012/07/03/troubleshooting-tools-for-common-active-directory-problems/

https://ignitedsoul.com/2012/06/22/how-the-active-directory-communication-does-happens/

https://ignitedsoul.com/2012/01/23/what-is-the-sysvol-folder/

https://ignitedsoul.com/2012/01/23/replmon/

https://ignitedsoul.com/2011/10/12/how-to-restore-the-system-state-on-a-domain-controller-2/

https://ignitedsoul.com/2011/10/12/how-many-fsmo-roles/

https://ignitedsoul.com/2011/08/10/active-directory-roles/

https://ignitedsoul.com/2011/08/01/intrasite-and-intersite-replication/

https://ignitedsoul.com/2011/07/05/active-directory-intersite-replication/

https://ignitedsoul.com/2011/07/05/support-files-of-active-directory/

https://ignitedsoul.com/2011/03/04/active-directory-naming-and-ldap/

https://ignitedsoul.com/2011/01/05/review-of-active-directory-in-server-2008/

Active Directory (AD) relies on several communications services to communicate with client computers and between domain controllers. The variety of communications protocols used reflects the complex nature both of AD and of the industry-standard protocols that AD implements, such as Kerberos and the Lightweight Directory Access Protocol (LDAP).

Understanding how AD communicates can be critical when you’re working with domain controllers or clients that are separated from domain controllers by firewalls or other port filtering devices (such as routers).

Basic Communications

AD needs only a few basic services to be available for normal operations:

User Datagram Protocol (UDP) port 88 is used for Kerberos authentication. Transmission Control Protocol (TCP) port 88 can also be used, although it’s less common.

  • TCP and UDP ports 135 are needed for remote procedure call (RPC) endpoint mapping. RPCs are used for a number of domain controller-to-domain controller and client-to domain controller operations. Unfortunately, not all communications take place over port 135, as I’ll discuss later.
  • TCP port 139 and UDP port 138 are needed for file replication between domain controllers. This port combination is the standard NetBIOS session service port set.
  • UDP port 389 handles LDAP queries and is used for normal domain controller operations.
  • TCP and UDP ports 445 are used for file replication and are the standard Windows files sharing ports.
  • TCP and UDP ports 464 are the Kerberos password change protocol ports.
  • TCP port 593 is used by the RPC over HTTP transport. Although you don’t technically need this port for normal operations, I’ll discuss later how this feature can make working with domain controllers through firewalls a bit easier.
  • TCP port 636 is for LDAP over Secure Sockets Layer (SSL), which is the default LDAP methodology for Windows Server 2003 and later.
  • TCP port 3268 and 3269 handle Global Catalog (GC) queries. Port 3269 handles secure queries. Any domain controller that needs access to a GC or that is acting as a GC server will use these ports.
  • TCP and UDP ports 53 are used to communicate with Domain Name System (DNS), which is a vital part of AD communications.

Generally, opening these ports between clients and domain controllers, or between domain controllers, will enable AD to function normally. One exception is RPC traffic.

 

The problems described in the symptoms section occur because of a lock on the Service Control Manager (SCM) database.  As a result of the lock, none of the services can access the SCM database to initialize their service start requests. To verify that a Windows computer is affected by the problem discussed in this article, run the following command from the command Prompt:

sc querylock

The output below would indicate that the SCM database is locked:

QueryServiceLockstatus – Success
IsLocked : True
LockOwner : .\NT Service Control Manager
LockDuration : 1090 (seconds since acquired)

There is no additional information in the Event Logs beyond those from the Service Control Manager indicating that Service startup requests have timed out. The underlying root cause is a deadlock between the Service Control Manager and HTTP.SYS.

Resolution

You can modify the behavior of HTTP.SYS to depend on another service being started first.  To do this, perform the following steps:

  1. Open Registry Editor
  2. Navigate to HKLM\SYSTEM\CurrentControlSet\Services\HTTP and create the following Multi-string value: DependOnService
  3. Double click the new DependOnService entry
  4. Type CRYPTSVC in the Value Data field and click OK.
  5. Reboot the server

NOTE: Please ensure that you make a backup of the registry / affected keys before making any changes to your system.

 

Issue: We had a System running Server 2008 and when it would boot it would hang with “Applying User Settings”.  When it would finally load, many of the services were not started.
Diagnosis: http://support.microsoft.com/kb/2004121 – This Microsoft Article explains the issue associated with the SCM database being locked:

sc querylock
The output below would indicate that the SCM database is locked:
QueryServiceLockstatus – Success
IsLocked : True
LockOwner : .\NT Service Control Manager
LockDuration : 1090 (seconds since acquired)

Resolution: You can modify the behavior of HTTP.SYS to depend on another service being started first.  To do this, perform the following steps:

  1. Open Registry Editor
  2. Navigate to HKLM\SYSTEM\CurrentControlSet\Services\HTTP and create the following Multi-string value: DependOnService
  3. Double click the new DependOnService entry
  4. Type CRYPTSVC in the Value Data field and click OK.
  5. Reboot the server

 

NOTE: Please ensure that you make a backup of the registry / affected keys before making any changes to your system.