< Day Day Up > |
Like the Windows Server 2003 assessment, the goal of the technical assessment is to document the existing mail and messaging systems to fully understand what technology is deployed and, more importantly, how your end users are accessing these systems. The technical assessment is the blueprint for your migration project. It helps lay the groundwork to understand your current state and the differences between your current state and the business requirements you have outlined for Exchange 2003. Existing Messaging OrganizationNearly every company has an installed mail and messaging infrastructure. No matter what type you have deployed, it's important to refer to any documentation you have related to that system's design. In addition to that, you must also collect information related to the environment in its current state. There will likely be differences between the original design documents and what is currently deployed. The following information is important to collect for all mail systems deployed:
If your existing messaging system is Exchange 5.5 or Exchange 2000, you can use a performance monitor on the existing servers to collect some of these statistics, such as message throughput. For others, you might need to rely on the management interface, such as ESM. In other cases, you can use third-party tools, such as Quest's MessageStats, to report back on much of the underlying Exchange infrastructure. Messaging Systems TopologyIn addition to documenting the existing messaging organization, you also must document the existing server hardware, location, and messaging interconnects. These server locations can be overlaid onto a network topology map to create a picture of how your network, users, and servers interact in the current environment. The existing servers should have a full hardware inventory done, including the following:
If you are planning on reusing some of your current hardware, then you need to understand the current load on the servers. In most cases, disk I/O will be the limiting factor on an Exchange server, followed by memory, and then CPU. Hopefully, this data is already documented somewhere, but if not, it needs to be. All of this information will play a critical role in determining whether the current set of servers can be redeployed or upgraded to the latest versions of Windows Server 2003 and Exchange 2003. Sometimes it's more cost effective to replace existing servers and move the users to the new platform as part of the migration plan. If you are looking at server consolidation, take into account the costs of upgrading the hardware along with the costs of licensing, maintenance, and management versus the cost of upgrading the network. In all likelihood , a major consolidation effort, such as moving all services to one or a few datacenters, will require the deployment of a SAN. This technology is extremely beneficial, but those benefits come at a price ”SANs are quite expensive. Mail-Enabled ApplicationsOne of the biggest showstoppers for migrations is in ensuring that existing mail-enabled business applications are accounted for in, and potentially migrated to, the new environment. These applications need to fall under one of the following categories:
Any of these approaches needs to be tested before they are put into production. Hopefully, you are seeing a trend here. Design, test, modify the design, test, test, and test again. Directory InfrastructureIf you are using Exchange 5.5 or other mail and messaging systems, you have to look at what level of directory synchronization is required with Exchange 2003 and what tools and utilities are available to accomplish the synchronization. Existing or Planned Windows ADExchange 2003 relies heavily on proper design and deployment of AD. It is vital that Windows Servers 2003 Global Catalog (GC) and domain controllers (DCs) are placed near Exchange 2003 servers. The details of this one sentence are quite important and require some explanation, so let's tackle that now. Domain Controller (DC)When a user needs authentication within a domain, it contacts a DC. There will likely be many DCs within a domain, and each DC holds a complete copy of the domain naming context (NC) for the particular domain in which it resides. This means that it knows about all other member servers, DCs, users, and printers that are registered within that domain. A DC also holds a copy of the Configuration and Schema NCs for the whole forest. DCs listen on LDAP port 389 for local domain queries. Global Catalog (GC) ServerThe GC server is a DC that holds the same information as any other DC in its domain. However, the GC server also holds a read-only replica of every domain NC in the forest. So, while DCs only know about the objects in their domain, a GC server knows about objects in its domain and every other domain. Although the GC server knows about all objects from every domain, it only has knowledge of a subset of the attributes for each object. The object attributes that are available for replication to a GC server and, therefore, published by the GC, are controlled by the Active Directory Schema Manager snap-in. By default, the first DC in a forest and the first DC in a domain are GC servers. GC servers listen on port 3268 (using LDAP) for queries as well as the standard LDAP port 389. Port 3269 can also be used on a GC server to process requests for GC information over Secure Sockets Layer (SSL). A DC can be made into a GC server by selecting the option from the Active Directory Sites and Services snap-in, as shown in Figure 12.2. Figure 12.2. Setting a DC to a GC via AD Sites and Services.Along with servicing user logon requests, GC servers offer directory lookup functionality to Exchange 2003 clients such as Outlook. GC servers hold a subset of the attributes from all objects within the forest, and specifically for Exchange 2003, they hold name and e-mail address information. This means that Exchange clients use information from the GC to provide the Global Address List (GAL). Although access to GAL information is available from GC servers over LDAP on port 3268, MAPI clients do not use this mechanism. By default, all MAPI client directory lookup is performed using the Name Service Provider Interface (NSPI) on a dynamically assigned port higher than 1024. (See Microsoft KB article Q270836, "Exchange 2000 and Exchange 2003 Static Port Mappings," for information on how to lock down the NSPI to a specific port number.) The NSPI is only available on GC servers, never on DCs. DSAccessDSAccess is the component of Exchange that controls how other components can access the AD. DSAccess also provides an in-memory volatile cache of user directory data and configuration information. The cache can usually hold approximately 80,000 user objects. This directory data relates to user mailbox information, which is required by other Exchange 2003 server components, including the Store and the Message Categorizer. The Categorizer is a key component to message transport. In addition, configuration information, which is stored in the Configuration NC, is important to message transport because it holds the routing topology for the environment. Without DSAccess, simple message transfer could not happen. This particular cache is not used for client-initiated GAL lookups. DSAccess' primary responsibility is to maintain a list of available, unavailable, and slow DCs and GC servers. There are two important parts to DSAccess: the Recipient cache and the Configuration cache. The Recipient cache contains information about users that Exchange 2003 components require access to, such as the Message Categorizer mentioned earlier. The Configuration cache contains only information about valid GC servers that Exchange components (including clients) should use. To be specific, in Exchange 2003 the Configuration cache contains a list of up to 200 working and preferred DCs and GC servers that Outlook mail clients and other Exchange services should use. DSAccess maintains this list through a detection process, and as changes in the environment occur ”for example, if a DC or GC server becomes unavailable ”DSAccess detects this change and augments the list. DSAccess performs its discovery process on startup, and this process either completes within one minute or aborts. You can control this timeout by setting the Registry key as follows : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess . In general, the 1-minute timeout should be sufficient; however, do note that if DSAccess does not find a DC/GC at all, Exchange will not function. To be specific, the Exchange Information Store will not start. Also note that this discovery process is repeated every 15 minutes. During the discovery process, DCs are identified into three key roles:
This discovery process can be bypassed by hard-coding the DCs that DSAccess will use. The discovery process itself is quite extensive and, in short, it basically determines which DCs and GCs will be used; preferring those that can be accessed quickly (fast links, those in the same site), and are near (in an adjacent site with a low connection cost). It really is more complex than this, but in a nutshell , that's what happens. GC Placement for Exchange ServersAs mentioned earlier, Exchange server components, such as the Message Categorizer, make use of a GC to determine the destination of a message. In short, the homeMDB is one of the attributes of a user object that is replicated to a GC. Without this information, message transfer just wouldn't work. More to the point, though, every addressee on every message processed by Exchange will be checked against a GC. This includes messages addressed to a new object introduced in Exchange 2003, the Query Based Distribution Group (QDG). A QDG is essentially a distribution group that has an LDAP query associated with it. This query is only performed, and therefore the group is only expanded, within the message transfer service. As you can guess, message transfer alone causes quite a load on the GCs, and if the connection to the GC is slow, it will have a negative impact on the messaging service. Needless to say, placing GCs in the same site, or an adjacent low-connection cost site, as the Exchange servers, is a good idea. Further, having multiple GCs available to Exchange servers will provide you with protection from a single point of failure from a performance perspective (although Exchange will attempt to use GCs that are not local to its site, of course). GC Placement for Outlook ClientsClients also make use of GCs for address lookups. They either use the GC directly, as in the case of Outlook 2000+ clients, or make use of the GC indirectly through a component called DSProxy. DSProxy's function is to perform directory queries on behalf of older clients and return the results back to the client. Unfortunately for the older clients, the GC used by DSProxy is "close" to the Exchange server, but is not necessary to the client. So, making use of newer clients, which do have the capability of selecting GCs close to them, is something to keep in mind. Again, we're skimming over Exchange 2003 in one chapter. There are loads of important details regarding all of these features, functions, and design considerations, and you really need an entire book to explore all of the details. Refer to our earlier list of titles for some recommendations. Existing Management StructureWhen designing Exchange 2003, you must consider the existing Windows management structure along with your existing mail and messaging management structure. Schema extensions to AD allow for delegation of user administration tasks such as adding users and moving mailboxes. AD delegation can be taken down to the object and attribute level, but should be planned to meet your administration model. Exchange 2003 allows for the delegation of administrative rights through the creation of AGs. AGs are essentially containers with the Exchange Services portion of the AD Configuration NC. In short, they are used to define the logical structure of the Exchange 2003 organization. AGs can contain subcontainers for various types of objects including
AGs can be created containing all of these subcontainers or only a subset. Multiple AGs can be created, each with different containers, and these AGs can be delegated to form a management environment that maps to the way an enterprise operates. Now, all this is fine and good, but there are a few caveats. The first is that if you are in a mixed-mode Exchange organization, one with Exchange 5.5 and Exchange 2003 servers, you are basically stuck with the site topology defined in your Exchange 5.5 organization. It won't be until you are in native mode, or unless you are moving to a clean, new Exchange 2003 organization, that you will get the advantages of a flexible AG design. Further, even if you were in mixed mode and have switched to native mode, you cannot move servers between AGs. So, while the flexibility afforded by AG delegation is nice, its advantages are typically enjoyed only by those moving to a brand new Exchange organization. And even then, the AG design should be well thought out. Too many AGs will complicate administration; too few will not afford the delegation that might be required. However, while we're on the topic, one of the very nice things to do, assuming you have created a new organization and are in native mode, is to create an AG that contains all of the routing groups within the organization. By doing this, you can delegate the management of message transfer to personnel that are messaging-and network-savvy. Existing Security, Virus Scanning, and AntiSPAM RequirementsEvery day there are reports of security breaches. With the increased reliance on messaging as a business system and the rising levels of threats, you must take into account your existing security and future security requirements when designing your Exchange 2003 deployment. Due to the number of open ports and access to sensitive data and directory information, a careful review of your existing network, systems, and messaging practices needs to be documented. From an Exchange perspective, the ports used are those shown in Table 12.2. Table 12.2. Exchange-Related Ports
The exposure to Exchange can be lowered by taking advantage of some of the features and deployment scenarios allowed by Exchange 2003. Examples are a front-end/back-end server with the following:
There are numerous permutations and combinations of possible configurations, and you should first gather your requirements and then determine the appropriate configuration. Because of the ever-changing nature of exploits, this task might require continued education and awareness of the latest attacks. Some companies have chosen to outsource this work to a company with a proven track record in assessing and reporting security threats, but even when using an external company, the local Administrators must be aware of the risks and risk-prevention measures. There's no avoiding this in today's world. To be sure, Microsoft has added some features to Exchange 2003 to help protect against SPAM and virus threats:
Connection FilteringThe first filters applied are connection filters. Connection filters (see Figure 12.3) are Exchange 2003's method of incorporating external real-time block (RBL) list functionality. This type of filtering is sometimes referred to as DNS Block-List (BL) filtering. The basic function is to check the sending system's IP address against an external DNS system that maintains lists of well-known SPAM sites. Connection filters involve more than just RBL, though; there are also other features such as configuring "accept" and "deny" lists. In fact, these features of the connection filter are processed first, as shown here:
Figure 12.3. Connection filter.Connection filters (see Figure 12.3) allow an Exchange Administrator to rely on managed, external lists of SPAM senders. Sender FilteringThe next filter that is applied is the Sender filter. Sender filters are designed to handle SPAM from well-known SPAM senders by either known IP addresses or known senders (see Figure 12.4). The processing for the Sender filter is as follows: Check sender address. If the sender's SMTP address is on the filter list, drop the connection. Again, dropping the connection directs the sending system to generate the NDR. Figure 12.4. Sender filter.
Sender filters are excellent in terms of redirecting processing associated with NDR generation. One of the basic problems with SPAM is that most of the costs associated with delivery and/or NDR generation are held with the receiving system. Redirecting the cost to the sending system might discourage the senders of SPAM if they have to incur the extra processing. Recipient FilteringRecipient filters (see Figure 12.5) operate against the RCPT TO: protocol command of an SMTP session, as the name implies. Recipient filters are the second check performed on incoming messages and they perform the following checks in this order:
Figure 12.5. Recipient filters.
As with sender filters, recipient filters force the sending SMTP server to take responsibility for NDR generation. Virus Scanning API (VSAPI) v2.5 and Upcoming FeaturesMicrosoft also introduced a newer Virus Scanning API that makes it easier for third-party antivirus vendors to integrate with Exchange 2003. In addition, Microsoft will be releasing the Intelligent Messaging Filter with Exchange 2003 SP1. This enhancement combines native Exchange SPAM-scanning technologies with the capability to inspect and tag a message with a rating of how likely the message is SPAM; that is, the SPAM confidence Level (SCL). This, combined with the capability of Outlook 2003 to recognize the tagging, will help reduce the amount of SPAM a user receives. It is surprising the number of issues Exchange installations have due to viruses within the messaging systems. And, although many customers who get these viruses are aware that patches and management procedures exist to stop or minimize the impact of the virus, they fail to install the necessary patches. More importantly, if your environment does not currently have an antivirus solution in place, you are just asking for trouble. Spend the money, get a good tool, and make sure automatic updates are in place. Most antivirus solutions provide an automatic update facility to ease the burden of staying current with the latest threats. Even with this in place, it is critical to keep abreast of the latest threats and their potential impact on your environment. |
< Day Day Up > |