Exchange in a Large Corporate Environment

Introduction Slide

This morning I am going to give you a perspective of a few of the major issues that need to be considered when implementing Exchange in a large corporate environment.

As examples I shall be referencing some areas of EDS' own messaging infrastructure.

To set some understanding—EDS' 1995 turnover was in excess of $12 Billion (US dollars). Staff world-wide are 90,000+ operating in over 65 countries.

Before I get into the detail of Exchange I should like to position the talk in the context of where EDS is in messaging today and its strategy for the future now that a true client-server enterprise capable solution is available.

EDS is well known for operating one of the largest private voice and data networks—EDS*NET. EDS' messaging environment is also substantial—some current statistics:

EDS' global directory contains some 27,000+ registered which are automatically synchronised across some two dozen different mail systems ranging from:

• 60+ thousand Office Vision users on five systems
• 70+ thousand Lotus Notes users on ~1000 servers
• 30+ thousand MS Mail users on ~270 servers
• Over 1M messages are sent each month
• Over 1M messages are received each month
• 200+K messages are sent to external users via the Internet
• ~90K messages are received from external users via the Internet

Talk Objectives

Microsoft Exchange Server

• Microsoft Exchange Site
• Relationship between Microsoft Exchange Sites and Windows NT domains
• Microsoft Exchange Site and Windows NT-based domain topology
• Microsoft Exchange and Web Services

Messaging in EDS—Today

• Many mail systems
• Differing Capabilities
• Large Directory
• Growth in User Requirements
• Growth in message size/complexity

Design Considerations—Some thoughts

• Present Installed base
• Desktop/Laptop—capacity
• LAN capability—capacity
• WAN availability—capacity

Present Installed Base

• Current Business Culture
• Business drivers for Exchange
• Infrastructure capabilities
• Business Priorities

Desktop/Laptop

• Is there the capacity—who pays?
• What cost to implement?
• What is cost to support?
• Business Case

LAN Capability

• Existing Architecture
• Is there an NT domain strategy?
• Is there an NT architecture?
• How is NT to be supported
• Security requirements?
• LAN Bandwidth
  • server
  • desktop

Server Sizing

• User usage levels
• Personal Mail
• Public Folders
• Rules/Views/Microsoft Schedule+
• Server hardware
  • CPU(s)
  • RAM
  • I/O subsystem

What Software Factors Influence Server Performance?

• Synchronous client-initiated actions
• Reading a Message
• Opening a Folder
• Server "Background Actions"
• Message transfer
• Replication
• Rules processing

Synchronous Client-Initiated Actions

• RPCs from clients to server
• Client-server semantics are critical
• Server load completely dictated by user actions
• Most RPCs are to the Information Store
• Response times dictate the user's perception of performance
• PST users place less load on the server

Server "Background" Actions

• Actions performed for users on the server using "background cycles"
• Server load indirectly dictated by user actions
• Users are less sensitive to background response times
• Message transfer largest consumer of background resources
• Public Folder replication proportional to modifications
• Directory replication will probably be negligible—DL modifications largest contributor

Other Sources of Load on the Server

• Gateways
• Other server applications
• Third-party Microsoft Exchange Server applications
• Microsoft SQL Server
• File Server
• Message tracking
• Event/diagnostics logging
• Server maintenance processing
• Server backup

What Hardware Factors Influence Server Performance?

• CPU speed and number
• RAM
• I/O subsystem
• Random access I/Os per second
• Software/hardware striping
• Caching controllers
• Network bandwidth and protocol

Balancing Hardware Resources

• The "delicate" dance
• I/O capacity and storage space go hand-in-hand
• RAM and I/O are interrelated
• Use the Windows NT Performance Monitor to find bottlenecks

Microsoft Exchange Server Optimizer

• Asks server usage questions
• Analyzes disk partitions speed/size
• Suggests/moves databases and Transaction Log Files
• Configures hardware-sensitive server parameters
• Run every time software or hardware modifications are made

Server Performance Recommendations

• Find your server hardware "sweet spot"
  • Think about user activity levels
  • Estimate your user usage levels
• Use LoadSim to simulate user loads
• Tune your software and hardware
  • Run the Microsoft Exchange Server Optimizer after All software or hardware modifications
  • IS Transaction Log on its own physical drive
• Use disk striping to increase I/O capacity

NT Domain and Exchange Site Topology Issues

Microsoft Exchange Server And Windows NT

Microsoft Exchange Server:

• Runs on Windows NT Advanced Server
• Leverages Windows NT Security for authentication and access control
• Utilises Windows NT Service for
  • Event Log
  • Service Control
  • Performance Monitor

Client Authentication

• Microsoft Exchange Server "impersonates" the security context of the client
• Client must have established a "security context" in an Windows NT-based domain which the server knows about
  • Windows NT account in the same domain as the server
  • Windows NT account in a domain which the server domain trusts
• Once the user proves who they are, they must then have the appropriate permissions configured to do what they want

Administration—Authentication

• Microsoft Exchange Server "impersonates" the security context of the administration application
• Administrator must be logged onto an Windows NT account in an Windows NT domain which the server knows about
• Just another type of "client" as far as Microsoft Exchange Server is concerned
• Additional administration rights in addition to user rights

Server Authentication

• Microsoft Exchange Server impersonates the security context of other servers in the same site
  • Directory Service replication
  • Message Transfer
• Authentication is bi-directional
• Inter-site message transfer authentication dictated by the messaging system used to connect the sites together

Access Control

• The Microsoft Exchange Administration Program is used to grant Windows NT accounts rights on Microsoft Exchange mailboxes
• The set of Windows NT domains and accounts offered are those the Windows NT–based machine on which the Administration Program is being used knows about
• Local groups and accounts are generally not shown

Microsoft Exchange Sites

• One or more Microsoft Exchange Servers in a site
• Users have a mailbox on a specific server
• All connectivity between servers in a site is RPC-based, bi-directional, single hop, peer-to-peer
• Assumed non-scheduled LAN connectivity and common security authority
• Directory data is multi-master within a site, read-only outside the site

Microsoft Exchange Site

Microsoft Exchange Organisation

• One or more sites in an organisation
• Connectivity between sites is always messaging-based
• No assumption of LAN connectivity or shared security authority
• Connectivity between sites may be indirect through any messaging system
• Connectivity between sites may be multihop
• Inter-site connections may be intermittent and scheduled

Microsoft Exchange Organisation

Windows NT-Based Domains

• Allows for centralised administration of machines at the domain level
• One or more Windows NT Servers in a domain
• At least one Domain Controller per domain
• Each machine in the domain has a machine account
• Machines in a domain share security and user account information
• Domain boundaries dictated primarily by administrative needs

Windows NT-Based Domains

Windows NT-Based Domain Trust Relationships

• Allows one domain to trust another's security information
• Allows users to have a single account and password in a single domain and yet access resources in other "trusting" domains
• Allows for centralized administration at the network level
• Trust can be one-way or two-way
• Trust is not transitive

Windows NT-Based Domain Trust Relationships—Single Master Domain

Windows NT-Based Domain Trust Relationships—Multiple Master Domain

Some Geography

Here we have a representative resilient network depicting a corporation with three locations in the US and three in Europe but in different countries.

This is a fairly typical scenario where these represent major centres of activity for the company. There may well be a number of satellite locations feeding each of the country major locations.

What needs to be understood is that each of these countries have their own PTT regulations regarding communications and differing interpretations of even international standards. These regulations must be factored into the messaging infrastructure architecture and design equation.

We hear much talk at a political and press level of the information superhighway. The reality is that some of the technology exists to enable it and physically the fibre, cable and satellite links could be put in place. BUT who is prepared to pay for it? The next slide takes the network depicted here and assumes a TI circuit speed (1.544 Mb/s) or E1 circuit speed (1.44 Mb/s). They cannot even agree circuit speed standards between the US and Europe!!

WAN Bandwidth Costs

The figures speak for themselves. This is one of the biggest factors in designing a messaging infrastructure that delivers an acceptable service but does not break the corporate bank.

High Level Domain Strategy

Multiple Master Domain Model

Microsoft Exchange Sites And Windows NT–based Domains

• Microsoft Exchange Site
  • Island of high-bandwidth synchronous LAN connectivity
  • Site boundaries determined primarily by network and messaging topology
• Windows NT-based domain
  • Basic unit of security and administration for the network
  • Domain boundaries determined primarily by administrative needs

Windows NT-based Domains Can Span Microsoft Exchange Sites

• You could put every single Microsoft Exchange Server into its own site if you really wanted to
• Might be necessary if you have strict messaging protocol or routing requirements

Microsoft Exchange Sites Can Span Windows NT-Based Domains

• By default, Microsoft Exchange setup specifies the same service account for every Microsoft Exchange Server
• Specifying different NT accounts for each Microsoft Exchange Server possible, but why?
• Maintaining user accounts in a single Windows NT-based domain is highly recommended

Public Folder Issues

• Distributed, replicated repository of "public" user data
  • Folder hierarchy replicated to every server
  • Folder contents may be replicated on a per-folder basis to multiple servers as needed
• Public Folders have rules, ACLs, forms, views
• Multi-mastered replication model, even across sites
• Replication always via mail messages
• Site Affinity allows for users to access Public Folder replicas outside their own site

Public Folders—Site Affinity

Exchange and the Internet

• Concept of Universal Inbox
• Information Repositories—objects
• Group Working/Scheduling
• Information Dissemination
• Web Services
  • Corporate Intranet
  • Public Internet