Exchange 2010 is Not Receiving External Emails


We have an Exchange Server 2010 Version 14.3 (Build 123.4) running on Window Server 2008 R2 Enterprise, which stopped receiving incoming emails about three hours ago, however everything we checked appears to be in order.

Items we checked so far:

  • Internal emails are working fine
  • Outgoing emails are working, a 10-14 second delay more than usual is felt
  • Nothing in incoming queues on management console
  • SMTP test from MXToolBox passed
  • Server is not blacklisted (MXToolBox)
  • Telnet to server’s port 25 works fine, also from outside the network
  • Senders (we used Gmail, Outlook and Yahoo for testing) are not receiving any error messages
  • We tried restarting the information store service and the server itself
  • The drive which is running Exchange has 700 MB free. Server does appear to be under loads

“Exchange server enters back pressure mode and refuses external mail when available disk space drops to around 1%.”

Exchange Server 2016 Database Availability Groups


What Is Database Availability Group?

A database availability group (DAG) is a set of up to 16 Microsoft Exchange Server 2016 Mailbox servers that provides automatic, database-level recovery from a database, server, or network failure. DAGs use continuous replication and a subset of Windows failover clustering technologies to provide high availability and site resilience. Mailbox servers in a DAG monitor each other for failures. When a Mailbox server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database failures.

When you create a DAG, it’s initially empty. When you add the first server to a DAG, a failover cluster is automatically created for the DAG. In addition, the infrastructure that monitors the servers for network or server failures is initiated. The failover cluster heartbeat mechanism and cluster database are then used to track and manage information about the DAG that can change quickly, such as database mount status, replication status, and last mounted location.

DAG witness server and witness directory

When creating a DAG, you need to specify a name for the DAG no longer than 15 characters that’s unique within the Active Directory forest. In addition, each DAG is configured with a witness server and witness directory. The witness server and its directory are used only when there’s an even number of members in the DAG and then only for quorum purposes. You don’t need to create the witness directory in advance. Exchange automatically creates and secures the directory for you on the witness server. The directory shouldn’t be used for any purpose other than for the DAG witness server.

The requirements for the witness server are as follows:

  • The witness server can’t be a member of the DAG.
  • The witness server must be in the same Active Directory forest as the DAG.
  • The witness server must be running Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2, or Windows Server 2003.
  • A single server can serve as a witness for multiple DAGs. However, each DAG requires its own witness directory.

Regardless of what server is used as the witness server, if the Windows Firewall is enabled on the intended witness server, you must enable the Windows Firewall exception for File and Printer Sharing.

DAG membership

When the first Mailbox server is added to a DAG, the following occurs:

  • The Windows failover clustering component is installed, if it isn’t already installed.
  • A failover cluster is created using the name of the DAG. This failover cluster is used exclusively by the DAG, and the cluster must be dedicated to the DAG. Use of the cluster for any other purpose isn’t supported.
  • A CNO is created in the default computers container.
  • The name and IP address of the DAG is registered as a Host (A) record in Domain Name System (DNS).
  • The server is added to the DAG object in Active Directory.
  • The cluster database is updated with information on the databases mounted on the added server.

When the second and subsequent servers are added to the DAG, the following occurs:

  • The server is joined to the Windows failover cluster for the DAG.
  • The quorum model is automatically adjusted:
  • A Node Majority quorum model is used for DAGs with an odd number of members.
  • A Node and File Share Majority quorum model is used for DAGs with an even number of members.
  • The witness directory and share are automatically created by Exchange when needed.
  • The server is added to the DAG object in Active Directory.
  • The cluster database is updated with information about mounted databases.

Automatic database mount dial

The AutoDatabaseMountDial parameter specifies the automatic database mount behavior after a database failover. You can use the Set-MailboxServer cmdlet to configure the AutoDatabaseMountDial parameter with any of the following values:

  • BestAvailability: If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to 12. The copy queue length is the number of logs recognized by the passive copy that needs to be replicated. If the copy queue length is more than 12, the database doesn’t automatically mount. When the copy queue length is less than or equal to 12, Exchange attempts to replicate the remaining logs to the passive copy and mounts the database.
  • GoodAvailability: If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to six. The copy queue length is the number of logs recognized by the passive copy that needs to be replicated. If the copy queue length is more than six, the database doesn’t automatically mount. When the copy queue length is less than or equal to six, Exchange attempts to replicate the remaining logs to the passive copy and mounts the database.
  • Lossless: If you specify this value, the database doesn’t automatically mount until all logs generated on the active copy have been copied to the passive copy. This setting also causes the Active Manager best copy selection algorithm to sort potential candidates for activation based on the database copy’s activation preference value and not its copy queue length.

The default value is GoodAvailability. If you specify either BestAvailability or GoodAvailability, and all the logs from the active copy can’t be copied to the passive copy being activated, you may lose some mailbox data. However, the Safety Net feature (which is enabled by default) helps protect against most data loss by resubmitting messages that are in the Safety Net queue.

Quorum Models

Exchange Server DAGs make use of an underlying Windows Failover Cluster. You don’t need to create, configure, or even touch the Windows Failover Cluster using cluster management tools, except in specific maintenance scenarios that are clearly documented. When you add members to a DAG the failover clustering components are automatically installed and configured for you.

Quorum is the voting process that the cluster uses to determine whether the DAG should remain online or go offline. If the DAG goes offline all of the databases in the DAG are dismounted and inaccessible to end users, causing an outage.

There are two quorum models:

  • Node Majority: When the DAG has an odd number of members the file share witness is not required for the quorum voting process, because the DAG members can determine a “majority” themselves. For example, if one DAG member fails, 2/3 DAG members are still online (a majority) and the DAG can remain online. If two DAG members fail, 1/3 DAG members are still online, which may result in quorum being lost and the DAG going offline.
  • Node and File Share Majority: When the DAG has an even number of members the file share witness is included in the quorum voting process to ensure that a “majority” can be determined. For example, in a two-member DAG if one member fails, 1/2 members are still online (not a majority), but you would expect the DAG to be able to withstand a single node failure. The file share witness is used as the tie-breaker, meaning 2/3 “votes” are still available, and the DAG can stay online. Similarly with a four-member DAG, if two members failed, with the file share witness there are still 3/5 “votes” online, so the DAG can stay online.

 

 

Exchange 2016 system requirements


Before you install Exchange 2016, I recommend that you review this topic to ensure that your network, hardware, software, clients, and other elements meet the requirements for Exchange 2016. In addition, make sure you understand the coexistence scenarios that are supported for Exchange 2016 and earlier versions of Exchange.

Coexistence of Exchange 2016 with earlier versions of Exchange Server

  • Exchange 2007 and earlier versions is not supported.
  • Supported with Update Rollup 11 for Exchange 2010 SP3 or later on all Exchange 2010 servers in the organization, including Edge Transport servers.
  • Supported with Exchange 2013 Cumulative Update 10 or later on all Exchange 2013 servers in the organization, including Edge Transport servers.

Directory server requirements for Exchange 2016

All domain controllers in the forest need to be running one of the following:

  • Windows Server 2012 R2 Standard or Datacenter
  • Windows Server 2012 Standard or Datacenter
  • Windows Server 2008 R2 Standard or Enterprise
  • Windows Server 2008 R2 Datacenter RTM or later
  • Windows Server 2008 Standard, Enterprise, or Datacenter
  • The Active Directory forest functionality level needs to be at Windows Server 2008 or higher.

Supported operating systems for Exchange 2016

Mailbox and Edge Transport server roles:

  • Windows Server 2012 R2 Standard or Datacenter
  • Windows Server 2012 Standard or Datacenter

Management tools:

  • Windows Server 2012 R2 Standard or Datacenter
  • Windows Server 2012 Standard or Datacenter
  • 64-bit edition of Windows 10
  • 64-bit edition of Windows 8.1

Supported clients:

Exchange 2016 and Exchange Online support the following versions of Outlook:

  • Outlook 2016
  • Outlook 2013
  • Outlook 2010 with KB2965295
  • Outlook for Mac for Office 365
  • Outlook for Mac 2011

Hardware requirements for Exchange 2016

Processor:

  • x64 architecture-based computer with Intel processor that supports Intel 64 architecture (formerly known as Intel EM64T)
  • AMD processor that supports the AMD64 platform
  • Intel Itanium IA64 processors not supported

Memory:

  • Mailbox: 8GB minimum
  • Edge Transport: 4GB minimum

Paging file size:

The page file size minimum and maximum must be set to physical RAM plus 10 MB, to a maximum size of 32778MB if you’re using more than 32GB of RAM.

Disk space:

  • At least 30 GB on the drive on which you install Exchange
  • An additional 500 MB of available disk space for each Unified Messaging (UM) language pack that you plan to install
  • 200 MB of available disk space on the system drive
  • A hard disk that stores the message queue database on with at least 500 MB of free space.

File format:

Disk partitions formatted as NTFS file systems, which applies to the following partitions:

  • System partition
  • Partitions that store Exchange binary files or files generated by Exchange diagnostic logging

Disk partitions containing the following types of files can be formatted as ReFS:

  • Partitions containing transaction log files
  • Partitions containing database files
  • Partitions containing content indexing files

Exchange Server 2016 Roles Descriptions


Exchange 2016 uses Mailbox servers and Edge Transport servers. These server roles are described in the following sections.

Mailbox servers

  • Mailbox servers contain the transport services that are used to route mail.
  • Mailbox servers contain mailbox databases that process, render, and store data.
  • Mailbox servers contain the client access services that accept client connections for all protocols. These frontend services are responsible for routing or proxying connections to the corresponding backend services on a Mailbox server. Clients don’t connect directly to the backend services.
  • Mailbox servers contain the Unified Messaging (UM) services that provide voice mail and other telephony features to mailboxes.
  • You manage Mailbox servers by using the Exchange admin center (EAC) and the Exchange Management Shell.
  • Mailbox server role will consolidate the Mailbox and Client Access roles from Exchange Server 2013. Compared to Exchange Server 2010 this role consolidates all of the functions of the Client Access, Mailbox, Hub Transport, and Unified Messaging server roles. The Mailbox server role in Exchange Server 2016 is the only mandatory server role, and the consolidation reinforces the recommended practice since Exchange Server 2010 to deploy Exchange as a multi-role server instead of deploying individual roles to separate servers.

Edge Transport servers

  • Edge Transport servers handle all external mail flow for the Exchange organization.
  • Edge Transport servers are typically installed in the perimeter network, and are subscribed to the internal Exchange organization. The EdgeSync synchronization process makes recipient and other configuration information available to the Edge Transport server as mail enters and leaves the Exchange organization.
  • Edge Transport servers provide antispam and mail flow rules as mail enters and leaves your Exchange organization.
  • You manage Edge Transport servers by using the Exchange Management Shell.
  • Edge Transport server role will be much the same as Edge Transport in previous versions of Exchange, designed to sit in perimeter networks and provide secure inbound and outbound mail flow for the organization. Edge Transport servers are not mandatory.

Installing Exchange 2016 Prerequisites


Active Directory Preparation

Install-WindowsFeature RSAT-ADDS

Mailbox server role

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

After you’ve installed the operating system roles and features, install the following software in the order shown:

  • .NET Framework 4.5.2
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit

Edge Transport server role

Install-WindowsFeature ADLDS

After you’ve installed the operating system roles and features, install .NET Framework 4.5.2

Exchange 2010 MSExchangeTransport Service frequently stop


1

The problem was caused by a third party exchange virus scanner. But you can perform the following steps to troubleshoot if you have a similar issue:

Open Exchange Management Shell, run this command

Get-TransportAgent

2

It gives a list of all transport agents, you will see which additional programs have plugged into the sequence. Then run

Get-TransportAgent | Disable-TransportAgent

3

Now all transport agents are disabled. Restart the Microsoft Exchange Transport service. View the event log to see if the error returns , in my case the transport services was stable now (wait some time to be sure it won’t return it could take about 5 till 10 minutes till it comes back).

Allright after you have seen everything is stable now we can enable the transport agents one by one to see when it will crash again. Run this command

Enable-TransportAgent -Identity “TransportAgent Name”

(You can copy the exact name from the Get-TransportAgent list you did before) note some programs have more than one transport agent enable those together. After enabling a transport agent you have to restart the Microsoft Exchange Transport service again and see if the process keeps to be stable (Keep in mind to give it some time).

If you have found the problematic transport agent you can use to disable on this transport agent again.

Disable-TransportAgent -identity “transportagentname”

The Consequences of FSMOs Failing


The following section looks at what actually happens when each FSMO role fails:

  • A Schema Master failure is basically only evident when an Administrator attempts to change the Active Directory schema. What this means is that a Schema Master failure is invisible to your standard network users. You should only seize this role to the domain controller designated as the standby schema master if the existing Schema Master can in fact never be recovered.
  • As is the case with a Schema Master failure, Domain Naming Master failure is only evident if an Administrator is attempting to add a domain to the forest, or remove a domain from the forest. A Domain Naming Master failure can generally not be perceived by your standard network users. You should only seize this role to the domain controller designated as its standby when the existing Domain Naming Master would never be operational again.
  • A RID Master failure is only evident to Administrators if they are attempting to add new Active Directory objects in the particular domain where the RID Master failed. When this happens, the RID Master is unable to allocate relative IDs to the domain controllers on which the new Active Directory objects are being created. A RID Master failure cannot be detected by your conventional network users. You should also generally only seize this OM role when the existing domain controller assigned with the RID Master role would never recover from the failure.
  • An Infrastructure Master failure is also not visible to your standard network users. The failure only impacts Administrators that are attempting to move user accounts, or rename them. Consider moving the role to the designated standby domain controller if the existing domain controller assigned with the Infrastructure Master is to be unavailable for a reasonably extended period of time, and the changes that need to be made are pertinent.
  • Unlike the OM role failures previously described that are not evident to your standard network users, a PDC Emulator failure does impact network users. It is important to immediately seize this role to its designated standby domain controller if the domain contains any Windows NT backup domain controllers. You can always return this role to its previous domain controller when it is recovered and online again.

Managing Operations Master Roles


Since only one or a few domain controllers are assigned the Operations Master roles, it is important that these specific domain controllers remain functioning in the Active Directory environment. There are essentially two processes involved in the management of FSMOs. These management tasks are outlined below:

  • Because the FSMOs are automatically created when the first domain controller is installed, you might need to transfer OM roles to a more robust server. You would also need to transfer OM roles to a different server before demoting the domain controller hosting them.
  • When a lost domain controller cannot be recovered, you would to need any seize OM roles assigned to the particular domain controller.

Transferring an Operations Master role, involves moving it from one server to a different server. To transfer the Schema Master role, you need to have Schema Admins rights, and to transfer the Domain Naming Master role, you need to have Enterprise Admin rights.
You can use an Active Directory console or a command-line utility to transfer OM roles. The Active Directory MMC consoles that can be utilized to transfer the different FSMOs are outlined below:

  • Active Directory Schema MMC snap-in: For transferring the Schema Master role
  • Active Directory Domains and Trusts console: For transferring the Domain Naming Master role
  • Active Directory Users and Computers console: For transferring the RID Master role, PDC Emulator role, and Infrastructure Master Role.

When you seize an OM role, you do it without the cooperation of the existing domain controller that is assigned with the particular OM role. When an OM role is seized, it is basically reassigned to a different domain controller. Before you attempt to seize any OM roles, first try to determine what the reason is for the filure of the existing domain controller which is assigned with the particular OM role. Certain network issues which are likely to be corrected in short time frames are well worth enduring through. Before you seize OM roles, first ensure that the domain controller you are planning to shift these roles to; is indeed powerful enough to uphold these roles. In summary, you should only really seize an OM role if the existing OM cannot be recovered again. You would need to use the Ntdsutil tool command-line tool to seize OM roles.

Planning the Placement of the FSMOs


A mentioned previously, all the OM roles are by default automatically assigned to the first domain controller created for the first domain in a new Active directory forest. Then, when you create either a root domain of a new tree in a forest, or a new child domain, the three domain specific OM roles are assigned to the first domain controller in that domain. In cases where a doain has only one domain controller, each domain specific OM role has to exist on that single domain controller. The two forest specific OM roles stay on the initial domain controller for the first domain created within the forest.

OM roles are usually transferred to other domain controllers when you need to perform maintenance activities, or load balance the existing load of the domain controllers, or simply move the particular OM role to a better equipped domain controller.

In instances where multiple domain controllers exist for a particular domain, consider the following recommendations when placing your Operations Master roles within the domain:

  • Where you have two domain controllers that are direct replication partners and are well-connected, assign the RID Master role, PDC Emulator role and Infrastructure Master Role to one domain controller. This particular domain controller would become the OM domain controller for the domain. The remaining domain controller would become the designated standby OM domain controller.
  • It is generally recommended to assign the PDC Emulator and RID Master roles to the same domain controller.
  • However, if the domain which you are placing FSMO roles for is large in size, consider locating the RID Master role and PDC Emulator role on two different domain controllers. Each of these domain controllers should be well-connected to the domain controller designated as the standby OM domain controller for these two roles. This strategy is usually implemented to reduce the load on the domain controller assigned the PDC Emulator.
  • You should place the Schema Master role and the Domain Naming Master role on the same domain controller.
  • You should refrain from assigning the Infrastructure Master role to a domain controller that contains the Global Catalog. The domain controller assigned the Infrastructure Master role should be well-connected to the Global Catalog server. The Infrastructure Master would not operate correctly if the Global Catalog is hosted on the identical domain controller.

Understanding the Operations Master Roles


Active Directory operates in a multi-master replication manner. What this means is that each domain controller in the domain holds a readable, writable replica of the Active Directory data store. In multi-master replication, any domain controller is able to change objects within Active Directory. Multi-master replication is ideal for the majority of information located in Active Directory. However, certain Active Directory functions or operations are not managed in a multi-master manner because they cannot be shared without causing some data uniformity issues. These functions are called Flexible Single Master Operations (FSMOs).

There are five Operations Master (OM) roles which are automatically installed when you install the first domain controller. These five OMs are installed on the domain controller. Two of these OM roles apply to the entire Active Directory forest. The roles that apply to the forest are the Schema Master role and the Domain Naming Master role. The other three OM roles apply to each domain. The roles that apply to a domain are the Relative identifier (RID)/relative ID Master Role, the Primary Domain Controller (PDC) Emulator role, and the Infrastructure Master role. When a domain controller is assigned a FSMO, that domain controller becomes a role master. The particular domain controller that is assigned these roles performs single-master replication within the Active Directory environment.

Because domain controllers generally contain the same Active Directory information, when one domain controller is unavailable, the remainder of the domain controllers are able to provide access to Active Directory objects. However, if the domain controller that is lost has one of these OM roles installed, you could find that no new objects can be added to the domain.

  1. Schema Master Role
  2. Domain Naming Master Role
  3. RID (Relative Identifier) Master Role
  4. PDC (Primary Domain Controller) Emulator Master Role
  5. Infrastructure Master Role

Forest-Wide Operations Master Roles

Schema Master Role:

Because the objects that exist in the in the schema directory partition define the Active Directory structure for a forest, great control is placed on who can add objects to this partition. Since each domain controller in an Active Directory environment have a common schema, the information in the schema has to be consistent on each domain controller. It is the domain controller that is assigned the Schema Master role that controls which objects are added, changed, or removed from the schema. The domain controller with the Schema Master role is the only domain controller in the entire Active Directory forest that can perform any changes to the schema. You can use the Active Directory Schema MMC snap-in to make changes to the schema, and only if you are a member of the Schema Admins group. Any changes made to the schema would affect each domain controller within the Active Directory forest. You can transfer the Schema Master role to a different domain controller within the forest. You can also seize the role if the existing domain controller holding the role had a failure and cannot be recovered.

Domain Naming Master Role:

As is the case with the Schema Master role, only one Domain Naming Master role is allowed in the entire forest. The domain controller that is assigned the Domain Naming Master role is responsible for tracking all the domains within the entire Active Directory forest to ensure that duplicate domain names are not created. The domain controller with the Domain Naming Master role is accessed when new domains are created for a tree or forest. This ensures that domains are not simultaneously created within the forest. The default configuration is that the first domain controller promoted in a forest, is assigned this role. You can however transfer the Domain Naming Master role to a different domain controller within the forest.

Domain-Wide Operations Master Roles

Relative identifier (RID) Master Role:

When a security object is created within Active Directory, it is allocated a security ID. The security ID is made up of the domain security ID and a relative ID. The domain security ID is exactly the same for each security ID created in the particular domain. The relative ID on the other hand is unique to each security ID created within the domain. Because each relative ID has to be unique, the domain controller that is assigned the RID Master role is responsible for tracking and for assigning unique relative IDs to domain controllers whenever new objects are created. To ensure efficiency when assigning relative IDs to domain controllers, the domain controller assigned the RID Master role actually generates a set of 500 relative IDs to allocate to domain controllers. As the number of available relative IDs decreases, the RID Master generates more relative IDs to maintain the number of relative IDs available as 500. The default configuration is that the RID Master role and PDC Emulator role is assigned to the identical domain controller. You can however transfer the RID Master role to a different domain controller within the domain.

PDC Emulator Role:

In domains that contain Windows NT Backup Domain Controllers (BDCs), the domain controller which is assigned the PDC Emulator role functions as the Windows NT Primary Domain Controller (PDC). The PDC Emulator role has importance when it comes to replication – BDCs only replicate from a Primary Domain Controller! Objects that are security principles can only be created and replicated by the PDC Emulator. Security principles are Users, Computers, and Groups. It is therefore the PDC Emulator that enables down-level operating systems to co-exist in Windows 2000 and Windows Server 2003 Active Directory environments. After the domain is operating in the Windows Server 2003 functional level, the domain controller assigned the PDC Emulator role continues to perform other operations for the domain.

These additional functions include the following:

  • All password changes and account lockout requests are forwarded to the PDC Emulator. A domain controller within a domain checks first with the PDC Emulator to verify whether a bad password provided by a user was a recently changed password, and is therefore a valid password.
  • Group policies consist of a Group Policy Container (GPC) in Active Directory, and a Group Policy Template (GPT) in the SYSVOL folder. Because these two items can become out of sync due to multi-master replication, the Group Policy Editor is by default set to the PDC Emulator. This prevents group policy changes from being made on all domain controllers within the domain.

Infrastructure Master Role:

The domain controller assigned the Infrastructure Master Role has the following functions within the domain:

  • Updates the group-to-user references when the members of groups are changed. These updates are sent by the Infrastructure Master to the remainder of the domain controllers within the domain via multi-master replication.
  • Deletes any stale or invalid group-to-user references within the domain. To do this, the Infrastructure Master Role checks with the Global Catalog for stale group-to-user references.

Active Directory Logical and Physical Components


Active directory introduced in windows 2000 operating system (little old stuff).
Active Directory can be considered to have both a logical and physical structure, and there is no correlation between the two. The logical parts of Active Directory include forests, trees, domains, OUs and global catalogs. Each element of the logical structure of Active Directory is defined below:

Domain – a domain in Windows 2000 is very similar to a domain is Windows NT. It is still a logical group of users and computers that share the characteristics of centralized security and administration. A domain is still a boundary for security – this means that an administrator of a domain is an administrator for only that domain, and no others, by default. A domain is also a boundary for replication – all domain controllers that are part of the same domain must replicate with one another. Domains in the same forest automatically have trust relationships configured.

Tree – a tree is a collection of Active Directory domains that share a contiguous namespace. In this configuration, domains fall into a parent-child relationship, which the child domain taking on the name of the parent.

Forest – a forest is the largest unit in Active Directory and is a collection of trees that share a common Schema, the definition of objects that can be created. In a forest all trees are connected by transitive two-way trust relationships, thus allowing users in any tree access to resources in another for which they have been given appropriate permissions and rights. By default the first domain created in a forest is referred to as the root domain. Amongst other things, this is where the Schema is stored by default.
There are two types of active directory forest :-
I) Single Forest
2) Multiple forest

Organizational Unit – An organizational unit (OU) is a container object that helps to organize objects for the purpose of administration or group policy application. An OU exists within a domain and can only contain objects from that domain. OU can be nested, which allows for more flexibility in terms of administration. Different methods for designing OU structures exist including according to administration (most common), geography, or organizational structure. One popular use of OUs is to delegate administrative authority – this allows you to give a user a degree of administrative control over just the OU, and not the entire domain.

Global Catalogs – Global Catalogs are listings of every object that exists within an Active Directory forest. By default, a domain controller only contains information about objects in that domain. A Global Catalog server is a domain controller that contains information about every object (though not every attribute for each) stored in the entire forest. This facilitates and speeds up the search for information in Active Directory. By default only the first domain controller created in a forest has a copy of the global catalog – others much be designated manually.

The physical structure of Active Directory helps to manage the communication between servers with respect to the directory. The two physical elements of Active Directory are domain controllers and sites. Each is described below.

Domain Controllers – domain controllers are Windows 2000 Server-based systems that store the Active Directory database. Every Windows 2000 domain controller has a writable copy of the directory. This is different that in NT 4, where only the PDC had this capability. Domain controllers in the same domain contain replicas of the directory that must be synchronized periodically.

Site – a site is a concept that did not exist in an NT directory service structure. In Active Directory, sites are groups of IP subnets that are connected at high speed. Although the definition of ‘high speed’ is open, it is generally considered to be subnets that are connected at LAN speeds (say 10 Mb) or higher. The purpose of defining sites in Active Directory is to control network traffic relating to directory synchronization, as well as to help ensure that users connect to local resources. For example, domain controllers located in the same site replicate with one another on a 5-minute change notification interval similar to in NT 4. However, replication between domain controllers in different sites can be scheduled according to your needs. This allows a much greater degree of flexibility that in NT 4. For example, you could set things up such that replication between sites could only happen between midnight and 6am – thus ensuring that replication traffic would not interfere with normal data transfer during business hours. Sites also help ensure that users avoid accessing resources over the WAN by having client systems access servers (such as domain controllers) that are in the same physical site first.4-20-2015 4-05-23 PM

What is Active Directory Domain Services ?


Microsoft Active Directory Domain Services are the foundation for distributed networks built on Windows 2000 Server, Windows Server 2003, Microsoft Windows Server 2008 and Microsoft Windows Server 2012 operating systems that use domain controllers. Active Directory Domain Services provide secure, structured, hierarchical data storage for objects in a network such as users, computers, printers, and services. Active Directory Domain Services provide support for locating and working with these objects.