The Expert's Guide for Exchange 2003 Preparing For, Moving To, and Supporting Exchange Server 2003
Total Page:16
File Type:pdf, Size:1020Kb
The Expert's Guide for Exchange 2003 Preparing for, Moving to, and Supporting Exchange Server 2003 by Steve Bryant iii Books Contents Chapter 3 Consolidating Your Exchange Services . 34 Server Ownership Costs . 34 Exchange Server Proliferation . 34 Consolidating Protocols . 35 Exchange 2003 and AD . 37 Front-End Exchange Servers . 39 Front-End Servers and Performance . 45 Balancing Front-End and Back-End Servers . 45 Consolidating Servers . 46 Storage Space and Recovery . 46 Configuration and Memeory . 47 Mailbox Consolidation Concerns . 47 Creating Server Redundancy . 48 Spreading the Load . 48 Clustering . 48 Deploying High- or Continuous-Availability Servers . 50 Consolidating Mailbox Servers . 50 Move Mailbox Tool . 50 Consolidating Sites . 51 Consolidating Your Exchange Organization . 52 Consolidating Exchange 2003 and Exchange 2000 Organizations . 52 Tools for Merging Exchange Organizations . 53 Using the Exchange Migration Wizard . 53 Copying Public Folder Data . 53 Copying the Organizational Forms Library . 54 Copying Contacts from One Organization to Another . 54 Collecting Group Distribution Memebership . 55 Completing the Consolidation . 57 More Consolidation Details . 64 Next: Installing Exchange 2003 . 64 34 Chapter 3: Consolidating Your Exchange Services At the heart of most successful and cost-effective Microsoft Exchange 2003 and Exchange 2000 deployments lies consolidation. Fewer Exchange servers translates to fewer server licenses, smaller data centers, easier administration, and a reduced cost of doing business. These benefits of consolidation are often the desired end results that prompt – and justify budgets for – upgrading and consolidating Exchange deployments. Estimating the savings that your consolidation efforts can realize will require some intelligent speculation because you’ll derive your overall savings from multiple sources. In fact, Microsoft recently performed a consolidation that illustrates the potential for administrative savings. With Exchange Server 2003, Microsoft reduced its 113 mailbox servers in 75 geographical locations worldwide to 38 mailbox servers in 7 locations worldwide. Server Ownership Costs IDC estimated that 62 percent of 2002 server costs came from the additional staffing required to support the servers. Another 23.1 percent of the costs came from downtime, with the balance assigned to training, software, and hardware. IDC broke down its 2002 numbers for the annual cost of Windows server ownership (per server) into the following server categories: • File server $19,809 •Networking server $2,357 • Print server $17,369 • Security server $14,099 • Web server $6,461 Although reports about messaging costs offer various figures, I like to use an annual cost of $10,000 per server for most calculations. Whether your specific numbers are higher or lower, you can see how quickly server-consolidation savings can add up. So the questions you’re probably asking right now are “How did we get here?” and “Where did all these servers come from?” In 2003, the Gartner Group noted that independent business units within companies – rather than the company’s IT department – initiate more than 60 percent of all IT projects. The high proportion of business units initiating deployments is especially true for Exchange because remote offices and departments often decide they need more horsepower or an additional server – or worse still (in terms of additional ports) their own SMTP domain or Microsoft Outlook Web Access (OWA) server. Exchange Server Proliferation Although you can certainly blame departmental projects for proliferation, Exchange 5.5 Server’s limited scalability has also been a key factor. Most of Exchange 5.5’s scalability limits involved the Brought to you by Quest Software and Windows & .NET Magazine eBooks Chapter 3 Consolidating Your Exchange Services 35 limits of the Extensible Storage Engine (ESE) engine. Administrators didn’t want to scale Exchange 5.5 servers too large because a 500GB database would take more than 15 hours to back up or restore). Moreover, a single database failure or corruption could mean certain death to the Exchange administrator who had decided to put all users on the same box (I won’t even mention how the OWA client performed). In short, many companies needed additional Exchange 5.5 servers to “spread the load” – both to accommodate users and protocols and to maintain acceptable performance. Also, although Microsoft Outlook 98 offered a stable offline mode that permitted remote access to the Exchange server, it wasn’t robust. Most remote offices wanted the same performance they enjoyed with local Microsoft Mail (MS Mail) and cc:Mail post offices. To achieve that performance, many remote offices installed a small Exchange 5.5 server. Fortunately, you now have more options. For this discussion, I’ll divide the subject of consolidation into distinct categories and begin with the lowest common denominator: protocols. I’ll then cover server consolidation, site consolidation, and, finally, Exchange organization consolidation. Consolidating Protocols Although administrators often consider protocol consolidation only after they’ve deployed or upgraded Exchange, the security implications involved should make protocols an early priority. As an Exchange consultant, I work all over the world and I get to hear many instructive stories. One customer described a security incident that put the virtues of consolidation in sharp perspective. His company was burglarized one afternoon; apparently the culprit had “tailgated” an employee into the building through a side door. Thereafter, the security team insisted that everyone come in and out the main doors so that security personnel needed to watch just one entrance for unauthorized access. Chances are you need to reduce the number of “entrances” to your network. And, although you might not be able to control the number of firewalls on your network (whose protection can be somewhat offset by the monitoring and management challenges that different access rules create), you probably can control how many and which protocols (and therefore ports) your company uses. Because business units drive many IT projects, companies often have multiple Internet connections. One of my client companies has roughly 50 business units and as many Internet connections. (I won’t discuss the potential problems that come with 50 Internet connections and possibly 50 firewalls; you understand the risks and administrative nightmares.) However, you no longer need all those connections. Instead, you can place a couple of inbound servers for the mail protocols centrally to provide a redundant inbound path for email and OWA. As you know, the more inbound ports you have open on your network, the less secure your network will be. Although I’ll discuss security in more depth in Chapter 7, I want to emphasize here some key points about the vulnerabilities that multiple protocols can create. Figure 3.1 shows a three-site design with multiple protocols in use. Brought to you by Quest Software and Windows & .NET Magazine eBooks 36 The Expert’s Guide for Exchange 2003 Figure 3.1 Site design with multiple protocols SUv.com Internet Other Sites SMTP POP Trucks.com IMAP HTTPS SportsCar.com Other Sites You can see several points of vulnerability in this design: 1. A new virus or network attack could bring down all three sites because they’re all exposed to the Internet. 2. From an SMTP perspective, a server or network failure stops inbound mail for that entire SMTP domain. 3. Virus and antispam updates might not be in sync, so different locations might have different protection levels. 4. Three firewalls and their access rules are much more difficult to manage and monitor than one or two. In Figure 3.1, you can see that many inbound ports must be enabled to support each business unit. A better design would establish a clear boundary between the Internet and the email servers (i.e., a Demilitarized Zone or DMZ) and consolidate the Internet email services to better secure and stabilize the environment. Brought to you by Quest Software and Windows & .NET Magazine eBooks Chapter 3 Consolidating Your Exchange Services 37 You can establish a protective boundary for your organization in various ways. You can configure Microsoft IIS to provide a boundary or configure Linux with Sendmail to accomplish the same purpose. Other products and more sophisticated solutions also exist. Microsoft has recently announced a new product, Exchange Edge Services, which will eventually play this role for SMTP and provide additional features as well. The current Microsoft solution is to place Microsoft ISA Servers or Exchange 2003 front-end servers at the boundary. Exchange 2003 and AD Before I discuss front-end server deployment, I want to point out that Exchange 2003 is smarter than I once thought. Because its folders and mailboxes are published to Active Directory (AD), Exchange 2003 knows to look in AD for Exchange resources. In your Exchange organization, you have mailboxes on servers. AD keeps mailbox information under several Exchange attributes in the Class object USER for each person who has a mailbox. But if you look at the Exchange objects in the Microsoft Management Console (MMC) Users and Computers snap-in, you see that the public folder proxies (in the default top-level hierarchy) are also added to AD, as Figure 3.2 shows. Figure 3.2 Exchange System Objects and Exchange Mailbox Store Each Exchange server in the routing group is notified of a hierarchy change, and information about the folder structure is replicated. This notification lets each mailbox server (within the routing group) report the folder hierarchy as well. And therein lay the magic. Brought to you by Quest Software and Windows & .NET Magazine eBooks 38 The Expert’s Guide for Exchange 2003 Although the public folder exists on only one server in the routing group, other Exchange 2003 servers can automatically redirect to the appropriate server. If I use OWA to access a public folder that exists on a different server, the server to which I’m connected will perform a quick directory lookup and send me to the server that contains the data.