It seems like one of the most asked question is about DNS, how to configure it correctly when it comes to the Exchange and active directory environment. Let me say this up front, Exchange is an application which depends upon Active directory, and Active directory is relays on healthy DNS. If you don't configure your DNS correctly you will not have healthy, properly functioning Active Directory and Exchange environment. Active directory and integrated DNS is what we have to deal most of the time day to day. What people seem to be confused about, the primary function of DNS? Also how it is being used in most of the networks. (TCP or UDP Port 53, depending upon the type of query) "What Port DNS operates" on is a tricky question. The DNS servers, that updating DNZ zone Data, the commutation is going to be TCP, we need some way of verifying if TCP/IP hand shake is occurring correctly, so that important DNS zone data can be safely replicated by its MR. IP( internet Protocol). If the acknowledgement won't come back from the recipient to the Sender, sender resends the IP packet.( we will ask the security master Zack Payton, last Living Unix samurai, no joke.) Let me tell you this up front as well, Zack Payton is my friend, who has immense heart and gigantic brain. I have learned a lot from master, anyway commercial break is over; let's get back to our topic. DNS Domain name system or service is, intended to resolve 32 Bits complicated Binary numbers to human friendly names. The classic story is that, when we open a browser, such as Internet explorer and type www.smtp25.blogspot.com, DNS converts the complicated IP addresses into, Human friendly name. Just like me for instance.
I don't remember Erika's ( My wife) social security number, but I do member her name (-: , DNS won't help at all here but, this just prevents me to sleep on the street or look for a shelter. If I need to know her SS number I call her and ask her what was the SS number.
When DNS was introduced in Microsoft active directory environment it pretty much provided same and deeper functionality. In active directory when a server gets DCPROMO, installation of active directory database "NTDS.DIT" a server is promotes itself to be the Domain Controller and Registers a service record called SRV record saying that, "Hey I am a DC (domain Controller) and I offer these services, come and get it from me, services such as, DHCP, DNS, Authentication service to the DNS name Space (SMTP25.org). With the help of registered service records, Clients are able to locate the Authentication Servers (DC) and register their own records as a CLIENT into the DNS, so that they can be found, and they get services when they need too.
Here What Microsoft Says about setting up your Domain Controller IP addresses for DNS.If the server is the first and only domain controller that you install in the domain, and the server runs DNS, configure the DNS client settings to point to that first server's IP address. For example, you must configure the DNS client settings to point to it. Do not list any other DNS servers until you have another domain controller hosting DNS in that domain.
During the DCPromo process, you must configure additional domain controllers to point to another domain controller that is running DNS in their domain and site, and that hosts the namespace of the domain in which the new domain controller is installed. or if using a 3rd-party DNS to a DNS server that hosts the zone for that DC's Active Directory domain
Configure the Preferred DNS server in TCP/IP properties on each Domain Controller to use itself as Primary DNS Server.
Ensures that DNS queries originating from the Domain Controller will be resolved locally if possible. Will minimize impact of Domain Controller's DNS queries on the network
Dependant on Active Directory replication to ensure that DNS zone is up to date. Lengthy replication failures may result in an incomplete set of entries in the zone. Configure all Domain Controllers to use a centralized DNS server as their Preferred DNS Server. Advantages, Minimizes the reliance on Active Directory replication for DNS zone updates of Domain Controller locator records. This includes faster discovery of new or updated Domain Controller locator records, as replication lag time is not an issue. Provides a single authoritative DNS server, which may be useful when troubleshooting Active Directory replication issues
Disadvantages: Will more heavily utilize the network to resolve DNS queries originating from the Domain Controller.DNS name resolution may be dependent on network stability; loss of connectivity to the Preferred DNS server will result in failure to resolve DNS queries from the Domain Controller. This may result in apparent loss of connectivity, even to locations that are not across the lost network segment .Please note, only a failure to respond will cause the DNS client to switch Preferred DNS servers; receiving an authoritative but incorrect response does not cause the DNS client to try another server. As a result, configuring a Domain Controller with itself and another DNS server as Preferred and Alternate servers helps to ensure that a response is received, but it does not guarantee accuracy of that response. DNS record update failures on either of the servers may result in an inconsistent name resolution experience
Netlogon service on the domain controllers
Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider's (ISP's) DNS servers. If you configure the DNS client settings to point to your ISP's DNS servers, the Netlogon service on the domain controllers does not register the correct records for the Active Directory, directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server.
To forward external DNS requests, add the ISP's DNS servers as DNS forwarders in the DNS management console. If you do not configure forwarders, use the default root hints servers. In both cases, if you want the internal DNS server to forward to an Internet DNS server, you also must delete the root "." (also known as "dot") zone in the DNS management console in the Forward Lookup Zones folder
If the domain controller that hosts DNS has several network adapters installed, you must disable one adapter for DNS name registration
To confirm that the DNS records are correct in the DNS database, start the DNS management console. There should be a host record for the computer name. (This host record is an "A" record in Advanced view.) There also should be a Start of Authority (SOA) record and a Name Server (NS) record that points to the domain controller
Use below commands
Domain controller without DNS installed
If you do not use Active Directory-integrated DNS, and you have domain controllers that do not have DNS installed, Microsoft recommends that you configure the DNS client settings according to these specifications:
- Configure the DNS client settings on the domain controller to point to a DNS server that is authoritative for the zone that corresponds to the domain where the computer is a member. A local primary and secondary DNS server is preferred because of Wide Area Network (WAN) traffic considerations.
- If there is no local DNS server available, point to a DNS server that is reachable by a reliable WAN link. (Up-time and bandwidth determine reliability.)
- Do not configure the DNS client settings on the domain controllers to point to your ISP's DNS servers. Instead, the internal DNS server should forward to the ISP's DNS servers to resolve external names.
Windows 2000 Server and Windows Server 2003 member servers
On Windows 2000 Server and Windows Server 2003 member servers, Microsoft recommends that you configure the DNS client settings according to these specifications:
- Configure the primary and secondary DNS client settings to point to local primary and secondary DNS servers (if local DNS servers are available) that host the DNS zone for the computer's Active Directory domain.
- If there are no local DNS servers available, point to a DNS server for that computer's Active Directory domain that can be reached through a reliable WAN link (Up-time and bandwidth determine reliability.)
- Do not configure the client DNS settings to point to your ISP's DNS servers. If you do so, you may experience issues when you try to join the Windows 2000-based or Windows Server 2003-based server to the domain, or when you try to log on to the domain from that computer. Instead, the internal DNS server should forward to the ISP's DNS servers to resolve external names.
Windows 2000 Server and Windows Server 2003 non-member servers
If you have servers that are not configured to be part of the domain, you can still configure them to use Active Directory-integrated DNS servers as their primary and secondary DNS servers. If you have non-member servers in your environment that use Active Directory-integrated DNS, they do not dynamically register their DNS records to a zone that is configured to accept only secure updates.
- If you do not use Active Directory-integrated DNS, and you want to configure the non-member servers for both internal and external DNS resolution, configure the DNS client settings to point to an internal DNS server that forwards to the Internet.
- If only Internet DNS name resolution is required, you can configure the DNS client settings on the non-member servers to point to the ISP's DNS servers
To sum all up I wanted to copy and paste below information one more time.
Netlogon service on the domain controllers
Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider's (ISP's) DNS servers. If you configure the DNS client settings to point to your ISP's DNS servers, the Netlogon service on the domain controllers does not register the correct records for the Active Directory, directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server
In multi master Replication model, Each DC/DNS server needs to point to itself first. Remember Clients can register their records to any available domain controllers in MultiMate replication model. Each DC has read and writes copy of DNS Zone Data in active directory integrated DNS model.
So AD integration with Exchange 2003 was split into 2 components: DSAccess & DSProxy.
DSAccess.dll ran inside the System Attendant and was responsible for building a topology of the Domain Controllers available to the Exchange Server (increase diagnostics logging for MSExchangeDSAccess Service\Topology in the properties of your server in ESM and look at the 2080 events logged every 15 minutes in the application log); for querying AD to determine the destination of an email for example; and for maintaining a DSAccess cache.DSProxy provided an address book service for earlier Outlook clients and referred Outlook 2003, which is 'GC aware', to AD. (Hold down the control key and right-click on the Outlook icon in the Taskbar; select Connection Status to see the connections to the 'Directory'.) As long as your GC's were performing well; there were enough of them (4:1 – Exchange proc:GC proc); your AD site topology was designed well; and the automatic topology discovery process had not been overwritten, AD integration worked well with Exchange. To verify that Exchange was receiving timely responses to LDAP requests you could use performance monitor to gather MSExchangeDSAccess Domain Controllers\LDAP Search & Read Time counter data.
Where is DSAccess in Exchange 2007?
In Exchange 2007 DSAccess has been split into two parts: AD Provider & AD Driver. Ad Provider is responsible for maintaining the DSAccess cache and for passing LDAP queries to AD. AD Driver is a sub-component of the AD Provider and builds and maintains the DC topology. The remaining component here is 'AutoDiscover' which to some extent takes over from DSProxy and enables Outlook 2007 clients to determine the location of mailbox data, but is much more powerful and can be used to ease data recovery for example.
Ex2007 is still very much dependent on your AD site design. (Even more so from a routing perspective as linkstate becomes a thing of the past.) The new ad provider & driver run inside the 'Active Directory Topology service' which runs on all Exchange 2007 server roles. This service reads information from all Active Directory partitions. The data that is retrieved is cached and is used to discover the AD site location of all Exchange services in the organization. For example, what the AD site topology is and where therefore the closest or local Hub Transport role server is.
We need to be aware of how each different Ex2007 server role makes use of AD now. This will be important when we begin to troubleshoot issues involving AD and for capacity planning and performance monitoring. For example, the Hub Transport server role contacts AD when it performs message categorization. The categorizer uses the topology information that is cached by the Active Directory Topology service to discover the routing path for a message. The Hub Transport server uses AD site configuration information to determine the location of other servers and connectors in the topology and the location the mailbox store. If the mailbox store is in the same Active Directory site as the Hub Transport server, the message will be delivered directly to the user's mailbox. If the mailbox store is in a different Active Directory site the Hub Transport server delivers the message to a Hub Transport server in the remote AD site.
The Mailbox server role on the other hand stores the configuration for mailbox policies for example in AD. The Mailbox server uses AD therefore to retrieve this information to enforce mailbox policies.
Autodiscover is enabled by default and is used to gather configuration information in AD to enable Outlook 2007, OWA, and mobile e-mail clients to locate and connect to the appropriate Ex2007 Mailbox server that contains the user's mailbox. Autodiscover is also used to make configuring Outlook 2007 clients easier and to provision mobile devices that are used to connect to Exchange 2007. Essentially it means that you only need to know your proxyaddress for example to ensure a successful first synchronisation of your mailbox. (Provided you have the appropriate security access of course.)
(To get the global settings from the AutoDiscoverConfig object under the Global Settings object in AD use Get-OutlookProvider (Get-OutlookProvider [-Identity <OutlookProviderIdParameter>] [-DomainController <Fqdn>]))
When you install the Client Access server role; a requirement of the Autodiscover service, a new virtual directory named Autodiscover is created under the default Web site in IIS. This virtual directory handles the Autodiscover service requests.
A great new feature which complements the Autodiscover service is database portability. In Ex2007 a mailbox database (NOT PF database) can be mounted on any server in the same Organisation. This is of no use unless clients can be redirected to the mailbox data at the new location. With the Outlook 2007 and Ex2007 Autodiscover service, clients are redirected to the new server when they try to connect. This gives us a lot more options when it comes to Disaster Recovery planning.
I have not seen any figures so far but we can also expect much better scalability with Ex2007 and its integration with AD. If nothing else, with 64-bit Exchange Servers we can have much more RAM and will therefore be in a position to potentially be able to cache the entire AD database, thereby increasing lookup and response times
More here (Dougs Blog)