Conducting the Technical Assessment of the Current Environment

 <  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 Organization

Nearly 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:

  • Physical network topology, including connectivity to branch offices

  • Network bandwidth

  • Available bandwidth

  • Division or departmental specifics

  • Geographic location specifics

  • Number of users (break down into local and remote)

  • Number of messages per day

  • Number of mailboxes deployed

  • Peak number of active or connected users

  • Current clients and version

  • Peak and average messages per day

  • Average message size in kilobytes

  • Average message store size

  • Current DNS and Windows Internet Naming Service (WINS) infrastructure

  • Current inbound and outbound messaging configurations

  • Public Folders ( assuming Exchange as the install base)

  • Current antivirus and antiSPAM technologies

  • Current DS deployed

  • Client configuration

  • Desktop OS version

  • Desktop messaging client and version

  • Access through Virtual Private Network (VPN), firewall

  • Third-party products layered on the messaging backbone

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 Topology

In 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:

  • System Type

  • OS type and version (including current patch levels)

  • Messaging product type and version (including current patch levels)

  • CPU size

  • Memory size

  • Current system, disk, and controller BIOS

  • Network interface types and revisions

  • Storage interfaces

  • Amount of storage

  • Current available storage and room for expansion

  • Current system and memory utilization

  • Messaging interconnect, types (X400, Simple Mail Transfer Protocol [SMTP], Lotus Notes, and so on) and endpoints

  • Third-party products

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 Applications

One 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:

  • Maintained in the current environment : Perhaps the application cannot exist natively in Exchange and the cost of rewriting it is too great. In such a case, a coexistence plan needs to be in place for this application and that plan must be tested .

  • Migrated to the new environment : If the application is based on Exchange 5.5 or Exchange 2000, it is likely that the application is Exchange 2003-ready if it's a commercial product. If it's a home-grown application that relies on Public Folders, then it will likely live happily in an Exchange 2003 environment. A migration plan for the application does need to be in place, though.

  • Ported to the new environment : Perhaps the application is based on Lotus Notes or GroupWise. There are boutique consulting firms in the marketplace that will port applications based on other messaging technology to Exchange.

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 Infrastructure

If 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 AD

Exchange 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) Server

The 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.

DSAccess

DSAccess 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:

  • Configuration DC (used for reading/writing system configuration information)

  • General-purpose or "worker" DCs

  • GC servers

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 Servers

As 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 Clients

Clients 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 Structure

When 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

  • Servers

  • Routing groups

  • System policies

  • Public Folder trees

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 Requirements

Every 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

Port

Protocol

80

TCP (basic HTTP)

389

TCP (LDAP)

3268

TCP (LDAP)

88

TCP (Kerberos)

88

UDP (Kerberos)

53

TCP (DNS)

53

UDP (DNS)

135

TCP (RPC Port-Mapper)

112

TCP (AD Service)

445

TCP (Netlogon SMB)

123

TCP (NNTP)

25

TPC (SMTP)


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:

  • The front-end (FE) in a Demilitarized Zone (DMZ); back-end (BE) in the internal network

  • A proxy server in the DMZ, and the front end/back end in the internal network

  • Configure RPC over HTTP with access through an RPC proxy server

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 filtering

  • Recipient filtering

  • Updated antivirus API

Connection Filtering

The 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:

1. Process the configured connection filter.

2. If sender's IP is on the "accept" list, flag the message as valid.

3. If the sender's IP address is on the "deny" list, drop the connection. Note that dropping the connection forces the sending system to generate the Non-Delivery Receipt (NDR) and, therefore, avoids local processing associated with NDR generation.

4. Query the first DNS BL server with the sender's IP address.

5. If a DNS "A" record is returned, drop the connection. If the RBL provider returns a valid response to the DNS lookup, then all recipients are rejected unless the recipient is on an exception alias.

6. Process message based on status returned by RBL provider.

7. Perform steps 1 and 2 against the next RBL filter configured.

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 Filtering

The 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 Filtering

Recipient 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:

1. Check the recipient addresses in the RCPT TO: portion of the message.

2. If the recipient does not exist, reject the RCPT TO: command with a protocol error.

3. If the recipient is on the list defined by the Admin, then reject the RCPT TO: command with a protocol error.

4. If the "unknown recipient" filter is on, and the recipient is unknown (that is, not in the directory; see check box at the bottom of Figure 12.5), drop the connection. This is a fairly intensive check, as the routing service must first determine whether the recipient is valid.

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 Features

Microsoft 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  >  


Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
Windows Server 2003 on Proliants. Deployment Techniques and Management Tools for System Administrators
ISBN: B004C77T6A
EAN: N/A
Year: 2004
Pages: 214

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net