New book: Microsoft Exchange Server 2010 Best Practices

  • Article

627192cvr.indd We’re happy to announce that Microsoft Exchange Server 2010 Best Practices (ISBN 9780735627192; 912 pages) is now available for purchase! Written by Exchange experts Siegfried Jagott and Joel Stidley, this book has already received raves from customers for pulling in candid advice and field-tested recommendations from industry experts around the world.

 

You can find the book’s Contents at a Glance and an excerpt from the Introduction in this previous post.

We’ve already heard from a couple of customers who had trouble locating the companion content for this book. The files are located here; you’ll need to click on the Examples link on the left-hand side of the page. (And yes, we’re actively working to make the companion files easier to find.)

In this post we offer an excerpt from this book’s Chapter 3, “Exchange Environmental Considerations”:

Chapter 3 Exchange Environmental Considerations

This chapter describes all the basic components surrounding Exchange Server 2010 that need to be considered to plan a solid Exchange implementation. These components provide the basis to build Exchange on a solid foundation and to identify potential issues.

It provides a basis for other chapters in this book by describing some of the technologies that will be discussed later. For example, this chapter includes a discussion on namespace design as well as a review of certificate requirements, which are then taken to the next level in Chapter 4, “Client Access in Exchange 2010.” Of particular importance when using this book is the “Planning Naming Conventions” section, which explains the names that are used throughout the entire book.

Evaluating Network Topology

Evaluating the network topology through which Exchange Server 2010 will communicate is crucial during the Delivery Phase, Step 2: Assess, as described in Chapter 2, “Exchange Deployment Projects.” Often, making changes in the network infrastructure can take a considerable amount of time because the Exchange team isn’t necessarily responsible for making changes to the network, and communication and negotiation are often required before network changes can be made, especially in large organizations that support heterogeneous operating systems.

Identifying any required changes and making sure that the execution of the change can occur without any difficulties early in the design process can save time later when you are implementing Exchange Server 2010.

This section provides an overview of the network-related requirements for Exchange 2010.

Reviewing Current and Planned Network Topology

The first step is to collect all information about your internal network, the perimeter network, and its external collections as thoroughly as possible from a variety of sources. These sources include the following:

  • Physical network topology Verify that TCP/IP is used everywhere, which Internet Protocol is used (IPv4 and/or IPv6), how IP addresses are allocated for servers, and that IP subnets are used according to location.
  • Internal physical network connections or links This includes LAN and WAN links, router, and so on.
  • External physical network connections This includes the Internet, partner companies, and so on.
  • Interconnection of physical network connections This includes hub-and-spoke, ring or star, and point-to-point.
  • Physical network speed Divide between guaranteed bandwidth, available bandwidth, and latency for each identified network link.
  • Network protection that might interfere This includes firewalls that protect physical links or network link encryption devices that reduce the link speed.
  • Firewall port availability to both external and internal systems.
  • Server name resolution used in locations or between locations (DNS/WINS name resolution).
  • Defined namespaces in DNS This is described in the “Planning Namespace” section later in this chapter.
  • Perimeter network servers Including any servers that are located in a perimeter network, especially any server that provides SMTP-relay functionality.

Be sure to identify any known changes that will occur to the network configuration during the interim between the planning phase and the deployment phase so that the impact of the change can be assessed just prior to deployment and the proper adjustments made.

NOTE  In large organizations, gathering this information might be quite a time-consuming effort—you may have to meet with many disparate network teams to get a thorough understanding of the network specific details. If you want to evaluate a global network infrastructure that includes many sites or locations, make sure you understand the company structure, the businesses that Exchange will serve, and how these businesses are supplied with IT currently. Having these discussions will provide you with much insight into the current network topology and help identify any problems and potential issues that you should consider when planning the messaging design.

Domain Name System (DNS)

This section is about the technical foundation on domain name system (DNS). It does not include any discussion about namespace planning. The aspects of namespace planning and disjoint namespace or single label domains are described in the “Planning Namespace” section later in this chapter.

DNS and Active Directory

Microsoft Windows uses the DNS standard as the primary name registration and resolution service for Active Directory. For that reason it is a basic requirement that all clients and servers must be able to reliably resolve DNS queries for a given resource in the appropriate namespace.

DNS provides a hierarchically distributed and scalable database where hosts can automatically update their records. These dynamic records can be fully integrated into Active Directory when using Active Directory–integrated DNS zones.

NOTE  In Exchange Server 2003 or earlier, the Windows Internet Name Service (WINS) was required to support multi-domain environments. This is no longer required for Exchange Server 2010.

The following list provides best practices for DNS settings when implementing Exchange
Server 2010 in your Active Directory:

  • Use the DNS Server service that is part of Windows Server. This provides you with features such as Dynamic Update and Active Directory–integrated DNS zones. For example, domain controllers register their network service types in DNS so that other computers in the forest can access them.
  • If you cannot use the Windows DNS Server for Active Directory and Exchange, make sure the DNS server supports SRV resource records and allows dynamic updates of Locator DNS resource records (SRV and A records). If your company uses BIND, make sure you use BIND 8.x or later.
  • Store all DNS zones as Active Directory–integrated in Active Directory to gain the benefit of having DNS and Active Directory replicated by a single mechanism. This prevents the need to use different tools for troubleshooting.
  • Configure Dynamic Updates as Secure, thus only allowing authorized clients to register their host name and IP address.
  • Only configure Forward Lookups Zones, which are required by Exchange 2010. You do not need to configure Reverse Lookup Zones because they are not used by Windows 2008 or Exchange 2010.

More information can be found in the whitepaper “DNS Requirements for Installing Active Directory” at https://technet.microsoft.com/en-us/library/cc739159(WS.10).aspx.

Notes from the Field
DNS Dynamic Updates
John P Glynn
Principal Consultant, Microsoft Consulting Services, US/Central Region

Active Directory is a key dependency for Exchange; without it Exchange does not and will not properly function. Active Directory is based on the DNS service. Without DNS, many components of Active Directory, Exchange, and client interaction fail to function properly. When a domain controller is installed on a domain, a series of records is created. These DNS records contain service location records for Kerberos, LDAP, GC, site-specific information, and a domain record that is a unique GUID.

Exchange servers utilize these DNS records to locate authentication or other specific services. Exchange will use Active Directory site-specific service location records for services such as: locating the closest Global Catalog servers to utilize for name resolution, locating domain controllers to utilize for Exchange configuration information, and routing messages between remote Exchange servers. Exchange servers as well as workstations that run the Exchange management tools rely heavily on Kerberos for authentication. Therefore, it is equally important that the Exchange server A records are registered within DNS correctly as well.

As a best practice, implement DNS with dynamic updates enabled. I have been in a few environments where transient Exchange and client issues were tracked to missing or invalid SRV records. Some of the specific issues that I have seen include the following:

  • Invalid host record for the Exchange Server—the connection suffix of the server did not match the DNS record causing Kerberos authentication failure.
  • The domain GUID records for the domain were incorrectly entered under the_msdcs zone, causing improper identification of domain controllers for the Active Directory domain.
  • Slowness issues resulting from missing site location records, causing Exchange to possibly grab a Global Catalog located at a distant site—thus communication needs to flow across WAN links. This might be because some
    or all of the following records are missing or incorrect in DNS: _ldap._tcp
    ._sitename._sites._gc._msdcs.domain.com.

Most modern DNS implementations in use today support dynamic updates. As a best practice it is advisable to allow only secure updates, which prevents rogue systems from injecting invalid entries into your DNS zones.

A few environments refused to globally enable dynamic updates on their zones. We were able to convince the team to allow only domain controllers to dynamically update their records. Exchange server records were created manually. However, A records are familiar to DNS administrators and less likely to be incorrect. As with any manual process, it can be incorrectly created, so always double-check. If this is not possible, try to convince the DNS team to temporarily enable dynamic updates during the DCPROMO process and the subsequent reboot to allow the domain controllers to dynamically create/update all of the necessary records. Obviously this requires more process overhead, but in the long run it will save on issues, outages, and hours of troubleshooting caused by incorrectly configured DNS records.

Several tools are available to validate records and the functionality of DNS, such as DNSLint, DCDiag, and netdiag. Other standard tools include nslookup, ipconfig, and nltest.

DNS Records Used by Exchange 2010

DNS provides a number of critical functions for Exchange 2010. This section provides an overview of the most important records in DNS.

A Records

A records or Host records provide a host name to IP address mapping. Host records are required for each domain controller and other hosts that need to be accessible to xchange Servers or client computers. Host records use IPv4 (A records).

Here is an example of an A record:

berlin-dc01.litware.com. IN A 10.10.0.10.

SRV Records

All Exchange 2010 servers use DNS to locate a valid domain controller or global catalog. By default, each time a domain controller starts the Netlogon service, it updates DNS with service (SRV) records that describe it as a domain controller and global catalog server, if applicable.

SRV resource records are DNS records. These records identify servers that provide specific services on the network. For example, an SRV resource record can contain information to help clients locate a domain controller in a specific domain or site. For that reason, the SRV records for domain controllers and global catalog servers are registered with several different variations to allow Exchange servers locating a suitable domain controller or global catalog during the Active Directory discovery process.

One option is to register DNS records by site name, which enables computers running Exchange Server to find domain controllers and global catalog servers in the local Active Directory site. Exchange Server always favors the selection of a domain controller and/or global catalog from the same site that Exchange is installed into.

Here is an example of an SRV record:

_ldap._tcp.litware.com. IN SRV 0 100 389 berlin-DC01.litware.com.

MX Records

A Mail Exchanger (MX) record is a resource record that allows servers to locate other servers to deliver Internet e-mail using the Simple Mail Transfer Protocol (SMTP). An MX record identifies the SMTP server that will accept inbound messages for a specific DNS domain. Each MX record contains a host name and a preference value. When you deploy multiple SMTP servers that are accessible from the Internet, you can assign equal preference values to each MX record to enable round-robin between the SMTP servers. You also can specify a lower preference value for one of the MX records. All messages are routed through the SMTP server that has the lower-preference-value MX record, unless that server is not available.

Here is an example of an MX record:

litware.com MX 10 fresno-ht01.na.litware.com.

NOTE  You don’t need MX records for Hub Transport servers that are involved in internal mail routing. That is only required for external SMTP routing—for example, to the Internet.

More information about MX records and how they are used for SMTP message routing can be found in Chapter 5, “Routing and Transport.”

SPF Records

Exchange Server 2010 uses Sender Policy Framework (SPF) records to support Sender ID spam filtering. If you want to use this feature, you need to configure the SPF records in DNS. This is described in more detail in Chapter 7, “Edge Transport and Messaging Security.”

Split DNS

Split DNS or split-brain DNS is about setting up separate DNS zones so that DNS requests that come from the Internet will resolve to different IP addresses than requests coming from your internal workstations or servers. In other words, as shown in Figure 3-1, if the Internet client resolves mail.litware.com, it will receive an IP address that is associated with an external firewall solution that is sitting in the perimeter network. The internal client will get an IP address associated with the internal Client Access server array.

Capture1

The benefit of using split DNS is that it helps control client access. Internal clients use the internal systems instead of the external systems. In other words, internal users’ sessions aren’t handled by the firewall application and you do not expose internal IP addresses or host names to the Internet.

You can also limit access to specific hosts that are part of the perimeter network or force users to take a specific communication route. For this reason it is a best practice to implement split DNS in every Exchange organization that has server roles exposed to the Internet.

Fixed IP Address vs. Dynamic IP Address

It’s important to know whether your company has an Internet provider that provides your company with fixed IP addresses or if you’re using dynamic IP addresses to access the Internet. If your servers that have some relationship to external communication, such as Edge Transport servers, have fixed IP addresses and your DNS entries (MX or A records) are registered accordingly, you’re working with the best practices approach.

However, a fixed IP address might be a cost issue, especially in small companies. Thus some companies might want to implement Exchange 2010 based on an Internet provider that only provides a dynamic IP address. If you’re in this situation, you should consider a Dynamic DNS service that lets you register your dynamic IP address to their DNS service. However, make sure the dynamic DNS service includes the following:

  • Your IP addresses should automatically register in DNS when the IP address changes. Your router and/or Dynamic DNS service provider need to support this.
  • IP updates should be replicated in DNS real time to make sure the change is known to the Internet immediately.
  • For external SMTP servers to know how to send messages to your domain, the DNS record for your domain should include an MX record.
  • The Dynamic DNS service should provide you with an SMTP relay host to send messages to the Internet. If you directly send messages, your server is quite likely to be detected as spam because of your changing IP addresses. Many SMTP servers consider dynamic IP addresses as not trustworthy and thus don’t accept messages from them.

If you consider these points, you’ll have no problem operating Exchange Server 2010 when using a dynamic IP address.

Internet Protocol (IPv4 and IPv6)

Internet Protocol Version 4 (IPv4) is commonly available and the basis for communication between any device on the Internet. The successor of IPv4 is called Internet Protocol Version 6 (IPv6), as defined in RFC 2460 in 1996.

IPv6 was developed to correct many of the shortcomings of IPv4, such as the limited pool of available IP addresses and the lack of extensibility. Because IPv6 addresses are 128 bits long (compared to IPv4 addresses, which are 32 bits long), there are enough IPv6 addresses available for every living insect, animal, and person on earth.

Unfortunately, IPv6 is not an extension of IPv4 but a completely new protocol. Therefore, an IPv4 network can’t communicate directly with an IPv6 network and vice versa. Any network device, such as a router, needs to be able to understand IPv6; otherwise, IPv6 causes communication problems.

IPv6 for Windows

The client and server software needs to support IPv6 to use it. The following Microsoft server operating systems support IPv6:

  • Windows Server 2003 (IPv4 is installed and enabled; IPv6 is not installed by default.)
  • Windows Server 2008 (IPv4 and IPv6 are installed and enabled by default.)
  • Windows Server 2008 R2 (IPv4 and IPv6 are installed and enabled by default.)

IMPORTANT  Microsoft also recommends that you do not turn off IPv6 in a clustered environment because Windows Server 2008 R2 Clustering uses IPv6 for internal communication.

Not only does the server need to support IPv6, but also the client operating system.
The following Microsoft client operating systems support IPv6:

  • Windows XP Service Pack 1 (SP1) or later (IPv4 is installed and enabled; IPv6 is not
    installed by default.)
  • Windows Vista (IPv4 and IPv6 are installed and enabled by default.)
  • Windows 7 (IPv4 and IPv6 are installed and enabled by default.)
  • For more information about IPv6, see the IPv6 for Microsoft Windows FAQ
    at https://go.microsoft.com/fwlink/?LinkId=147465.