I haven’t had a chance to write up anything since I joined into the new project. So without writing anything else lets jump to the topic. This post will cover up all pending concepts of Active Directory.
Someone would certainly think that why would an exchange administrator need to understand active directory first? The answer to this question is very simple. Exchange Server 200x family is tightly integrated with Microsoft Active Directory Services. For 90% of the routine tasks, Exchange Server has to contact Active Directory and retrieve data out of it. A simple example is of an incoming email to some mailbox. When an email comes into your exchange server; it has to query Active Directory to understand where this email needs to be routed or handed over to.
The first one I would like to start with is Domain. A domain can be simply defined as a security boundary, a separate namespace structure. We will not jump into this in much deeper as this is just for understanding. An understanding of what domain is would be good enough.
Domain Naming Context:
Domain Naming Context is the placeholder in an active directory database (ntds.dit) which contains the information of all active directory objects such as users, their mailboxes, printers, computers and etc.
So whenever a new user object is created and had a mailbox created for it. Exchange Stores the information about the location of that user account, its mailbox location, and everything that appears in User’s properties dialog in Active Directory Users and Computers (ADUC) in Domain Naming Context. This partition also contains the information about domain objects and lot more.
Schema Naming Context:
The Schema naming context holds ClassSchema and AttributeSchema objects that represent the various classes and attributes in Active Directory. If this sounds like a circular definition, it’s meant to be. Unlike some directory services that load the schema in a separate file, the Active Directory schema is completely self-referential.
Every domain controller in a forest hosts a read-only copy of the Schema naming context. Only one domain controller, the Schema Role Master, can make changes to the schema.
Application Naming Context:
A new feature in Windows Server 2003 is the ability to create additional naming contexts that can be placed on specific domain controllers. Microsoft uses this feature to store DNS resource records for Active Directory Integrated zones.
Application Naming Context is currently capable of holding the information of DNS as an application only and this partition was introduced with DS changes in Windows Server 2003, so not available with Windows 2000 Server family products.
Configuration Naming Context:
The Configuration naming context holds information about parameters that control the services that support Active Directory. Every domain controller in a forest hosts a read/write copy of the Configuration naming context. It holds eight top-level containers.
1. Extended Rights
2. Lost and Found Config
4. Physical Locations
7. Well-Known Security Principals
Out of these 8 top level container Services is the one where Active Directory Integrated applications like Exchange store their configuration data. Exchange uses this partition to store the configurations like exchange organization name and all other settings.